Re: oa:List spec

The answer (posted a few hours ago):
http://lists.w3.org/Archives/Public/public-linked-json/2013May/0017.html



On Fri, May 3, 2013 at 4:01 AM, Robert Sanderson <azaroth42@gmail.com>wrote:

>
> Agreed. It's a difficult problem to evaluate the effects of changing the
> model in order to make implementation easier, and hence adoption hopefully
> greater, rather than to incorporate a use case where it's very clear.
>
> The JSON-LD folk don't seem keen on even discussing lists.
> eg:
> http://lists.w3.org/Archives/Public/public-linked-json/2013Apr/0048.html
> got precisely zero responses.
>
> So I'm very happy to leave it alone and wait until we have further
> feedback on the model from various sources to inform our decisions in cases
> like these.
>
> Rob
>
>
>
> On Thu, May 2, 2013 at 1:22 PM, Antoine Isaac <aisaac@few.vu.nl> wrote:
>
>> Hi Rob!
>>
>>
>>
>>
>>
>>> I agree that the turtle is incorrect, but not what is incorrect :)
>>>
>>> The typo is the use of []s rather than ()s which imply a collection and
>>> rdf:nil
>>>
>>> http://www.w3.org/**TeamSubmission/turtle/#sec-**collections<http://www.w3.org/TeamSubmission/turtle/#sec-collections>
>>>
>>> Thus the correction would be:
>>>
>>> <list1>  a oa:List, rdf:List ;
>>>      oa:item<selector1>,<selector2>  ;
>>>      rdf:first<selector1>  ;
>>>      rdf:rest (<selector2>  ) .
>>>
>>>
>>
>>
>> OK!
>>
>>
>>
>>
>>> This does bring up the question as to whether the list should be the
>>> object, or should be referenced from the object.
>>>
>>> In other words should the above instead be:
>>>
>>> <list1> a oa:List ;
>>> oa:item <selector1>, <selector2> ;
>>> oa:hasList (selector1 selector2) .
>>>
>>> Which might serialize more naturally, but would be a departure from the
>>> other multiplicity objects.
>>>
>>
>>
>> I'm not very much in favor of reverting our previous choice for
>> serialization-based reasons only...
>>
>> Antoine
>>
>>
>>
>>> On Thu, May 2, 2013 at 8:38 AM, Antoine Isaac <aisaac@few.vu.nl <mailto:
>>> aisaac@few.vu.nl>> wrote:
>>>
>>>     Hi Rob,
>>>
>>>     You are right, well spotted!
>>>     The rdf:nil should indeed be present to indicate that the list is
>>> "closed".
>>>
>>>     Best,
>>>
>>>     Antoine
>>>
>>>
>>>
>>>         I \think/ the following is meaningful and right about
>>>         http://www.openannotation.org/**__spec/core/20130208/__**
>>> multiplicity.html#List<http://www.openannotation.org/__spec/core/20130208/__multiplicity.html#List><
>>> http://www.openannotation.**org/spec/core/20130208/**
>>> multiplicity.html#List<http://www.openannotation.org/spec/core/20130208/multiplicity.html#List>
>>> >
>>>
>>>
>>>         1. The turtle example doesn't specify that the list ends in
>>> rdf:nil
>>>         although the picture does. I think you need something like
>>>         rdf:rest [ rdf:first<selector2> ;
>>>         rdf:rest rdf:nil ]
>>>         as the end of<list1>
>>>
>>>         2. Well, the spec doesn't actually require or even suggest an
>>> oa:List
>>>         should be terminated by rdf:nil, but IMO it would be a good help
>>> for
>>>         consumers. Maybe those looking at the rdf ordering problem
>>> already
>>>         have discussed this issue.
>>>
>>>
>>>         --
>>>         Robert A. Morris
>>>
>>>         Emeritus Professor of Computer Science
>>>         UMASS-Boston
>>>         100 Morrissey Blvd
>>>         Boston, MA 02125-3390
>>>
>>>         IT Staff
>>>         Filtered Push Project
>>>         Harvard University Herbaria
>>>         Harvard University
>>>
>>>         email: morris.bob@gmail.com <mailto:morris.bob@gmail.com>
>>>
>>>         web: http://efg.cs.umb.edu/
>>>         web: http://wiki.filteredpush.org
>>>         http://www.cs.umb.edu/~ram
>>>         ===
>>>         The content of this communication is made entirely on my
>>>         own behalf and in no way should be deemed to express
>>>         official positions of The University of Massachusetts at Boston
>>> or
>>>         Harvard University.
>>>
>>>
>>>
>>>
>>>
>>
>>
>


-- 
Dr. Paolo Ciccarese
http://www.paolociccarese.info/
Biomedical Informatics Research & Development
Instructor of Neurology at Harvard Medical School
Assistant in Neuroscience at Mass General Hospital
Member of the MGH Biomedical Informatics Core
+1-857-366-1524 (mobile)   +1-617-768-8744 (office)

CONFIDENTIALITY NOTICE: This message is intended only for the addressee(s),
may contain information that is considered
to be sensitive or confidential and may not be forwarded or disclosed to
any other party without the permission of the sender.
If you have received this message in error, please notify the sender
immediately.