Feature request: Displaying skos:notation with data type in UI

[nikokaoja]

In many domains, for example wind energy, labels for controlled terms are often sourced from multiple standards established by an international organization such as IEC or IEA.

All these labels representing the same concept should find their place in a well-curated ontology and should be easy/clearly distinguished and ideally well represented in SKOSMOS UI.

Following the discussion in #1085, @osma suggested, and I agree very much, that the cleanest way to deal with is to use skos:notation and define custom data type to annotate its literal values. An example a term wind_speed which has a specific label in a standard IEC61400-25-2 can be represented in RDF as:

wep:wind_speed a skos:Concept;
    skos:prefLabel "wind_speed"@en;
    skos:notation "HorWdSpd"^^wep:IEC61400_25_2 .

# define the data type
wep:IEC61400_25_2 a rdfs:Datatype ;
    rdfs:label "IEC61400"@en .

Currently SKOSMOS does not display skos:notation nither the data types that are attached to their literal values.
Having this feature would increase usability in SKOSMOS when serving controlled terms which include lables/notations from multiple standards.

[osma]

I think this is closely related if not identical to #627 ?

[osma]

Please see this thread on skosmos-users for some quick fixes to display the notation codes (though not the data types).

[nikokaoja]

@osma it is! As we discussed in #1085, displying of notations would be great to have!
I have been having this request by several domains.

Until skos:notation display in SKOSMOS is added, I defined several special RDF properties to mimic skos:notation.

[osma]

There are a few things to do to make this happen:

1. Add the missing translations for the skos:notation property (as discussed in the skosmos-users thread)
2. Since we probably don't want to show the notation code for classifications like DDC, implement a vocabulary-specific configuration setting such as skosmos:showNotation to control whether they are shown as regular properties on the concept page or not
3. Adjust the concept-shared.twig template to display the data type for notations (this may require adjustments to the SPARQL query as well if we want to show the label of the data type, not just the URI)

Doesn't seem like hugely difficult steps. Are you by any chance interested in contributing a PR to address at least some of the above? Just step 1, adding the translations, would be a start.

[nikokaoja]

@osma I would be up for contributing, however I am not a PHP user, therefore would need some help and pointers what and how should I modify source code.

[nikokaoja]

@osma maybe I misunderstood your request, what do you mean under "contributing a PR" ?

[osma]

See e.g.
https://www.dataschool.io/how-to-contribute-on-github/
https://git-scm.com/book/en/v2/GitHub-Contributing-to-a-Project

So basically making a modification to Skosmos codebase (not necessary PHP code) and turning it into a pull request so it can be discussed, improved and eventually merged. See e.g. PR #1113

[nikokaoja]

Ok, so I did indeed understood it correctly, and read PR as a contribution to code base (as someone who is using GitLab in work I have tendency to call this merge request), and not to Public Relations (PR). I am familiar with Git workflow, so no prob.