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

Re: RDF List and Collection questions

From: Barry Norton <barry.norton@aifb.uni-karlsruhe.de>
Date: Tue, 12 Oct 2010 13:32:01 +0200
Message-ID: <4CB44731.4050607@aifb.uni-karlsruhe.de>
To: Martin Hepp <martin.hepp@ebusiness-unibw.org>
CC: Bob Ferris <zazi@elbklang.net>, Semantic Web <semantic-web@w3.org>

So does SPIN (e.g., sp:lt):
http://www.spinrdf.org/sp.html

It's a shame that standards keep saying 'reuse XPATH/XQUERY etc.' 
without these features having been given canonical URIs, no?

Barry


On 12/10/2010 12:10, Martin Hepp wrote:
> Hi all:
> Side comment: GoodRelations defines properties for standard ordinal 
> relations between objects:
>
> gr:equal
> gr:greater
> gr:greaterOrEqual
> gr:lesser
> gr:lesserOrEqual
> gr:nonEqual
>
> The domain and range is gr:QualitativeValue, so using these properties 
> for more general purposes will not have any negative side-effects 
> other than making your entity a gr:QualitativeValue, which is harmless.
>
> See
>
> http://purl.org/goodrelations/v1#QualitativeValue
>
>
> Martin
>
>
>
>
> On 12.10.2010, at 11:30, Bob Ferris wrote:
>
>> 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 11:32:42 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 08:45:20 UTC