Re: JSON and Lists

On 25 Oct 2014, at 09:58 , Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk> wrote:

> oa:inList is not good as it implies the opposite directipn, just oa:member perhaps.

My feeling is: we shouldn't do anything. As Rob said, the semantics is clear, as you proposed, an API can be defined for users, and the SPARQL property path features covers the need for RDF users who want to query the data. The chances that somebody wants to do some serious OWL reasoning on the annotation data is so low in my view, that we should not go out of our way to define extra properties...

Ivan


> 
> On 25 Oct 2014 17:56, "Stian Soiland-Reyes" <soiland-reyes@cs.manchester.ac.uk> wrote:
> You are right. This is part of the trouble with rdf List, it does not play well in OWL land (hence most OWL people simply ignore it ).
> 
> In OWL the easiest might be to introduce a 
> oa:inList as superproperty of rdf:first and the chain rdf:rest>oa:inList.
> 
> Bit of a hack, but worth testing?
> 
> (Alternatively a transitive oa:partialRest as superprop of rdf:rest and change the chain to oa: partialRest>rdf:first. But this would mean two new magic properties rather than one oa:inList)
> 
> On 25 Oct 2014 17:42, "Ivan Herman" <ivan@w3.org> wrote:
> 
> On 24 Oct 2014, at 07:35 , Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk> wrote:
> 
> > We could use a transitive oa:involves (subproperty of
> > prov:wasInfluencedBy) as a superproperty of oa:hasBody / oa:hasTarget
> > / oa:hasSource / oa:members - and add a propety chain equivalence for
> > oa:members -> (rdf:list/rdf:rest*).
> 
> I am not sure what you mean here. Property chains (in OWL) are defined with a fixed number of properties, whereas property paths (in SPARQL) allow the '*' operator, ie, they can be of a variable length. Can you explain what you mean here?
> 
> >
> > (Warning: Some OWL tools are angry about any kind of statements about
> > rdf:* as they are reserved namespaces! Perhaps keep the property chain
> > in a secondary OWL file.)
> >
> 
> AFAIK, the issue is with OWL DL reasoner where, indeed, the rdf namespace is untouchable. But I do not think we should optimize on this; I do not see OWL DL type reasoning playing an important role in annotation-related applications anyway.
> 
> > Systems are then free to either use OWL reasoning to conclude
> > oa:involves, or add them explicitly when creating the resource, or
> > calculate them at some later point programmatically. We are going to
> > need something along this (or its' inverse property) in an Open
> > Annotion API - as the basic operation would be "Tell me about all
> > annotations that somehow talk about resource X".
> 
> I guess having an API makes sense indeed. Having an explicit entry as a term in the model seems an overkill to me; we may choose to add a informative note or an appendix, aimed at RDF users, to show how similar issues can be handled by them using, say, SPARQL.
> 
> Ivan
> 
> 
> >
> >
> >
> > On 24 October 2014 12:46, Robert Sanderson <azaroth42@gmail.com> wrote:
> >>
> >> 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
> >
> >
> >
> > --
> > 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
> 
> 
> ----
> 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
> 
> 
> 
> 
> 


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