Should `gist` add explicit English language tags to all its existing SKOS annotation values?

[pmcb55]

Currently the skos:prefLabel and skos:definition (and skos:scopeNote and skos:example, etc.) values for all terms in gist are only provided in English, yet they are not explicitly language tagged with @en.

To help promote more international reuse of gist, and to more clearly and explicitly denote the intended use of these values (i.e., I assume for human users to read and interpret), I would strongly advocate always adding explicit language tags for such predicates (and to leave strings of type xsd:string for predicates whose literal values would never make sense to translate across human languages (e.g., values for social security numbers (that may contain hyphens), or alphanumeric passport numbers, etc.))

[Jamie-SA]

This request has come up several times. I am not sure why we haven't done this yet.

#311
#228
#185
#85

[rjyounes]

It's worth reading the discussion thread on #311 to get some insight into why we haven't done this in the past - essentially, the assumption is we have no non-English-speaking users and therefore no use case. But as use of gist broadens, we may well have international users.

If we do want to do it, rdf-toolkit has this option:

 -osl,--override-string-language <arg> 
 sets an override language that is applied to all strings

We could add this argument in the pre-commit hook.

However, this will over-generate in a couple of cases:

• gist:license value - though it has been suggested that this be an object rather than datatype property - see Should gist:license be an object property? #682.
• If we use vann:hasPreferredPrefix and hasPreferredNamespaceUri as suggested in Should gist describe its preferred prefix and namespace URI using VANN? #684.

Perhaps it's better placed in the bundler, where we can specify exactly the properties we want it to apply to (note: all annotation properties, not just skos:prefLabel and skos:definition).

[Jamie-SA]

Should it be a post processing step? Why not just change the source files and then only verify correctness in the bundling step? Similar to some of the queries Boris wrote for validating style.

Also think through how we'd want to handle having multiple languages in/for gist.

[rjyounes]

That works too, but I do think we should use the bundler to verify it in case people forget, as you suggest.

[JonathonGist]

Excellent. I was hoping you all would add @en where appropriate.

[rjyounes]

Considerations:

• @en tags could be added by bundler.
• This is a breaking change, not in terms of inferences, but it will break SPARQL queries.
• The bundler could add non-tagged versions of the annotations to rdfs:Annotations, for users who don't want to update their queries.
• Alternatively, Jamie suggests keeping the non-tagged files in gistCore.ttl, at least as a transitional device, so users don't have to add an additional import.

Needs further discussion, so moving to December release.

[Jamie-SA]

Rebecca is correct, this likely will break someone's queries or code. But I think we should do it. I'll volunteer to do the PR.

I think we should schedule it for the next major release (probably the Units Of Measure changes release).

But there is another problem, if we only have one language, adding a second would also break queries/code. It seems we have 2 options, 1) keep translations in a separate file, or 2) add at least one more language at the same time so people would need to address the issue of multiple languages at the same time as the switch to language tags.

Dealing with multiple languages might be harder for most of us who haven't had to deal with it yet, than just the change of literal type. So part of my likes the idea of keeping other languages in separate files. But I also think it might be a good idea to push us to start preparing for it, and therefore should put them into the main file. Of course, we could release multiple versions and let people choose.

See also these discussions about dealing with multiple languages:

• Resolving labels with language negotiation w3c/sparql-dev#13
• https://github.com/w3c/sparql-12/blob/main/SEP/SEP-0005/sep-0005.md

[rjyounes]

I don't consider myself anglocentric, but I don't think ontology terms need to have language versions until we have a specific use case for that. Instances are a different issue. In the Treasury of Lives project, for example, data properties like names and pref labels in taxonomies have different versions for different languages and transliterations. But ontology terms are not user-facing and I see no reason to provide alternate language versions for maintainers of the ontology - again, until we have a use case, which would have to be a gist developer who knows little or no English - arguably extremely unlikely.

[Jamie-SA]

I disagree. I think you are being quite anglocentric.

This isn't just for maintainers of gist, it is also for users of gist. I think we do want to increase the adoption of gist, don't we? If you want non-native English speaking developers (quite a bit of the world) to adopt gist, then gist should provide, or at least allow for, annotations in multiple languages.

And, when you move towards model/metadata driven architectures, Ontology terms do surface to the UI.

[rjyounes]

It's not anglo-centric to acknowledge that English is the de facto lingua franca in the worlds of business, finance, tech, industry, and academia, it's just a plain fact. I bet every professional ontologist has read the English texts on the subject.

Your final point is convincing, though, so I'll retract my disagreement.

[rjyounes]

Do we want to add @en or @en-us, so that our colleagues in the UK can use "Organisation"@en-gb?