Use language maps approach for string internationalization

[acka47]

We currently represent German and English values for the properties classification, fundertype and stocksize in the following way using what the JSON-LD spec calls a "expanded term definition". Example:

  "classification" : {
    "id" : "http://purl.org/lobid/libtype#n15",
    "label" : "Zentrale Fachbibliothek",
    "label_en" : "Central Subject Library"
  }

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:

... systems often need to express the value of a property in multiple languages. Typically, such systems also try to ensure that developers have a programmatically easy way to navigate the data structures for the language-specific data. In this case, language maps may be utilized.

For the example above this would look like this:

{
   "@context": {
      "label": {
         "@id": "http://www.w3.org/2000/01/rdf-schema#label",
         "@container": "@language"
      }
   },
   "classification":{
      "id": "http://purl.org/lobid/libtype#n15",
      "label": {
         "de": "Zentrale Fachbibliothek",
         "en": "Central Subject Library"
      }
   }
}

[nichtich]

Just change id to uri and label to prefLabel and you get valid JSKOS for classification, fundertype, and stocksize!

[acka47]

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,

[fsteeg]

Deployed to staging:

http://test.lobid.org/organisations/DE-605?format=json http://test.lobid.org/organisations/context.jsonld

[nichtich]

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.

[acka47]

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?

[acka47]

@fsteeg +1

[nichtich]

@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.