Re: JSON and Lists

oa:inList is not good as it implies the opposite directipn, just oa:member
perhaps.
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
>>
>>
>>
>>
>>
>>