Re: JSON and Lists

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
> >
> >
> >
> >
> >
>
>
>