Improve JSON-LD context

[carstenhoyerklick]

Description of the issue

1. In some previous discussions we noticed that there is a mix-up of classes and properties in the context.
2. We should also move the standard context from the gitrepository "https://raw.githubusercontent.com/OpenEnergyPlatform/oemetadata/production/oemetadata/latest/context.json" to something which delivers proper application/json-ld.

Ideas of solution

1. Update the context for the metadata
2. Put the context e.g. on MOSS of the OEP: https://moss.openenergyplatform.org/modules/OEMeta204/context

Workflow checklist

• I am aware of the workflow in CONTRIBUTING.md

[jh-RLI]

Is there a list (or draft list) in which the terms are incorrectly assigned? I cannot immediately tell what is a property and what is a class.

[holycrab13]

A first step would be to look up the URIs and create a list.
A strong indicator is the convention to write type with capital letter and properties with lower case letter:

"fundingAgency": {
      "@id": "sc:FundingAgency",
      "@type": "xsd:string"
}

looking up sc:FundingAgency points to https://schema.org/FundingAgency which is a type, in the context it looks like it is declared like a property.

There might be more things to fix and adjust in the context, but I think the Type/Property-errors would be a good place to start

EDIT: This is Jan Forberg from InfAI, feel free to add me to the project and assign me to the issue :)

[holycrab13]

Other flaws in the context, just to have them listed:

• Duplicate mappings. Currently the context maps multiple properties to e.g. dct:issued. Part of the problem is that the properties in the metadata might be not precise enough. E.g.:

  • publicationDate -> dct:issued
  • publicationYear -> dct:issued
  • date -> dct:issued

  I think it would be best here to either use "issued" and map it to "dct:issued" for all entries in the metadata or create an ontology for the OEMetadata with a property like oem:publicationDate and then use "publicationDate" everywhere with a standardized date format specified at oem:publicationDate. This would eliminate the need for a property like "publicationYear" altogether.

• An easy fix would be using https namespaces, if available. E.g.: https://schema.org/ instead of http://schema.org/

• Usage of properties "context" and "id" in the original metadata requires mappings in the context. "@context" and "@id" are fixed keywords in JSON-LD. This could create confusion and could be handled more cleanly. This could however require changes to the metadata format itself. I would strongly recommend to make a small step towards JSON-LD in the OEMetadata itself instead of solely relying on the "@context". Most importantly I would recommend using "@id" instead of "id" or "path" for identifiers.

[Ludee]

dct:issued

That is because there are talking about different materials.
As I am currently updating the dataset structure, there will be 4 "issued":

1. (new) dataset/created -> Day of the creation of the dataset [mandatory in DataCite]
2. resource/publicationDate -> Day of the creation of the table
3. resource/sources/publicationYear -> Year of the publication of the source [mandatory in Bibtex]
4. dataset/contributors/date -> Day of the specific contribution. Can be updated to dct:modified

They all fit the description of dct:issued and xsd:date
https://www.w3.org/TR/vocab-dcat-2/#temporal-properties

https://
Can be fixed! Thanks.

context / id
We have a naming issue here.
The '@context' is the JSON-LD extension. There is also a "context" section, that describes the "projectContext".
We decided against having everything in a single file, because we want the standard to be used by humans in our domain. Usability first.
But we can and should automatically create a single LD file and can setup a proper endpoint for the metadata.