Better support for structured/reified definitions

[osma]

Skosmos has some basic support for reified definitions used in e.g. AGROVOC and GACS, but only enough that it shows the rdf:value of the definition. It doesn't show any extended metadata such as source.

Examples:
http://skosmos.dev.finto.fi/agrovoc/en/page/c_8601
http://tester-os-kktest.lib.helsinki.fi/gacsdemo/gacs/en/page/C8994

The definition should be shown not as a link, but as regular text. The extra metadata such as dc:source could be shown inline, for example only visible when hovering, similar to help texts.

[osma]

GACS example now on the Skosmos demo site: http://skosmos.dev.finto.fi/gacs/en/page/C8994

[VladimirAlexiev]

SKOSXL recommends structured labels to be published redundantly: as plain SKOS labels and as skosxl:Label.

But neither SKOS nor SKOSXL define separate properties for structured notes. (Also, there is no class defined, that's why in Getty AAT we defined gvp:Note).

So if you want to publish notes with a similar redundancy (for both simple consumers and "structured" consumers), skos:definition and friends would carry both a string, and a resource, which will complicate consumption. @osma, has that bothered you?

@osma Does Skosmos do label matching? Eg for this below, will it show the label just once?

<concept> skos:note "foo", [rdf:value "foo"; dct:issued "2020-03-30"]

Where does it display the language from? Getty follows the good practice of putting lang in a separate field so it can be filtered more efficiently, eg:

<concept>
  skosxl:prefLabel [skosxl:literalForm "foo"@en; dct:language lexvo:en]
  skos:note [rdf:value "bar"@en; dct:language lexvo:en]

[osma]

So if you want to publish notes with a similar redundancy (for both simple consumers and "structured" consumers), skos:definition and friends would carry both a string, and a resource, which will complicate consumption. @osma, has that bothered you?

Skosmos supports both styles (either a literal value or a resource with rdf:value), but assumes that only one of them is used.

@osma Does Skosmos do label matching? Eg for this below, will it show the label just once?
skos:note "foo", [rdf:value "foo"; dct:issued "2020-03-30"]

I tested this - it does not eliminate duplicates in this case. Example that shows the result when both a literal and a resource are used as a note value:

This has not been a problem for us since the vocabularies we have use either pattern but not both at the same time.

Where does it display the language from? Getty follows the good practice of putting lang in a separate field so it can be filtered more efficiently, eg:

The language is taken from the literal value. I see the point of using a separate field, but none of our vocabularies do that.

[VladimirAlexiev]

both styles (either a literal value or a resource with rdf:value), but assumes that only one of them is used.

I think that's reasonable, "duplicate label matching" is too complicated to expect that consumers will do such a thing.

Then @osma what does Skosmos do with labels? Will it display duplicate labels in this case:

<concept> skos:prefLabel "foo"@en; skosxl:prefLabel [skosxl:literalForm "foo"@en]

(I never thought More could be Bad. Until I miscalculated the amount of concrete needed for my yard pool... When the concrete pump arrived, I had to scramble to build two more yard features with the leftovers ;-)

@illip please read above and could you add that to Nomenclature API discussion? It presents a problem: if we go with literal Definitions now but make structured Definitions later (when we publish SKOSXL), that will be a backward-incompatible API change. I now think we should have two different API models: simple vs structured.

[VladimirAlexiev]

Added section Non-functional> Backward Compatibility

[osma]

Then @osma what does Skosmos do with labels? Will it display duplicate labels in this case:
skos:prefLabel "foo"@en; skosxl:prefLabel [skosxl:literalForm "foo"@en]

Skosmos requires SKOS Core labels in any case (for example due to the jena-text index). SKOS XL is an optional extra. This case works fine - duplicates are eliminated. See e.g. AGROVOC which has both SKOS Core and SKOS XL labels: http://skosmos.dev.finto.fi/agrovoc/en/page/c_32624

[VladimirAlexiev]

Posted proposal for SKOS Profiles: https://lists.w3.org/Archives/Public/public-esw-thes/2020Apr/0000.html