Re: JSON and Lists

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