issues

• Create a script to create a Docker container, to make the install and upgrade process a lot easier.

• Backwards & Forwards history navigation has several issues.
  • note: The web standards community is working on improving the browser-history API, since many other “Single Page Applications” (SPA) are running into the same issues.
  • See also: App History API (proposal)

• Reloading complex-encoded URLs does not always work, due the mis-encoding of the URL parameters. This is a tricky issue, for which the causes which will need to be carefully studied, tested and fixed. Research what tools could be used to help debug this issue.
  • There is a need to have a better workflow & tooling to help with debugging these URL-issues.

• Allow for datasources activation via an URL parameter (so these searches can be linked to) and store these in a cookie.

• Add persistent-linking to inline-views
  • When clicked on headline/section fields, set the fragment-parameter in the URL
  • When a URL with a fragment is loaded, upon up the inline-view.
  • Note: Make sure the used IDs are robust and durable.

• URL hash handling
  • Fix the hash-handling conflict between the inline-category widget and Wikipedia ToC clicks.
  • Always reset the hash when needed (eg. when clicking on another topic) (partly fixed)
  • Scroll-position / section alignment issue for Wikipedia (example)

• Cold-startup time (upon first use) is very slow - sometimes more than 10-20 seconds on low-bandwidth networks.

• The Apple iOS mobile browser needs more UX testing & fixing.

• The Wikipedia-app needs a “Table of Content” system suited for mobile devices.

• Accessibility (including keyboard-access) should be assessed and improved where needed.
  • Integrate an automated accessibility test system.
  • Maybe look into a web-component framework for accessible replacements (when needed).

• Integrate an automated testing system.

• Get more UX feedback from real users.

• Improve the workflow for adding API integrations.
• Improve the workflow for adding datasources.

• Create a structure to store field-label translations (title and icon-title), both for Wikidata and non-Wikidata fields.
  • Allow the json2fields script to fetch and store property translations too.

• Clean up any issues with field definitions:
  • Turn the the inline-API field-structure into an object (instead of a string)?

• Difficulty avoiding duplicate items in more complex/stacked SPARQL queries (there are some ways, but it is not easy to generalize to all SPARQL queries). (experiment more with “GROUP BY”)
• Wikidata: claim-statements integration not done yet, because the data-access is more complex when using wikibase-sdk (with claims).
• Abandoned Wikidata-based tools.
• Wikipedia: Image-loading failing sometimes (“too many image requests”)

• How to detect if the field URL could be embedded (instead of opening a a new tab)? (run a headless browser loading an iframe with the URL, checking for CORS-errors?)

• JSON-LD enhancement: “Add schema:about properties that include #Wikidata (/entity/{id}) and #DBpedia (/resource/{id}) identifiers as property values.” * (this is useful when there are multiple subjects, beyond the main subject)

• Conzept currently uses the Europeana APIs for:
  • The Europeana item viewer app (REST API, not sparql) (code based on this project)
  • The inline Europeana media-query for images (REST API)
  • TODO: audio-query in SPARQL/REST (used for dynamically fetching audio in the auto-generated presentations) (see below)

• Europeana SPARQL links:
  • https://pro.europeana.eu/page/sparql (docs)
  • http://sparql.europeana.eu (online query tool)

• Specific SPARQL-questions:
  • Show a SPARQL query to fetch audio-URLs (in MP3 or Ogg Vorbis format) from a certain creation year (with a source link for attribution).

How to get the license info: also from the Aggregator object?

• edm:rights “The rights statement that applies to the digital representation (…)” * dc:rights “Information about rights held in and over the resource.”

PREFIX dc: <http://purl.org/dc/elements/1.1/>
PREFIX edm: <http://www.europeana.eu/schemas/edm/>
PREFIX ore: <http://www.openarchives.org/ore/terms/>
SELECT ?title ?creator ?mediaURL ?date
WHERE {
  ?CHO edm:type "SOUND" ;
      ore:proxyIn ?proxy;
      dc:title ?title ;
      dc:creator ?creator ;
      #dc:source ?source . 
      #dc:license ?license ;
      dc:date ?date .
  ?proxy edm:isShownBy ?mediaURL .
  FILTER (?date > "1960" && ?date < "1970") .
  FILTER(regex(str(?mediaURL), ".mp3" ) )
}
LIMIT 100

• The same query as above, but for a certain country.

How to get country string?

PREFIX dc: <http://purl.org/dc/elements/1.1/>
PREFIX edm: <http://www.europeana.eu/schemas/edm/>
PREFIX ore: <http://www.openarchives.org/ore/terms/>
SELECT ?title ?creator ?mediaURL ?date ?country
WHERE {

  # ?Aggregation edm:aggregatedCHO ?ProvidedCHO ;
  #    edm:country "France" .
      
  ?CHO edm:type "SOUND" ;
      ore:proxyIn ?proxy;
      dc:title ?title ;
      dc:creator ?creator ;

  ?proxy edm:isShownBy ?mediaURL .
}
LIMIT 100

working “country” example:

PREFIX ore: <http://www.openarchives.org/ore/terms/>
PREFIX edm: <http://www.europeana.eu/schemas/edm/>

SELECT DISTINCT ?year ?country
WHERE {
  ?Aggregation edm:aggregatedCHO ?ProvidedCHO ;
      edm:country ?country .
  ?Proxy ore:proxyFor ?ProvidedCHO ;
      edm:year ?year .
  FILTER (?year > "1700" && ?year < "2020")
}
ORDER BY asc(?year)
LIMIT 100

• General remarks on the SPARQL service:
  • Add https-support (besides http) to the SPARQL-endpoint (web applications hosted on https require that, because of the secure-browser context strictness these days).
  • what is the SPARQL data freshness (I've heard the data is 2+ years old) and what is the data completeness (amount of items, compared to the REST API)?
  • It would be nice to have better ontology documentation, especially an overview of the high-level concepts.
    • For example provide an entity overview like this and a visual relation-tree like this.
    • Plus anything that would make the mental-map-to-ontology translation easier for users.
  • Provide a low-barrier REST/SPARQL API query-support via a wiki or forum similar (this is what Wikidata is doing)
  • Provide a community wiki-page with lots of linked query examples (with a short explanation and if needed comments in the SPARQL-query)
  • Provide a better online query-tool, like: https://query.wikidata.org (this tool is free and open to use, this is also used for Conzept)