Extend the context file to get better RDF coverage

[jh-RLI]

Summary of the discussion

We want to provide the oemetadata in an RDF using json-ld. We already provide a simple / basic context.json file but we want to attempt to cover 100% of the oemetadata properties. As it is not always easy to find matching ontology terms to map the properties. 100% coverage might not be feasible.

Type of change (CHANGELOG.md)

Added

• Add test for @context with the example.json as valid JSON-LD (#234)

Changed

• Update the context.json and add terms for all keys (#234)

Workflow checklist

Automation

Closes #232

PR-Assignee

• 🐙 Follow the workflow in CONTRIBUTING.md
• 📝 Update the CHANGELOG.md
• 📙 Update the documentation
• 🐙 Assign a reviewer to the PR

Reviewer

• 🐙 Follow the Reviewer Guidelines
• 🐙 Provided feedback and show sufficient appreciation for the work done

[vismayajochem]

Following ontology classes appear in the oekg:

• rdfs:label
• not dct:title (json-ld) but DC:title (oekg)
• not dct:description (json-ld) but DC:description (oekg)
• not sc:url (json-ld)l but SCHEMA:url (oekg) which should be the exact same
• not dct:descrpition but DC:description

[Ludee]

Dublin Core (DC)
dc: DC Elements (15 terms) "Dublin Core Principles"
dct: DC Terms (15 terms + ranges) "Dublin Core Terms"

Unless you have a reason for using the terms from the Element Set .., go with the terms from the Terms namespace

source: https://stackoverflow.com/questions/47519315/what-is-the-difference-between-dublin-core-terms-and-dublin-core-elements-vocabu

[Ludee]

subject (General Keys)
8.1 | name -> rdfs:label
8.2 | @id -> dct:subject

context:

            "@container": "@set",
            "@id": "dct:subject"
        },```
        
Should that be a "nest" as well?

[jh-RLI]

This is a bit experimental as the container feature was added to the json-ld specification not too long ago. The decision about using “nest” or “container” for properties that are used to group other properties is not 100% settled yet. For this reason, I have introduced the container for groups for which I have found a term, and as nest for groups for which I could not find a term. As far as I understand it, the “container” can help to improve the graph structure derived from the json-ld mapping in context using a parser.

I would like to keep this for future discussions. It's valid and doesn't seem to interfere with any other functionality so far.

EDIT: Another constrain for how to decide between @nest and @container usage is the structure of the property once wants to annotate. If the property is a list (e.g. "xyz": [ ... ]) than you can use the container with type: @set oder @list if the property is a complex type (e.g. "xyz": { "prop": "val", "prop2": "val2" }) then we cant use a container without defining the type in the json data at the position of the related property xyz. The json ld parser will otherwise raise an error.

subject (General Keys) 8.1 | name -> rdfs:label 8.2 | @id -> dct:subject

context:

            "@container": "@set",
            "@id": "dct:subject"
        },```
        
Should that be a "nest" as well?