- From: Danny Ayers <danny.ayers@gmail.com>
- Date: Fri, 20 Aug 2004 19:53:26 +0200
- To: "Miles, AJ (Alistair)" <a.j.miles@rl.ac.uk>
- Cc: "public-esw-thes@w3.org" <public-esw-thes@w3.org>
> This one of the strongest requirements as yet not supported by SKOS Core, so > I thought I'd try to move this along by making a concrete proposal. This > proposal seems very vocab heavy (i.e. lots of new constructs) so feel free > to shoot this down, or come back with some better names for the suggested > constructs. One or two first impressions, please take lightly. The use of a collection rather than a container seems a good idea, if for no better reason than the containers can confuse by sounding like membership entails more than it does. But I think there is a better reason, that it should be straightforward to interface with this kind of construct programmatically for systems without much RDF/OWL support - e.g. mapping to Java Collections - Sets/Lists (clarification over whether duplicate items can appear might be an idea - I presume not, as there is by definition a division between individual items). Most of the constructs aren't really tied to Concepts, it might be worth considering breaking these out into another namespace as a utility vocabulary, perhaps having skos:inCollection and skos:viewUnder as specializations of properties with a more general domain/range. I'm not sure - might the collections be useful elsewhere in SKOS, say for expressing lists of top concepts? Another thing caught my eye, but I don't know if it would be significant to anyone that actually knows something about thesauri ;-) The label of the collection in your example: "Aircraft by function" (a node label or guide term, the Wiki tells me). The 'characteristic of division' seems quite important here, maybe 'function', 'form' or whatever could somehow be stated more explicitly, perhaps as a reference to a skos:Concept with the label 'function' or 'form'. Cheers, Danny.
Received on Friday, 20 August 2004 17:53:28 UTC