Re: use of skos:inScheme and rdf:type in SKOS modeling

Hello Alistair, Ed,

I'm glad to see that's pretty much in line with a mail (copied below) I had sent to Ed and Clay when we were discussing our LCSH mapping a while ago.
(I refrained myself from jumping in beforehand, for fear I would bias the debate ;-)

Note however that I would really recommend testing A only before (and in our own (non-LoC) experiments we'll implement the A approach A alone), at least in a first move, as the model and data more straightforward to deploy and consume (no dedicated ontoloy and reaoning). And B can be later deployed on top of it without breaking it.

Cheers,

Antoine

> Hi Ed,
> 
> If you use solution A (skos:inScheme) I would anticipate that a
> generic SKOS browser would recognise that there are a number of
> different schemes described in the data, and allow you to browse,
> search and do lint-like sanity checking on each independently.
> 
> If you use solution B (rdf:type) then you have classes declared which
> can be used in property axioms, e.g. domain or range assertions or
> other restrictions. This might be useful where you want to document
> usage and/or semantics for a set of metadata elements.
> 
> Not knowing the requirements in detail, I think I would do both A + B,
> with your additional workaround for B to avoid inferencing (adding the
> triple X rdf:type skos:Concept). This should give you a platform to
> explore the options.
> 
> For practical purposes this probably won't help, but you could also
> make an assertion that formalises the fact that both A and B are
> different ways of saying the same thing, e.g....
> 
> lcsh:TopicalConcept rdf:type owl:Class ;
>   rdfs:subClassOf skos:Concept ;
>   rdfs:subClassOf [
>     rdf:type owl:Restriction ;
>     owl:onProperty skos:inScheme ;
>     owl:hasValue lcsh:topicConceptScheme ;
>   ] ;
> .
> 
> ...which supports an inference from B to A. 
> 
> Actually, thinking about that again, if they really are different ways
> to say exactly the same thing, you'd probably want to assert...
> 
> lcsh:TopicalConcept rdf:type owl:Class ;
>   owl:intersectionOf (
>     skos:Concept ,
>     [ 
>       rdf:type owl:Restriction ; 
>       owl:onProperty skos:inScheme ;
>       owl:hasValue lcsh:topicConceptScheme ;
>     ]
>   ) ;
> .
> 
> ...which I think supports an inference from B to A and from A to B,
> although you might want to double-check my OWL.
> 
> Cheers,
> 
> Al
> 
=========================

To sum up, we've got two basic choices: 

1. What I've implemented so far, let's call it the "multiple-schemes" solution:
<http://lcsh.info/sh96009133#concept> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/2008/05/skos#Concept>.
<http://lcsh.info/sh96009133#concept> <http://www.w3.org/2008/05/skos#prefLabel> "Speed skaters"@en.
<http://lcsh.info/sh96009133#concept> <http://www.w3.org/2008/05/skos#inScheme> <http://lcsh.info/#conceptScheme>.
<http://lcsh.info/sh96009133#concept> <http://www.w3.org/2008/05/skos#inScheme> <http://lcsh.info/topicConceptScheme>.

2. What you seem to prefer, let's call it the "concept-subclass" option:
<http://lcsh.info/sh96009133#concept> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://lcsh.info/ontology#TopicConcept>.
<http://lcsh.info/sh96009133#concept> <http://www.w3.org/2008/05/skos#prefLabel> "Speed skaters"@en.
<http://lcsh.info/sh96009133#concept> <http://www.w3.org/2008/05/skos#inScheme> <http://lcsh.info/#conceptScheme>.

Note that there is a catch-all solution which is to implement both, and say that http://lcsh.info/ontology#TopicConcept is an equivalent class to the class of these instances of skos:Concept that are skos:inScheme http://lcsh.info/topicConceptScheme!

There a pros and cons for each of them:

1 in a way does the job out-of-the-box. It blurs a bit the concept scheme landscape, but in the end you know that you're in LCSH, and in which LCSH category you are, just looking at the raw RDF triples.

2 is conceptually better, I agree. But it has some drawbacks:
- it requires introducing a custom namespace and ontology for http://lcsh.info/ontology#TopicConcept. That's a minor drawback, and indeed for the work with Clay we're gonna create such an ontology. But the further problem is that:
- the distinction is not graspable anymore by standard SKOS tools. Using inScheme you can choose to display or search only one category at a time if you see fit, without requiring adaptation of the tool to read the subclass axioms and interpret your specifial concepts as denoting elementsfrom a specific part of LCSH;
- indeed the subclass trick is ontologically neutral wrt. the type distinction which is made. I could have well subclassed skos:Concept along a completely orthogonal dimension, e.g. something dummy like lcsh:ConceptCreatedIn2005. Using skos:inScheme denote creating vocabularies that do fit certain applications or views on the world.
- the ontology that specifies the subclass link has to be read and "applied" at some point, by running an RDFS engine or simulating it. Either we rely on the data consumer to do that, or we do it ourselves, by serving
<http://lcsh.info/sh96009133#concept> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://lcsh.info/ontology#TopicConcept>.
*and*
<http://lcsh.info/sh96009133#concept> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/2008/05/skos#TopicConcept>
whenever the description of http://lcsh.info/sh96009133#concept is requested.

Received on Monday, 2 February 2009 10:00:56 UTC