W3C home > Mailing lists > Public > public-esw-thes@w3.org > October 2004

Re: Options for ordered/labelled collections

From: Dave Reynolds <der@hplb.hpl.hp.com>
Date: Wed, 06 Oct 2004 11:41:18 +0100
Message-ID: <4163CBCE.9070709@hplb.hpl.hp.com>
To: "Miles, AJ (Alistair) " <A.J.Miles@rl.ac.uk>
Cc: "'public-esw-thes@w3.org'" <public-esw-thes@w3.org>, "Dan Brickley (E-mail)" <danbri@w3.org>

Hi Al,

I haven't thought about this deeply enough to pretend I have the right 
answers, this is all just opinion.

As far as I can see you are already proposing to define the interaction 
between skos:Collection and skos:narrower etc in the form of inference 
rules. So in that case I would be inclined to to define skos:member as 
something that is inferrable so that the duplication is not required 
(but not banned either).

 > (1) Should we remove the 'skos:member' property from this proposal?

It would be inclined to leave it in. And define an inference rule for 
deriving it:

   (?collection skos:memberList ?l), elementOfList(?e, ?l) ->
             (?collection skos:member ?e)

Where the predicate elementOfList does the obvious thing.
[At the moment Jena rules don't support anything like elementOfList 
cleanly enough to do this - for an actual implementation you would use 
the listMapAsObject builtin but the implementation shouldn't sully the 

That way the duplication is not required in the source data but can 
optionally be added and in any case processing tools can assume that it 
is derivable.

 > (2) If we do remove 'skos:member', how should we express the fact that a
 > collection is ordered or not?

In any case I think that should be done by having an OrderedCollection 
class (as a subclass of Collection) or something similar. If you don't 
do this then the open world assumption bites (you can't infer that a 
Collection without a memberList is unordered because you might just have 
not found the memberList triples yet). Most of skos processing is 
probably closed-world anyway so this is not a practical issue but it 
seems slightly nicer to not have the specs overtly dependent on 
closed-world reasoning where they don't have to be.

 > (3) Is there value in the 'skos:CollectableProperty' suggestion?

Seems reasonable to me at first glance but I haven't thought about it 


Miles, AJ (Alistair) wrote:

> Hi Dave, Dan, all,
> Can I get some feedback and a sanity check on the options for a collections
> proposal for SKOS Core, in light of the recent discussion at the Bristol
> SWAD-E meeting ...
> The most recent proposal [1] is for two new classes 'skos:Collection' and
> 'skos:CollectableProperty' and two new properties 'skos:member' and
> 'skos:memberList', to be used as in:
> <skos:Concept rdf:about="c1">
> 	<skos:prefLabel>Aircraft</skos:prefLabel>
> 	<skos:narrower>
> 		<skos:Collection>
> 			<rdfs:label>aircraft by size</rdfs:label>
> 			<skos:member rdf:resource="c10"/>
> 			<skos:member rdf:resource="c11"/>
> 			<skos:member rdf:resource="c12"/>
> 			<skos:memberList rdf:parseType="Collection">
> 				<skos:Concept rdf:about="c11"/>
> 				<skos:Concept rdf:about="c10"/>
> 				<skos:Concept rdf:about="c12"/>
> 			</skos:memberList>
> 		</skos:Collection>
> 	</skos:narrower>
> </skos:Concept>
> Under this proposal, whether or not the members of the collection are
> ordered is inferred from the presence of absence of a 'skos:memberList'
> property.
> The point of 'skos:CollectableProperty' is to support the rule: 
> (x,p,c) (c,skos:member,m) (p,rdf:type,skos:CollectableProperty)
> ->
> (x,p,m)
> ... so e.g. 'skos:narrower' would be declared a 'skos:CollectableProperty'.
> Discussion
> ---
> The design of this proposal was in part motivated by the current limitations
> of RDF query languages and rule languages.  However, Dave R. has suggested
> that we should not make design decisions based on current technological
> limitations.  Under Dave's suggestion, there is no need for a 'skos:member'
> property ... the 'skos:memberList' is sufficient.
> So the questions I have are:
> (1) Should we remove the 'skos:member' property from this proposal?
> (2) If we do remove 'skos:member', how should we express the fact that a
> collection is ordered or not?
> (3) Is there value in the 'skos:CollectableProperty' suggestion?
> (4) Any other comments on name/form of the new terms in this proposal?
> Thanks,
> Al.
> [1] http://lists.w3.org/Archives/Public/public-esw-thes/2004Aug/0082.html
> ---
> Alistair Miles
> Research Associate
> CCLRC - Rutherford Appleton Laboratory
> Building R1 Room 1.60
> Fermi Avenue
> Chilton
> Didcot
> Oxfordshire OX11 0QX
> United Kingdom
> Email:        a.j.miles@rl.ac.uk
> Tel: +44 (0)1235 445440
Received on Wednesday, 6 October 2004 10:40:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:45:16 UTC