SKOS profiles: Simple vs Structured

Hi!

Skos is provided in one of two formats (profiles):

   -

   Simple (SKOS)
   -

   Structured (SKOSXL <https://www.w3.org/TR/skos-reference/#xl>+Advanced
   Documentation Features
   <https://www.w3.org/TR/skos-primer/#secadvanceddocumentation> with
   metadata/provenance props). "Documentation" means notes, definitions, etc

It's a common practice to publish "structured" with redundancy, to cater to
both "simple" consumers and "structured" consumers:

   -

   SKOSXL recommends structured labels to be published redundantly: as
   plain SKOS labels and as skosxl:Label. Dumbing-Down to SKOS Lexical
   Labels <https://www.w3.org/TR/skos-reference/#L780> defines how to
   provide structured and plain labels together.
   -

   Not sure about notes, as neither SKOS nor SKOSXL defines a class Note
   (Getty defines gvp:Note), nor separate properties. So skos:definition and
   friends would carry both a string and a resource, which will complicate
   consumption.


Currently a SKOS dataset or API does not have a way to declare its profile.
https://github.com/NatLibFi/Skosmos/issues/477 describes some troubles
related to this:

   - Skosmos uses "duplicate label matching logic" to display the label
   below just once, and assumes label redundancy.

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

   - However, there is no similar logic for notes, so it would display
   labels in duplicate.


To avoid complicated duplicate matching logic at the consumer, I think we
should define two SKOS profiles: simple vs structured.

   - Should "structured" subsume "simple", i.e. redundantly provide the
   same strings as simple labels/notes? That will simplify life for data
   providers
   - Do we need the two aspects separately: structured labels vs structured
   notes?
   -

   The profile should be communicated:
   -

      In HTTP request: client should be able to request "simple" or
      "structured"
      -

      In HTTP response
      -

      In the description of ConceptScheme and VOID/DCAT Dataset (property
      dct:conformsTo)
      -

   ConceptSchemes should provide completeness guarantees: if one label or
   note is structured, then all labels respectively notes are available as
   structured. I think these SPARQL tests should be used:
   -

      Some SKOSXL label exists:

<scheme>
^skos:inScheme/(skosxl:prefLabel|skosxl:altLabel|skosxl:hiddenLabel) ?label

   -

   Some skos:definition or skos:scopeNote is non-literal. I exclude:
   skos:changeNote, skos:historyNote, skos:editorialNote because these may be
   structured without the "business payload" notes being structured;
   skos:example because conceivably it can point to a resource; skos:note
   because that's a super-prop of excluded props (but many people use it
   directly, so I'm not sure):

<scheme> ^skos:inScheme/(skos:definition|skos:scopeNote) ?definition

Assuming subsumption/redundancy (that "structured" includes "simple") and
that the client can use SPARQL then "duplicate matching" can be done easily
in SPARQL. Eg something like this:

select ?lab ?prop ?propLabel ?metadata {

  <concept> skos:prefLabel ?lab.

  optional {

    <concept> skosxl:prefLabel ?label.

    ?label skosxl:literalForm ?label; ?prop ?metadata

    filter (?prop != skosxl:literalForm)

    optional {?prop (rdfs:label|skos:prefLabel) ?propLabel} # need lang
preferencing here!

  }

}


select ?def ?prop ?propLabel ?metadata {

  <concept> skos:definition ?def.

  optional {

    <concept> skos:definition ?definition.

    ?definition rdf:value ?def; ?prop ?metadata

    filter (?prop != rdf:value)

    optional {?prop (rdfs:label|skos:prefLabel) ?propLabel} # need lang
preferencing here!

  }

}

Are there any takers to formalize SKOS profiles?
-- 
Vladimir Alexiev, PhD, PMP
Chief Data Architect
Sirma AI, trading as Ontotext: https://www.ontotext.com, LinkedIn
<https://www.linkedin.com/company-beta/208070>, Twitter
<https://twitter.com/ontotext>, Rate GraphDB
<http://www.capterra.com/database-management-software/reviews/157533/Graph%20DB/Ontotext/new>
Email: vladimir.alexiev@ontotext.com, skype:valexiev1
Mobile: +359 888 568 132, SMS: 359888568132@sms.mtel.net
Calendar:
https://www.google.com/calendar/embed?src=vladimir.alexiev@ontotext.com
Publications and CV: https://github.com/VladimirAlexiev/my