Handling several skos:notations on a same concept

[joelit]

Description of the enhancement

Currently Skosmos supports showing a single notation code for a concept. If we had two notation codes on the same concept, the behavior in Skosmos is not defined.

Who are the users that would benefit from the enhancement and how?

The feature is speculative in a way that such a situation is specified in the SKOS documantation, but we don't have a use case for it yet.

What new functionalities would the enhancement make possible?

We could have a SKOS browser that supports SKOS data structures!

The question remains, how to show an arbirary number of notation codes next to the concept label both in the title of a concept page and in the sidebar, like alphabetical listing and hierarchy views.

It is also possible to arrange concepts in an ordered list according to notation code, but we would need to specify how to handle the case of several notation codes on one concept.

Why is the enhancement important?

It is a SKOS feature we don't currently have support for.

[cmutel]

A concrete use case: We at Départ de Sentier are trying to build a common vocabulary for sustainability assessment. One core part of that work is bringing sanity to units, which are now commonly just strings (and of course not consistent).

There are a lot of unit systems with their own codes, so we would have something like:

<https://vocab.sentier.dev/qudt/unit/KiloGM>
  skos:prefLabel "kilogram"@en ;
  skos:notation "0112/2///62720#UAA594"^^qudt:iec61360Code, "KGM"^^qudt:uneceCommonCode, "kg"^^qudt:ucumCode, "kg"^^qudt:symbol, "0112/2///62720#UAD720"^^qudt:iec61360Code ;
  a skos:Concept .

Showing the notation in the hierarchy is amazing, but the user experience right now is not great:

The question remains, how to show an arbirary number of notation codes next to the concept label both in the title of a concept page and in the sidebar, like alphabetical listing and hierarchy views.

This is fundamentally hard; having the ability to specify which notation datatype to use in the title and sidebar would already be a huge advancement, and is much easier.

It is also possible to arrange concepts in an ordered list according to notation code, but we would need to specify how to handle the case of several notation codes on one concept.

IMHO this is also quite hard, or at least a large chunk of work; small improvements when multiple notations are present are probably enough to make groups like us happy.

@jsvgoncalves FYI

[joelit]

Thanks!

I'll bring this up in our next notation code support session for Skosmos 3.0. Your suggestion that we go forward with defining which datatype of a notation to show sounds like the wisest first step. It would not solve the case where there might be several notation codes with the same datatype, but at least this would be a good start.