Re: JSON and Lists

I agree with Stian.  The existence of the oa:Choice resource (or oa:List
separate from the head node of the rdf:List) is the important aspect, and
with it the semantics are pretty clear. If the target is a Choice, then the
annotation's bodies are about a resource that has several possible URIs by
which it is identified, any of which are appropriate to use and potentially
some are better than others.

I think that Choice can be thought of as an abstract resource that
identifies a conceptual collection of interchangeable resources, such as a
book that has multiple URIs where representations are available.  This is
the same way that an oa:Composite or oa:List can be thought of as an
abstract resource that identifies a conceptual collection of resources, but
without the interchangeableness.


In terms of the direct link, previous discussion on that topic went along
the lines of:

* It would be nice to have a relationship from the annotation to all of the
full URIs for the targets and ditto for the bodies, as they can be quite
deep down in the graph
* Systems (either client or server) can add in that property if it's useful
locally, or an API function could give direct access to them.
* But you couldn't use SPARQL if you didn't know the non-standard property
* Optimizing for a particular technology isn't a priority, compared to
cluttering up all of the representations to be transferred over the wire,
as it turns something that's almost always a tree into something that's
almost always a graph.


HTH, and apologies for radio silence -- I've had limited access this week.

Rob


On Fri, Oct 24, 2014 at 10:43 AM, Stian Soiland-Reyes <
soiland-reyes@cs.manchester.ac.uk> wrote:

> I think the semantics are clear. You are annotating not the list of
> resources, but an oa:Choice between resources. The available choices are
> detailed with a list - related using our own property oa:members.
>
> It might be an issue that tthere is no direct link from the annotation to
> the underlying resources - independent of any choice or specific resource
> and so on. This can be solved by having a new superproperty and some
> property chains. No idea what to call it... oa:involvedInAnnotation or
> something. (And in which direction should it go?)
>
>
>
>
>
> On 23 October 2014 21:05, Jacob Jett <jgjett@gmail.com> wrote:
>
>> This sounds fine to me from the developer / serialization view point.
>>
>> I do have a more conceptual question though. Does it change the semantics
>> of what is being annotated? Are we annotating a list rather than the things
>> in it?
>>
>> This might not actually be a change, since it seems like the original
>> model is annotating a choice rather than the choices. Probably this makes
>> no difference (kind of like annotation properties in OWL).
>>
>> But I am curious about the implications for tools that leverage semantics.
>>
>> Regards,
>>
>> Jacob
>>
>>
>> On Thu, Oct 23, 2014 at 2:34 PM, Frederick Hirsch <w3c@fjhirsch.com>
>> wrote:
>>
>>> +1  (developer usability/comprehension)
>>>
>>> Nothing is lost and some simplification is gained, it appears.
>>>
>>> regards, Frederick
>>>
>>> Frederick Hirsch, Nokia
>>> Co-Chair W3C Web Annotation WG
>>> @fjhirsch
>>>
>>>
>>>
>>> On Oct 20, 2014, at 4:56 AM, Ivan Herman <ivan@w3.org> wrote:
>>>
>>> > That definitely looks like a better option to me.
>>> >
>>> > Ivan
>>> >
>>> > On 18 Oct 2014, at 03:22 , 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
>>> >
>>> >
>>> > ----
>>> > Ivan Herman, W3C
>>> > Digital Publishing Activity Lead
>>> > Home: http://www.w3.org/People/Ivan/
>>> > mobile: +31-641044153
>>> > GPG: 0x343F1A3D
>>> > WebID: http://www.ivan-herman.net/foaf#me
>>> >
>>> >
>>> >
>>> >
>>> >
>>>
>>>
>>>
>>
>
>
> --
> Stian Soiland-Reyes, myGrid team
> School of Computer Science
> The University of Manchester
> http://soiland-reyes.com/stian/work/ http://orcid.org/0000-0001-9842-9718
>



-- 
Rob Sanderson
Technology Collaboration Facilitator
Digital Library Systems and Services
Stanford, CA 94305