W3C home > Mailing lists > Public > public-rdf-wg@w3.org > October 2011

Re: proposal to close ISSUE-77 (Re: [ALL} agenda telecon Oct 19)

From: Pat Hayes <phayes@ihmc.us>
Date: Wed, 19 Oct 2011 19:10:11 -0500
Cc: public-rdf-wg@w3.org
Message-Id: <AD9E5DE5-F2CF-4319-90FD-57E6A7B44985@ihmc.us>
To: Andy Seaborne <andy.seaborne@epimorphics.com>

On Oct 19, 2011, at 2:55 PM, Andy Seaborne wrote:

> 
> 
> On 19/10/11 20:33, Pat Hayes wrote:
>> 
>> On Oct 19, 2011, at 7:32 AM, Andy Seaborne wrote:
>> 
>>> 
>>> 
>>> On 19/10/11 13:17, Sandro Hawke wrote:
>>>> On Wed, 2011-10-19 at 11:23 +0100, Andy Seaborne wrote:
>>>>> 
>>> 
>>>>> I don't mind how what we do to rdf:Seq but if we say "use blank nodes
>>>>> for Seq" (which then avoids the merge issues) it is a step forward (Ian
>>>>> -- skolemized system generated URIs would count as well)
>>>> 
>>>> I can live with that, but I'm not sure why we'd say
>>>> dont-use-non-blank-nodes-for-Seq any stronger than dont-use-Seq.
>>> 
>>> It avoids merge problems as the bNodes should stop two rdf:_1's on the same resource.
>> 
>> Huh? How does that work? I mean, how do bnodes stop this happening?
> 
> ----------- RDF Graph 1
> @prefix rdf:     <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
> 
> <http://example.org/favourite-fruit>
>    a           rdf:Seq ;
>    rdf:_1      <http://example.org/banana> ;
>    rdf:_2      <http://example.org/apple> ;
>    rdf:_3      <http://example.org/pear> .
> 
> ----------- RDF Graph 2
> <http://example.org/favourite-fruit>
>    a           rdf:Seq ;
>    rdf:_1      <http://example.org/pineapple> .
> 
> ----------- RDF Merge
> 
> @prefix rdf:     <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
> 
> <http://example.org/favourite-fruit>
>    a           rdf:Seq ;
>    rdf:_1      <http://example.org/banana> ;
>    rdf:_1      <http://example.org/pineapple> ;
>    rdf:_2      <http://example.org/apple> ;
>    rdf:_3      <http://example.org/pear> .
> -----------
> 

> [[
> the rdf:Seq class is used conventionally to indicate to a human reader that the numerical ordering of the container membership properties of the container is intended to be significant.
> ]]
> 
> Double use of rdf:_1 is confusing.

It might be, but it also might not be. Maybe the moral here is that both bananas and pineapples are preferable to apples and oranges, but there is no way to put the first two in a preference order. Which makes a loose kind of sense, given the original graphs. 

> 
> ----------- RDF Graph 3
> @prefix rdf:     <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
> 
> []
>    a           rdf:Seq ;
>    rdf:_1      <http://example.org/banana> ;
>    rdf:_2      <http://example.org/apple> ;
>    rdf:_3      <http://example.org/pear> .
> 
> ----------- RDF Graph 4
> []
>    a           rdf:Seq ;
>    rdf:_1      <http://example.org/apple> .
> 
> ----------- RDF Merge
> 
> @prefix rdf:     <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
> []
>    a           rdf:Seq ;
>    rdf:_1      <http://example.org/banana> ;
>    rdf:_2      <http://example.org/apple> ;
>    rdf:_3      <http://example.org/pear> .
> 
> []
>    a           rdf:Seq ;
>    rdf:_1      <http://example.org/pineapple> .
> -----------
> 
> and the app can decide what to do.

Except that in this case, the graphs record nothing about these two seqs. How could an app decide what to do? One of them might be a laundry list. 

Also, this example applies just as much to other kinds of RDF containers. Even when the ordering is not significant, its still as confusing (or not) to have two rdf:_1 values. 

Pat

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973   
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
Received on Thursday, 20 October 2011 00:10:45 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:46 GMT