Re: JSON and Lists

Jacob

Yes, U agree, we need to very clear regarding  alternate representations (versus choice of arbitrarily different things) to avoid confusion and interoperability problems.

I need to take another look at the community group use cases and our draft to see how clear it is, with this perspective.

thanks
 
regards, Frederick

Frederick Hirsch, Nokia
@fjhirsch



On Oct 23, 2014, at 4:29 PM, Jacob Jett <jgjett@gmail.com> wrote:

> Hi, 
> 
> I think I was unclear about what I meant about altering the semantics. The annotation's goal is communicating that one thing is about another thing. When we add in choice (or list) we're making a subtle change. What we mean to say with an annotation is that the body is about the target, the latter of which has multiple representations. The trouble I'm having with both lists and choices is that the semantics of the annotation becomes -- the body is about your choice of some things (which happen to be representations for some abstract thing). The annotation becomes about the "choiceness" of the things, if that makes sense. 
> 
> Ironically this is the looked for effect of composite but, in this case this probably isn't a good side effect, although it might easily be a case of it doesn't matter from the dev/implementation side. I'm still interested in talking through the implications on the conceptual side. For instance if an implementer builds tools that use reasoners, what kind of pitfalls will they need to aware of. 
> 
> Regards,
> 
> Jacob
> 
> 
> On Thu, Oct 23, 2014 at 3:14 PM, Frederick Hirsch <w3c@fjhirsch.com> wrote:
> I believe it has the same semantics of annotating the choice since the semantics are defined by the use of oa:Choice
> 
> (I also believe there is still the same underlying linkage to RDF behind the simplified representation, if we are clear about the meaning)
> 
> regards, Frederick
> 
> Frederick Hirsch, Nokia
> Co-Chair W3C Web Annotation WG
> @fjhirsch
> 
> 
> 
> On Oct 23, 2014, at 4:05 PM, 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
>> >
>> >
>> >
>> >
>> >
>> 
>> 
>> 
> 
>