W3C home > Mailing lists > Public > public-esw-thes@w3.org > February 2008

[SKOS] Re: TR : Broader, collections and the difference between SKOS and OWL

From: Antoine Isaac <aisaac@few.vu.nl>
Date: Mon, 18 Feb 2008 15:59:47 +0100
Message-ID: <47B99D63.2090301@few.vu.nl>
To: SWD WG <public-swd-wg@w3.org>, SKOS <public-esw-thes@w3.org>

Dear Simon, Michael (I'm forwarding this thread to the SWD list as well)

Thanks for the discussion!

Notice that Simon's items 1-2-3 overlaps with the discussions the SWD 
working group is about to conclude on in the coming days.
http://lists.w3.org/Archives/Public/public-swd-wg/2008Feb/0053.html

To sum up, we say that some SKOS concept can be also considered as RDFS 
classes but this is not always the case, some skos Concepts will not be 
RDFS classes. This can be confusing but we have to deal with 
applications which have different requirements.

The fundamental understanding of skos:Concept is the one underlying the 
metamodelling thoughts of the old SKOS Guide [2]
SKOS Concepts are defined in a quite pragmatic way: as the SKOS 
Reference [2] puts it,

> A conceptual resource can be viewed as an idea or notion; a unit of 
> thought. However, what constitutes a "unit of thought" is subjective, 
> and this definition is meant to be suggestive, rather than restrictive.
>
> The notion of a conceptual resource is useful when describing the 
> conceptual or intellectual structure of a knowledge organization 
> system, and when referring to specific ideas or meanings established 
> within a KOS.
>

So SKOS concepts are representation of things in a conceptual 
vocabulary. In this repect, I guess they are similar to the Subject 
Terms of Svenonius. Except that I don't get it when you say that this 
make them fundamentally different from "concepts" :-( What is a concept 
for you, that would make it essentially incompatible with the idea of a 
subject? To me it is rather the notion of Term that is not adapted here: 
a term is essentially linked to (a specific) natural language, while a 
"concept" can be abstracted (at least a bit) from it, consider for 
instance classes in classification schemes.

But this is for the fundamental interpretation. It happens that some 
applications require these concepts/subjects to be considered also as 
RDFS classes, with extension relating to individual in the "real world" 
(as in the triple: ex:simon rdf:type ex:Person).
Now, as Michael puts it, this stance allow for having mixes of 3 and 1 
(see mail below). Honnestly I'm not sure that what this would mean in 
terms of interpretation for such mixed objects. For the moment it would 
be up to individual application designers to cope with such problems if 
they decided to mix SKOS and OWL worlds.
Alistair and I had actually gathered some proposals to link 
concept/subject to classes while keeping them distinct, but they did not 
really provoke huge enthusiasm in SWD crowds. But there will be more 
discussion on that when we'll have time to cope with ISSUE-80 [5]

Note that I would however consider that the mixing stops here, that is, 
between Michall's 1 and 3 solutions: I disagree with considering 2, or 
at least with the following assumption that Michael makes

> In the above model:
>
> Doc_A is indexed as A     <=>   Doc_A rdf:type A
> Doc_B is indexed as B     <=>   Doc_B rdf:type B

Let me clarify: to me it is also clear that concept/subject can be 
associated to some sort of extension, namely the documents that have 
them as subject. But such a link should be represented by a proper 
property (skos:subject or dc:subject) and not by rdf:type. So, SKOS 
concepts are not essentially RDFS/OWL classes.
Notice that my argument would be more practical than formal : it's just 
because people have started to use rdf:type in a categorial way. If 
ex:bible has to be linked via rdf:type to a class related to the idea of 
religion, SW designers would expect it to be ex:ChristianBook rather 
than ex:Christianism.
Or with another example, if you have ex:Wheel which is both an OWL class 
and a SKOS subject, you would expect it to participate in the following 
triples that I hope will make some sense (I really don't have time to 
write a lot these days)
- ex:theBookOfWheels skos:subject ex:Wheel
- ex:theLeftFrontWheelOfMyCar rdf:type ex:Wheel
But I will stop here, there was a lot of discussion (cf references of 
[3]) in the past years over this on the SKOS list...

Best,

Antoine

[1] http://www.w3.org/TR/swbp-skos-core-guide/#secmodellingrdf
[2] http://www.w3.org/TR/skos-reference/#L1289
[3] http://www.w3.org/2006/07/SWD/wiki/SkosDesign/ConceptSemantics
[4] http://www.w3.org/TR/skos-reference/#skos-owl-patterns
[5] http://www.w3.org/2006/07/SWD/track/issues/80

>
>
>
> -------- Message d'origine--------
> De: public-esw-thes-request@w3.org de la part de Mikael Nilsson
> Date: lun. 18/02/2008 09:13
> : Simon Spero
> Cc: SKOS
> Objet : Re: Broader, collections and the difference between SKOS and OWL
>
>
> Simon,
>
> SKOS does indeed lack a theoretical foundation, I'm glad you proposed
> one! If a theory is agreed upon, the theory can be used to answer many
> of the difficult questions we're asking.
>
> I don't fully agree with the path your model took, so let's see where I
> land when I try...
>
>
> fre 2008-02-15 klockan 18:04 -0500 skrev Simon Spero:
> >
> > 3: The extension of a SKOS Concept is the set of all documents which
> > have that SKOS Concept as a subject; compare with the definition of an
> > rdfs class in RDF Semantics (Hayes 2004)
>
> I have sympathy with this model. This would make skos:Concepts also
> rdfs:Classes (i.e. skos:Concept rdfs:subClassOf rdfs:Class), something
> that has been avoided to far.
>
[...]
>
>
>
>
> This is all very interesting. We can model a skos:Concept as one of a
> number of entities in this world. Think of the skos:Concept "Wheels".
> Here are a few options:
>
> 1 "Wheels" is the set of wheels. This is the OWL approach, and not taken
> by SKOS.
> 2 "Wheels" is the set of documents indexed by "Wheels" (my approach
> above).
> 3 "Wheels" is a Subject, disjoint from the two above, but with
> relationships to both of the above classes. This is Simon's approach.
>
> I think both 2 and 3 work. 2 is simpler, but suffers from being closely
> intermingled with RDF schema.
>
> The most critical thing is that we choose *one* of the models and stick
> with it. In the above, I've tried to explain where I believe Simon
> starts mixing 3 and 1, and I think that's really counterproductive. Keep
> the entities disjoint.
>
> Sorry, this reply didn't turn out as readable as I had hoped. Hope
> someone finds a use for it :-)
>
> /Mikael
>
Received on Monday, 18 February 2008 14:59:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:38:59 GMT