Properly validate context and support additional context definitions

[acka47]

I think these are currently not validated as incorrect.

[acka47]

Das Problem ist, dass bisher der Context nicht vernünftig validiert wird. Fehlen z.B. die SKOS properties ("prefLabel": "skos:prefLabel" & "inScheme": "skos:inScheme"), dann wird das bei der Validierung nicht entdeckt.

Eine Möglichkeit, damit umzugehen, ist eine Aktualisierung des Schemas wie in ca2236b.

Eine zweite – eventuell elegantere – Möglichkeit ist die Publikation eines externen Kontext, der dann im Schema referenziert wird und entsprechend validiert wird.

Eine dritte Möglichkeit ist dann natürlich, beide Optionen zu erlauben.

[acka47]

Im Branch 12b-contextTest habe ich mal die Lösung mit einem externen @context-Dokument umgesetzt und zwar so, dass optional auch ein weiterer Kontext referenziert werden kann oder auch nur ein einzelnes Key-URI-Mapping ergänzt werden kann wie in Beispiel 20 in der 1.1 Spec.

Das wäre meine präferierte Lösung.

[acka47]

Mir fiel gerade auf, dass ja im Schema nur Concept and inSchemeaus dem SKOS Namespace erwähnt werden. Dementsprechend sollten wir prefLabel aus dem Context entfernen. Dies würde es Anwendungen auch überlassen, ob sie dafür kein Sprachtag, das Default-Sprachtag oder eine language map benutzen wollen.

[acka47]

Dementsprechend sollten wir prefLabel aus dem Context entfernen.

Um die Anforderungen in #18 zu erfüllen, bleibt wird prefLabel im Kontext bleiben und um "@container": "@language" ergänzt, siehe 12499f9#diff-447f8484035cf0d63b4dea54fed16bec.