W3C home > Mailing lists > Public > public-swd-wg@w3.org > December 2007

Re: [SKOS] Reference abstract and synopsis

From: Antoine Isaac <aisaac@few.vu.nl>
Date: Fri, 14 Dec 2007 00:19:41 +0100
Message-ID: <4761BE0D.5020109@few.vu.nl>
To: "Miles, AJ \(Alistair\)" <A.J.Miles@rl.ac.uk>
CC: public-swd-wg@w3.org

Hi Alistair,
>> - semantic conditions (general) I've got a big remark there, 
>> coming in my reply to Quentin. Notice that it is valid for 
>> transitivity of skos:broader, but also similarly applies to 
>> disjointness of skos:Concept and owl:Class. I really think 
>> you should clarify what you mean by "interpreting" there. To 
>> me, it should not be asserting triples changing the semantics 
>> of SKOS constructs.
> Do you mean that you think the SKOS Reference should say things like, "do not assert x y z..."?
> If that is what you mean, then I don't think you can prevent anyone from asserting triples. 

No. I just count on the fact that if nothing is said about x y z then 
knowing that x and z are from a standard vocabulary people will not add 
their own axioms.
Consider that I want to use skos:Concept to model classes from a subject 
heading list: will I add the triple skos:Concept rdfs:label "Heading" in 
my vocabulary? I guess I would create my own subclass of skos:Concept, 
and do it what I like with it.

I would expect people to do the same for these 
concepts-which-are-classes. If nothing is said in the SKOS reference 
that says that Classes and Concepts are disjoint, then if I need the 
aformentioned thing I will just create it as a subclass of both 
skos:Concept and owl:Class.
I expect that sensible modelers will infer that if SKOS does not say 
that skos:Concept is a subClassOf owl:Class, it's because it is not true 
in absolute, and there are therefore somewhere concepts which are not 
classes. And therefore they should not overload the standard SKOS 
vocabulary. But perhaps that's too optimistic

> All I think you can do is put semantic conditions in the normative specification which would make certain statements inconsistent with the normative semantics.
> E.g. if you *don't* want people to say
> skos:Concept rdfs:subClassOf owl:Class.
> then you have to put something in the normative semantics which would make the statement inconsistent, e.g. 
> skos:Concept owl:disjointWith owl:Class.

I think this is going way to far, especially if we are already aware 
that somewhere in the world there will be concepts that are also classes.

> I think you have to accept that people can make any statement whatsoever which is consistent with the normative semantics, and still "conform" to the standard.

Well there is always this problem of implicit modelling, especially when 
it is about thing that cannot easily be represented in OWL.
Anyway, the initial problem is really about wording: I think whenever 
you say something like:

> interpreting skos:Concept as a sub-class of owl:Class would be 
> consistent with the SKOS semantics

I would prefer something like "having instances of skos:Concept treated 
as instances of owl:Class would be consistent with the SKOS semantics", 
or, better, "skos:Concept and owl:Class are not disjoint". This capture 
what is needed for the patterns we want to allow, while not encouraging 
people to make weird statements.

>> - semantic (paradigmatic) relations. I still don't get why 
>> the semantic relationship would be "paradigmatic". Or more 
>> precisely, why labelling properties or documentation 
>> properties would not be paradigmatic as well. But that's just 
>> a detail ;-)
> The term "paradigmatic" comes from the BS 8723 standard. "Paradigmatic" relations, which are inherent in the meaning of concepts, are distinguished from "syntagmatic" relations, which occur when two concepts are both subjects of the same document (if I've remembered correctly :).
> If "paradigmatic" is not helpful to the wider community then I'm happy to drop it.

Well I'm now starting to feel like using it sometime ;-)


Received on Thursday, 13 December 2007 23:19:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:31:46 UTC