W3C home > Mailing lists > Public > public-swd-wg@w3.org > October 2008

Re: SKOS comment [ISSUE-129]

From: Lourens van der Meij <lourens@cs.vu.nl>
Date: Fri, 31 Oct 2008 18:23:57 +0100
Message-ID: <490B3F2D.8040405@cs.vu.nl>
To: Sean Bechhofer <sean.bechhofer@manchester.ac.uk>
CC: SWD Working SWD <public-swd-wg@w3.org>

Dear Sean,

Thank you for considering my objection to certain disjunctness 
requirements of certain
skos Classes. I do still feel somewhat uncomfortable with the decision, 
though.
Sean Bechhofer wrote:
>
>
> Thank you for your comments [1,ISSUE-129]:
>            
> """
> A comment on
> "S9 skos:ConceptScheme is disjoint with skos:Concept "
>
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>
> Requires discussion.
>
> ------------------------------------------------
>
> As you discuss, in the SKOS data model, a concept scheme is viewed as 
> an aggregation of a number of Concepts and we have chosen to make 
> Concept and ConceptScheme disjoint. This does then require the 
> introduction of additional URLs to identify the scheme and the 
> concepts but we believe that maintaining a separation between the two 
> notions aids clarity and promotes interoperability.
To be honest, I do not really understand the reasoning here, there are 
Concepts and there is an aggregation of Concepts
defined by ConceptScheme objects. Indeed completely separate notions, 
but why would we want to force some exclusion
here? Is there some specific modeling you are afraid of skos modelers 
would do which you think would be objectionable but
that the restriction makes impossible? Ok, after internal discussion 
(with Antoine) there is at least one half way plausible
objection: If Concept and Conceptscheme were not disjunct then 
skos:broader relations could hold between two URIs
that are skos:ConceptScheme, and this could confuse modelers into 
thinking that skos:broader defined between
skos:ConceptSchemes has some other meaning (i.e. skos:isSubConceptSchemeOf)

In other words; I do think it could be ok if a URI, a thing, has 
multiple roles, completely independent from each other.

Ok, I am not an expert in ontology construction so, if it is common 
practice to add such restrictions for clarity, go ahead.
And indeed tools might get confused if they have to deal with rare cases.

This is really not important, though, I remain a teany bit unhappy.

Thanks for considering my objection,

lourens
>
> We propose to *close* this issue, making no change to the document. I 
> hope that you are able to live with this.
>
Received on Friday, 31 October 2008 17:25:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 31 October 2008 17:25:44 GMT