Closed acka47 closed 7 years ago
Just change id
to uri
and label
to prefLabel
and you get valid JSKOS for classification
, fundertype
, and stocksize
!
Hi @nichtich, thanks for the hint.
id
is mapped to @id
in the JSON-LD context and we won't use another label for this.
Regarding label/altLabel, we are working on implementing a "side car" approach for all our services using label
and altLabel
to give names for linked resources – whether they are authority resources data or other resources (like a superordinated bibliographic resource, e.g. a Journal linked to from an article).
For now, we chose label
and altLabel
. Currently, I am thinking of using http://schema.org/name and http://schema.org/alternateName instead, see https://github.com/hbz/lobid-resources/issues/103#issuecomment-244375448,
Changing names is less a problem than different structures, so I don't mind whether label
or prefLabel
and id
or uri
. altLabel
is not included in the current context document, it should be a language map too, right? In JSKOS this is also named altLabel
and its value MUST be an array, because it is repeatable. In pure JSON-LD one cannot express such additional constraints, that's why I chose to define an independent data format that happens to be JSON-LD, not the other way round.
altLabel
is not included in the current context document, it should be a language map too, right?
We don't have any alternate Labels in lobid-organisations so we don't need it in the context.(We will have to add it to lobid-resources, though, see https://github.com/hbz/lobid-resources/issues/103.)
it should be a language map too, right? In JSKOS this is also named
altLabel
and its value MUST be an array, because it is repeatable.
Yes, we will do it like this in lobid-resources but without language maps as we don't have any language tags in the data (mainly GND) we use there. Out of curiosity: If we used language maps on altLabel
it should look something like this:
{
"@context": {
"id": "@id",
"type": "@type",
"label": "http://www.w3.org/2000/01/rdf-schema#label",
"altLabel": {
"@id": "http://www.w3.org/2004/02/skos/core#altLabel",
"@container": "@language"
},
"subject": {
"@type": "@id",
"@id": "http://purl.org/dc/terms/subject",
"@container": "@list"
}
},
"@id" : "http://lobid.org/resources/HT018843259#!",
"subject": [ {
"id" : "http://d-nb.info/gnd/4031485-6",
"type": "PlaceOrGeographicName",
"label": "Erzstift Köln",
"altLabel": {
"de": [ "Kölner Krieg", "Truchsessischer Krieg" ]
}
} ]
}
This seems to be valid JSON-LD (see https://www.w3.org/TR/json-ld/#language-maps). Is it also what you envision for JSKOS?
@fsteeg +1
@acka47 yep. The @context
tells that altLabel
is a JSON-LD language map, but JSON-LD need to expect both arrays, and strings. JSKOS enforces arrays in addition, making this part a subset of JSON-LD. JSKOS further extends language maps for closed world-statements (useful if there are many languages but not all of them are included in a record), but this part can be stripped automatically.
We currently represent German and English values for the properties
classification
,fundertype
andstocksize
in the following way using what the JSON-LD spec calls a "expanded term definition". Example:There is another approach defined in the spec that is more developer friendly: language maps. It reads in section 6.9 of the JSON-LD spec:
For the example above this would look like this: