Add a language tag in "skos:altLabel"

[BaptisteCecconi]

In some vocabularies in preparation (such as the ObsFacility one), we need to include and language tag in the "skos:altLabel" literals.

This is restricted to the "skos:altLabel" relations, but the default language value of the skos:prefLabel, rdfs:label or rdfs:comment should be set to english anyhow, for better interoperability outside the IVOA ecosystem (in the RDF/XML or RDF/ttl representations of our vocabularies).

[msdemlei]

On Fri, Mar 01, 2024 at 04:51:26AM -0800, Baptiste Cecconi wrote:

In some vocabularies in preparation (such as the ObsFacility one), we need to include and language tag in the "skos:altLabel" literals.

This is restricted to the "skos:altLabel" relations, but the

With this restriction, I have no fundamental problems with that, but I think we should first work out how this would look like in desise. My immediate hunch would be do have a key

altLabel: { lang1: ["label1", "label2"], lang2: ["label3"], ... }

but is that actually what would be useful for clients? I frankly don't think we (in the VO) actually would want localised labels on anything we do, and then sorting by language doesn't make any sense.

For all I can see, our one use case at this point is in the facilities vocabulary, where we would like to keep, as it were, alternative spellings for the use by resolvers. If that remains the only use case, a single, flat list would do. But then I don't feel too good about discarding the language information entirely. Perhaps we should just go for a flat sequence for strings with Turtle-style language tags:

altLabel: @.", @.", ...]

Oh, and would we show this in our HTML renderings? My instinct would be: probably not.

[BaptisteCecconi]

With this restriction, I have no fundamental problems with that, but I think we should first work out how this would look like in desise. My immediate hunch would be do have a key

altLabel: {
   lang1: ["label1", "label2"], 
   lang2: ["label3"], 
   ... 
} 

but is that actually what would be useful for clients? I frankly don't think we (in the VO) actually would want localised labels on anything we do, and then sorting by language doesn't make any sense. For all I can see, our one use case at this point is in the facilities vocabulary, where we would like to keep, as it were, alternative spellings for the use by resolvers. If that remains the only use case, a single, flat list would do. But then I don't feel too good about discarding the language information entirely. Perhaps we should just go for a flat sequence for strings with Turtle-style language tags:

altLabel: ***@***.***", ***@***.***", ...]

Oh, and would we show this in our HTML renderings? My instinct would be: probably not.

The main use-case is indeed for the resolvers. In the ObsFacility vocabulary, we would like to include alternate labels in any languages we have information for in Wikidata. Although most of the known names of observations facilities are in English, some observatories can be referred to with their local language name. For instance, there are some papers using French names or acronyms for radio telescopes in Nançay. We need to include those terms in our vocabulary, so it can be used and mapped to the skos:prefLabel label. The goal is to use the skos:prefLabel for the IVOA vocabulary (in english language), and that's only what should be required for an IVOA vocabulary (and shown on the vocabulary page).

In HTML rendering, I don't think skos:altLabel's and languages should be displayed.

I don't have strong feelings on including language information in the desise version. If desise have to include the same information as in RDF/xml or turtle, then yes. If desise is seen as a JSON version of the HTML view, then we may keep this simpler.