Re: Options for ordered/labelled collections

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 
spec.]

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 
deeply.

Cheers,
Dave

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