Re: RDF List and Collection questions

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 10:11:17 UTC