W3C home > Mailing lists > Public > semantic-web@w3.org > October 2010

Re: RDF List and Collection questions

From: Bob Ferris <zazi@elbklang.net>
Date: Tue, 12 Oct 2010 11:30:30 +0200
Message-ID: <4CB42AB6.7080609@elbklang.net>
To: Semantic Web <semantic-web@w3.org>
Hi,

Am 12.10.2010 08:11, schrieb Antoine Zimmermann:
> Le 12/10/2010 03:04, Nathan a écrit :
>> Hi,
>>
>> One or ten questions here..
>>
>> Are two instances of rdf:List the same rdf:List if they have the same
>> rdf:first and rdf:rest values?
>
> No, not according to the formal semantics. An application could be
> implemented such that it consider them the same, for practical purposes,
> but this would not follow the specifications.
>
>> Clarifications asked
>> - Lists can be recursive - yes/no?
>
> Nothing prevent them to be in the spec but again, one can think of
> applications that make restriction on this.
>
>> - Lists can fork, in that two (or more) list chains can intersect and
>> share the same tail - yes/no?
>
> It can fork, intersect and even be infinite. The formal model of a
> rdf:List is such that it describes a directed graph, where rdf:rest
> denotes the edges and rdf:first maps the nodes to their labels (label in
> a general sense, it can be a URI or a bnode).
>
>> - Lists can use both bnodes or URIs - yes/no?
>
> Sure.
>
>> Why are both rdf:List and rdf:Seq defined, does Seq offer something that
>> List does not (I can see things List offers that Seq doesn't but not the
>> other way around)? Are the two interchangeable?
>
> To make an analogy with programming languages, rdf:List is liked a
> linked list and rdf:Seq is like an array. Members of a rdf:Seq are
> easier to get: if you support RDFS reasoning, you can get the members
> with the predicate rdfs:member.
>
> SELECT ?m WHERE { ?seq rdfs:member ?m . }
>
>> rdf:Alt, does anybody use this? (I'm struggling to see why it's defined
>> in rdf to be honest)
>
> I don't know but the only times I saw it used was in the RDF specs and
> RDF tutorials. I'm sure there are a few marginal data publishers that
> use it.
>
>> Do we actually need unordered and ordered lists in rdf? (something
>> niggles that we only need say List and consideration of whether to treat
>> it like an ordered or unordered list happens when processing, based on
>> context)
>
> I a list is unordered, how can one know what is the first element? It
> seems that what you suggest is rather "make everything ordered then
> ignore the order if you don't need it". In principle, this would be
> possible using rdf:Seq because you can order the element explicitly
> (using rdf:_1, rdf:_2, etc) or ignore the order with the generic
> rdfs:member. However, due to the Open World Assumption, you can never be
> sure that all elements of a rdf:Seq, e.g.,
>
> ex:s a rdf:Seq ;
> rdf:_3 ex:firstElement ;
> rdf:_17 ex:seventeenthElement ;
> rdf:_42 ex:fourtysecondElement .
>
> is a valid sequence in RDF and it does not say that 42 is the last
> element. With rdf:List, assuming it's used "normally" (no fork, no loop,
> etc) you can close the list with rdf:nil.

That's why, we designed the Ordered List Ontology[1,2], to overcome the 
drawbacks of the existing approach (rdf:Seq) to model ordered lists. 
That means, we can

- still query all members of an ordered list by
    SELECT ?s WHERE { ?olo olo:slot ?s . }
- but also request by index
    SELECT ?s ?i WHERE { ?seq olo:slot ?s . ?s olo:index ?i . }
- an furthermore iterate over the list elements
    SELECT ?cs ?ns WHERE { ?cs olo:next ?ns . }
- request the length of an ordered list
    SELECT ?l WHERE { ?seq olo:length ?l . }

The consistency of such an ordered list should be handled by the 
knowledge management system that produces or modifies this ordered list.

Cheers,


Bob


PS: Unordered list are represented by multiple utilization of one 
property. That means, so do not really need a further explicit list 
representation.


[1] http://purl.org/ontology/olo/orderedlistontology.html
[2] http://smiy.wordpress.com/2010/07/15/the-ordered-list-ontology/
Received on Tuesday, 12 October 2010 09:31:06 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:41:23 UTC