Closed acka47 closed 4 years ago
I would simply go with 1. and publish the context used in e.g. https://skohub.io/literarymachine/skos/heads/master/oerworldmap.org/assets/json/licenses/by-nc.json on SkoHub. We could even just add it alongside the rest of the static data individually for each repo.
As for 2., I don't think anybody uses or actually knows those schema terms.
+1 for the custom context. However, take note that the contexts differ for the SKOS vocabs and the editor.
I moved the schema plus context to https://github.com/dini-ag-kim/lrmi-profile where the schema will be further developed and perspectively will also get an HTML specification. The files are published with GitHub pages at https://dini-ag-kim.github.io/lrmi-profile/draft/schemas/schema.json & https://dini-ag-kim.github.io/lrmi-profile/draft/schemas/context.jsonld. Closing.
We now have implemented #21 which is great, however, we are currently using SKOS besides schema.org in the JSON-LD and the respective properties (
prefLabel
,inScheme
) and type (Concept
) are not mapped in the context yet. There are two approaches for dealing with this1. Publish and link a custom context
We could change the
@context
link to a custom context that we be publish somewhere. The context would look something like this:2. Replace SKOS elements with schema.org
Instead of SKOS, we could use schema.org everywhere and replace SKOS parts like this:
skos:Concept
->schema:DefinedTerm
skos:prefLabel
->schema:name
skos:inScheme
->schema:inDefinedTermSet
However, these terms have been in the pending section schema.org now since April 2018 (https://github.com/schemaorg/schemaorg/pull/1776) and haven't been integrated into schema.org yet. Would it be sufficient for this approach to update the JSON schema or would this approach require more adjustments in the way we create the data about a SKOS concept?