W3C home > Mailing lists > Public > public-esw-thes@w3.org > November 2006

Re: SKOS without OWL

From: Jakob Voss <jakob.voss@gbv.de>
Date: Tue, 14 Nov 2006 14:28:44 +0100
Message-ID: <4559C48C.5010701@gbv.de>
To: SKOS <public-esw-thes@w3.org>

Antoine, Bernard - thanks for you feedback!

Antoine wrote:

>>> 1. Transitivity
>>> skos:broader and skos:narrower are defined as transitive. In my
>>> point of view this is just an error of design in SKOS because 
>>> if you inference the transitivity rule, your full tree of concepts
>>> gets expanded. This is not suitable for common retrieval tasks
>>> where you only want to expand to certain depth (please correct
>>> me if I am wrong). Your application needs to expand skos:broader
>>> and skos:narrower depending on rules that are independet from OWL
>>> anyway.
>> Well, yes and no. Seems to me that all hierarchies of index, thesauri,
>> classification schemes ... are implicitly transitive. 
> I encountered cases where it is not. Still I believe that it could be
> useful to have a version where this property is not transitive, and an
> extension offering a transitive version (superproperty, or different
> 'dialect', as for OWL). But this should be discussed, of course.

Good idea! In [1] skos:borader, skos:narrower and skos:related are
subproperties of skos:semanticRelation. There should be two new
properties in between:

skos:narrower  rdfs:subPropertyOf  skos:descendant.
skos:broader   rdfs:subPropertyOf  skos:ancestor.

with skos:ancestor and skos:descendant beeing transitive instead of
skos:broader and skos:narrower. So if you do OWL reasoning you don't
loose all the information which Concepts were *directly* related to each
other but you can also get the transitive closure with skos:descendant
and skos:ancestor.

The same applies to skos:subject and the Subject Generality Rule. With
inference you loose the possibility to rank result depending on whether
they are directly indexed with a concept or indirect with a concept that
is descendant of the concept you are searching for.

I'd propose two new properties skos:indexedWith and skos:indexes with:

skos:indexedWith  rdfs:subPropertyOf  skos:subject.
skos:indexes      rdfs:subPropertyOf  skos:isSubjectOf.

So we can keep the Generality Rule for skos:subject but it does not
apply for skos:indexedWith and skos:indexes.

I don't know if the Generality Rule also applies for
skos:primarySubject, this is not clear in the spec. As far as I
understand it skos:primarySubject should be a subproperty of

Here is an EXAMPLE:

Let "c:" be your KOS namespace with:

c:asia   skos:narrower  c:china.
c:china  skos:narrower  c:beijing.

And let "book:" be your namespace of records:

book:C  skos:indexedWith  c:china.
book:B  skos:indexedWith  c:beijing.

With inference you also get:

book:C  skos:subject  c:china.
book:C  skos:subject  c:asia.
book:B  skos:subject  c:beijing.
book:B  skos:subject  c:china.
book:B  skos:subject  c:asia.

c:asia   skos:descendant  c:china.
c:asia   skos:descendant  c:beijing.
c:china  skos:descendant  c:beijing.

1. You can retrieve all books about Chinese topics (including Bejing-books):

?B skos:subject c:china

2. You can retrieve all books about China in general (no Bejing-only-books):

?B skos:indexedWith c:asia

3. You can build a tree of concepts narrower than asia (first level:
China, second level Bejing)

?C skos:narrower c:asia
?C skos:narrower c:china

4. You can build a set of concepts under asia (China and Bejing mixed

?C skos:descendant c:asia

Without the new properties you can only do 1. and 4. (inference) or 2.
and 3. (no inference).

>>> PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
>>> PREFIX owl:  <http://www.w3.org/2002/07/owl#>
>>> CONSTRUCT    { ?x ?p1 ?y }
>>> WHERE        { ?y ?p2 ?x. ?p1 owl:inverseOf ?p2 }
>>> For this action you don't have to know anything about OWL.
>>> owl:inverseOf is just a property that is identified by an URI.
>> Right
> I agree that this does the trick, but still am really not convinced of
> the interest of encoding these semantics (at the level of a
> recommendation) in SPARQL queries. OWL specification is by far more
> interoperable (where do you publish this query? How do you link it to
> the SKOS properties which are inverse of each other?) and even in this
> case, clearer (why would users like to deal with all these variables?).

Right - the SPARQL query is just an implementation, not the
specification. I wanted to show that up to now you *cannot* use OWL with
inference (because transitivity will destroy information about
hierarchical relations that is probably needed for retrieval) but you
also don't have to use OWL because you can easily implement the
reasoning yourself.

> Of course I understand that the point in this solution is to avoid using
> an OWL reasoner, and therefore there is practical relevance. However,
> I'm really far from convinced that a SKOS recommendation should advice
> people to systematically - as you say it - emulate OWL reasoning by
> systematically completing the data they have with SPARQL construct
> queries.

The spec should define SKOS in a way that lets you use OWL reasoning or
implement the needed rules without OWL. To my impression [2] does this
but as shown above there are new properties needed and rules to be changed.


[1] http://www.w3.org/TR/2005/WD-swbp-skos-core-spec-20051102
[2] http://www.w3.org/TR/2005/WD-swbp-skos-core-guide-20051102
Received on Tuesday, 14 November 2006 13:29:06 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 13:32:07 UTC