Re: JSON and Lists

Yeah, the RDF model would be exposing the list in order to preserve the
order.

As such oa:Choice would become more complicated in serialization, but I
guess at the benefit of being easier to consume.

E.g. if we express the example from Robert in Turtle without using the list
operator:

:choice1 a oa:Choice;
    oa:members [ a rdf:List;
      rdf:first eg:body1;
      rdf:rest [ a rdf: List;
          rdf:first eg:body2;
          rdf:rest [ a rdf: List;
              rdf:first eg:body3;
              rdf:rest rdf:nil .
          ] .
      ] .
  ] .

Hence the need for property chains or special SPARQL functions if you need
to retrieve the list values from an RDF store. Challenge to the reader -
how to sort this list using standard SPARQL.

(Typed on my phone, probably wrong syntax! )
On 20 Oct 2014 18:31, "Jacob Jett" <jgjett@gmail.com> wrote:

> Hi Rob,
>
> I think the proposed serialization is much better. I am wondering what the
> underlying RDF / conceptual model is going to look like. IIRC the proposal
> is that the above is an existing interpretation of rdf:list in JSON-LD is
> that right? So we would keep rdf:list in the rdf version of the model, is
> that correct?
>
> This sounds fine to me, use of rdf:list is in my mind a little more
> tenuous, as it is a very kludgey model of a list-type entity.
>
> Regards,
>
> Jacob
>
>
> On Fri, Oct 17, 2014 at 8:22 PM, Robert Sanderson <azaroth42@gmail.com>
> wrote:
>
>>
>> Dear all,
>>
>> The current OA model is less intuitive than it could easily be when it
>> comes to the Multiplicity constructs.  For the FPWD, I think it would be
>> beneficial to make them easier to understand and implement.
>>
>> The proposed structure for the oa:Choice is:
>>
>>   {
>>     "@type": "oa:Choice",
>>     "members": ["eg:body1", "eg:body2", "eg:body3"]
>>   }
>> Where the members are ordered in descending priority.
>> (or "items" or other convenient name tbd)
>>
>> And the exact same structure for oa:List:
>>
>>   {
>>     "@type": "oa:List",
>>     "members": ["eg:target1", "eg:target2", "eg:target3]
>>   }
>> Where the members are ordered.
>>
>> This looks like something that a developer would create using JSON, when
>> it needed to go into an object (which it does, given the distinction
>> between List and Choice, and that the object of the hasTarget property must
>> be an object) [see Issue 12]
>>
>>
>> Conversely, the current structures expose a lot of the RDF plumbing where
>> they shouldn't:
>>
>>   {
>>    "@type": "oa:Choice",
>>    "default": "eg:body1",
>>    "item" : ["eg:body3", "eg:body2"]
>>   }
>> Where item is two separate triples, and thus the order is not
>> deterministic.
>>
>> And worse for list:
>>
>>   {
>>    "@type": ["oa:List", "rdf:List"],
>>    "first": "eg:target1",
>>    "rest": ["eg:target2", "eg:target3"],
>>    "item" : [ "eg:target2", "eg:target1", "eg:target3"]
>>   }
>> Where, again, the order of the entries in item is not deterministic as
>> they're separate triples.
>>
>>
>> Thoughts?  Jacob, please feel free to describe your counter proposal from
>> issue 1 if you'd like :)
>>
>>
>> This is related to issues:
>>   https://github.com/w3c/web-annotation/issues/1
>>   https://github.com/w3c/web-annotation/issues/2
>>   https://github.com/w3c/web-annotation/issues/5
>>   https://github.com/w3c/web-annotation/issues/12
>>
>> --
>> Rob Sanderson
>> Technology Collaboration Facilitator
>> Digital Library Systems and Services
>> Stanford, CA 94305
>>
>
>