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

Re: ISSUE-160: Allowing collections in semantic relationships

From: Antoine Isaac <aisaac@few.vu.nl>
Date: Tue, 16 Dec 2008 18:54:46 +0100
Message-ID: <4947EB66.4000703@few.vu.nl>
To: Leonard Will <L.Will@willpowerinfo.co.uk>
CC: "public-swd-wg@w3.org" <public-swd-wg@w3.org>, "public-esw-thes@w3.org" <public-esw-thes@w3.org>


> 
>> And we have to deal with the fact that there are applications which 
>> are designed to consume SKOS data, which do not care about all the 
>> subtleties. We could have SKOS contain 100 model elements: Johan's [2] 
>> and Leonard's [3] mails, as well as the work in [4] perfectly 
>> illustrate that this could easily be reached, should we only consider 
>> ISO and the vocabularies Christophe mentioned. But in that case, 
>> should every SKOS implementation deal with all of them?
> 
> If we accept that SKOS cannot yet provide for all the elements of the 
> draft ISO model, it might nevertheless cover a subset of them, with the 
> possibility of others being developed later as time and resources permit.

Yes!

> 
> My concern is that at present it contains elements that conflict with 
> the model and which will give rise misunderstandings and confusion; e.g. 
> allowing node labels to be treated as concepts and using "collections" 
> in a vague way which does not correspond to either "arrays" or "concept 
> groups" in the ISO model.

If this is the case, that's a valid concern. But do you think that collections really distinct from node labels, or is it that collections are somehow more general than node labels?

> 
>> That's just not doable to require such a thing from implementers. At 
>> some point, we therefore would have to define a core --and the SWD 
>> working group has to do that itself, because otherwise future 
>> interoperability is ruined. And practically, this amounts to having a 
>> standard core vocabulary extended with application-specific profiles.
> 
> Rather than "application-specific profiles", which may diverge and 
> overlap, I would like to see any additional work being directed to 
> extensions which form an integral part of the format and which are in 
> accordance with the data model.

That's why it is important for us to keep a place where the SKOS community can gather and share idea and extensions. Eventually leading to an agreed-on "thesaurus application profile" (please do not beat me to death for this expression ;-) ) in a skos-xt namespace, related somehow to ISO work.

> Many of the elements of the model are 
> optional - they are allowed to have zero occurrences - so if not needed 
> for a particular application they do not have to be used.

That's trickier than that. Currently, *most* of the SKOS core constructs are optional, even prefLabel. But I would really not encourage applications to ignore them...


 
> I would like to see the data model extended to allow for faceted 
> classification structures and pre-coordinated subject indexing schemes, 
> and we may have to look at these when we start work on the draft of part 
> 2 of ISO 25964 next year. I do think that we have to get the model right 
> before starting to construct a format in XML, RDF or whatever.

This is rather different from our stance (at least from my own view on our approach ;-). If some parts of this ideal model are difficult to specify and agree on, and less often used, then it might be valueable (and equally "right") just to postpone them, and issue a model that catches the low hanging fruits. Especially when the model is still open for further extension.

> Any ideas on these would be most welcome, though as Antoine says a lot 
> of work lies ahead. Can I just remind folk of the fact that the Bliss 
> Classification Association has a small amount of money that might be 
> made available for a project in this area - see:
> <http://lists.w3.org/Archives/Public/public-esw-thes/2008Oct/0033.html>

Thanks for the pointer, I had indeed missed it :-/

Antoine
Received on Tuesday, 16 December 2008 18:44:41 GMT

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