Re: RDF List and Collection questions

Hi Barry, all:

Side-note: It's not easy to establish canonical URIs for properties  
that start in a particular context and become globally useful later  
on. Also, it's difficult to

1. reuse and
2. consolidate existing properties globally

because of domain / range specifications.

In particular, using owl:sameAs and rdfs:subProperty (maybe also  
owl:equivalentProperty, not sure) can lead to unintended class  
memberships due to the "weird" (from a DBMS perspective) semantics of  
rdfs:domain and rdfs:range.

For example, if you have

foo1:weight with rdfs:domain foo1:Book

	and

foo2:hasWeight with rdfs:domain foo2:Car

then

foo2:hasWeight owl:sameAs foo1:weight .
foo2:hasWeight rdfs:subPropertyOf foo1:weight .

or

ex:MyCar foo1:weight 100 .

will turn ex:MyCar into an instance of foo1:Book.

This is why using domains and ranges in Web Ontologies are a tricky  
subject, and it also likely the cause that similar properties are  
defined in multiple vocabularies.

Martin



On 12.10.2010, at 13:32, Barry Norton wrote:

>
> 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 12:12:20 UTC