Re: SKOS profiles: Simple vs Structured

Hello

Le mer. 1 avr. 2020 à 10:48, Vladimir Alexiev <vladimir.alexiev@ontotext.com>
a écrit :

> 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.
>

This should probably be tackled in the context of the Content Negociation
by Profile : https://www.w3.org/TR/dx-prof-conneg/#getresourcebyprofile.
A client could request a resource in a specific profile using
"Accept-Profile" and the server can declare the profile of a representation
using "Content-Profile" :

# A request for resource a according to Profile x is made
GET /resource/a HTTP/1.1
Accept-Profile: <http://example.org/profile/x>

---

# The server returns a representation of Resource a conforming with Profile x
HTTP/1.1 200 OK
Content-Profile: http://example.org/profile/x

[response body]


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)
>
>
cf. Content Negotiation by Profile.
If the profile is expressed as a set of SHACL rules, then this Shapes URI
can probabaly be used as the value in the HTTP headers and as the value of
dct:conformsTo.

Cheers
Thomas



>
>    -
>
>    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
>


-- 

*Thomas Francart* -* SPARNA*
Web de *données* | Architecture de l'*information* | Accès aux
*connaissances*
blog : blog.sparna.fr, site : sparna.fr, linkedin :
fr.linkedin.com/in/thomasfrancart
tel :  +33 (0)6.71.11.25.97, skype : francartthomas