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

Re: ISSUE-160: Allowing collections in semantic relationships

From: Aida Slavic <aida@acorweb.net>
Date: Tue, 16 Dec 2008 08:51:49 +0000
Message-ID: <49476C25.4010102@acorweb.net>
To: Antoine Isaac <aisaac@few.vu.nl>
CC: Leonard Will <L.Will@willpowerinfo.co.uk>, "public-swd-wg@w3.org" <public-swd-wg@w3.org>, "public-esw-thes@w3.org" <public-esw-thes@w3.org>

Antoine,

> To pick a concrete example, in a previous mail you said that node labels 
> from ISO-25964 were actually not entirely captured by skos:Collection. 
> OK, but then if we follow this path, we have to add another class to our 
> model, and maybe a couple of additional properties. This would make the 
> SKOS model more complex, for dealing situations which I believe are not 
> that common (at least compared to the variety of KOSs outside there), 
> and therefore could turn to be counter-productive.

It would be very important that you explain why is complexity counter productive 
in the case of SKOS. Who are intended SKOS users?

 From the point of view of interoperability it may be better (cheaper and 
easier) if people have to simplify a complex format than if we all have to 
extend dumbed down formats. If more classes are needed by an entire community of 
users then it is far better that these classes are added by SKOS developers than 
by users.
Standards have also power of introducing and instructing about a good practice.

So far SKOS is not created to port any of existed structured vocabulary in its 
completeness and for each of existing vocabularies there would be need to make 
extensions in order to prevent data loss. Thesaurus, having a simplest 
structure, is the one that seems to be the closest to be fully supported by 
SKOS. I see many advantages in having at least one type of vocabulary for which 
there is no need to develop extensions.

Aida
Received on Tuesday, 16 December 2008 08:52:40 UTC

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