Re: Multiple bodies v. multiple annotations: annotating a base annotation

Hi Jacob,

see inline..

Am 04.08.2015 um 17:52 schrieb Jacob Jett:
Hi Lutz,

Thank you for sharing these technical documents.

Looking at the figure directly below the "W3C Open Annotation implementation..." heading, I had a question about how the oa:hasSource predicate is being used. Specifically, it looks like your implementation calls adding "role" data to the sources (e.g., Body 1) through typing the source as a member of a specific annosys class. Could you say more about why the "role" information is being attached to the sources rather than the specific resources?
In our case, the "role" represents the expectation towards the curator to either add, update or remove the XML-element addressed by the scoped specific target selector. As rdf:type is already used in for specific resources, and I was a bit lazy in programming this, I simply attached the expectation as class of the body. Of course, it could have been also implemented by introducing a further property for expectation or by adding it as a class to the specific resource, if i am not wrong.


I'm also a bit curious about the exact work the annotation in the figure is expected to play. It looks like it's being used to record some human intervention in a workflow, essentially timestamping when a human has signed off on a batch of edits targeting a variety of data targets. Is that correct?
This is in more detail explained in the technical document (section annotation data model ff.).

Each body takes an annotated value and a comment which relates to an XML-Element of a metadata document describing a physical object in a (botanic) collection. So, the specific body relates to an XPath selector matching the XML-Element in an XML-document holding the metadata. There may be several body-selector couples which alltogether are relevant for a given annotation, which in fact proposes corrections, additions or removals to the metadata of the collection object. A curator of the collection may decide for each of these annotated elements if he accepts the annotated element and updates his collection database or not.

So, the "variety" of data targets are XML-Paths in a XML-based metadata record describing a unique physical object in a collection.

Hope, that clarifies the use case ?

Best regards
Lutz



Thanks,

Jacob



_____________________________________________________
Jacob Jett
Research Assistant
Center for Informatics Research in Science and Scholarship
The Graduate School of Library and Information Science
University of Illinois at Urbana-Champaign
501 E. Daniel Street, MC-493, Champaign, IL 61820-6211 USA
(217) 244-2164
jjett2@illinois.edu<mailto:jjett2@illinois.edu>

On Tue, Aug 4, 2015 at 6:50 AM, Suhrbier, Lutz <L.Suhrbier@bgbm.org<mailto:L.Suhrbier@bgbm.org>> wrote:
Timothy,

oh sorry, I gave you the link to the internal version. The public
version's url is without "-intern", so

http://wiki.bgbm.org/annosys/index.php/TechnicalDocumentation#W3C_Open_Annotation_implementation_of_the_AnnoSys_Annotation_Data_Model.


I guess you will understand the without JSON or Turtle...


Best regards
Lutz


Am 03.08.2015 um 19:02 schrieb Cole, Timothy W:
> Lutz-
>
> Backing up slightly in this thread, I wanted to follow up on this part of your reply of 30 July:
>
> "Actually, we are using the oa:hasScope relationship to relate a specific body to a specific target, which in our use case relates value&comment of an annotated XML Element in the specific body, with an XPointer selector defined in an specific target of an annotation. Semantically, that means that the specific body was created when the annotator has evaluated that what is selected by the specific target (an element in an XML document). This is somewhat like a "soft link", but it is absolutely ok with regard to our use case.
> Even though, I wanted to have a "hard link" relation, I guess that this would contradict to the Open World Assumption..."
>
> Could you say more about how you are using oa:hasScope and maybe provide an example in JSON or Turtle? I had not thought about hasScope being used in this way.
>
> By the way, when I tried to view the use cases on your wiki at this address: http://wiki.bgbm.org/annosys-intern/index.php/TechnicalDocumentation#W3C_Open_Annotation_implementation_of_the_AnnoSys_Annotation_Data_Model I was prompted for a login and I didn't see an obvious way to self-subscribe to the wiki, so unable to view.
>
> Thanks,
>
> -Tim Cole
>
>
> ________________________________________
> From: jgjett@gmail.com<mailto:jgjett@gmail.com> [jgjett@gmail.com<mailto:jgjett@gmail.com>] on behalf of Jacob Jett [jjett2@illinois.edu<mailto:jjett2@illinois.edu>]
> Sent: Monday, August 03, 2015 09:40
> To: Suhrbier, Lutz
> Cc: Cole, Timothy W; public-annotation@w3.org<mailto:public-annotation@w3.org>
> Subject: Re: Multiple bodies v. multiple annotations: annotating a base annotation
>
> Hi Lutz,
>
> My question was about the semantics of subclassing expectation as a kind of motivation. I was thinking that it would be more logical to simply have an additional property describing specific resources, i.e., motivation ≠ expectation. Does that make sense?
>
> Essentially under the current proposal, a specific resource would have a source, a role, and (optionally) an expectation (that is not a semantic sibling to role).
>
> Regards,
>
> Jacob
>
>
>
> _____________________________________________________
> Jacob Jett
> Research Assistant
> Center for Informatics Research in Science and Scholarship
> The Graduate School of Library and Information Science
> University of Illinois at Urbana-Champaign
> 501 E. Daniel Street, MC-493, Champaign, IL 61820-6211 USA
> (217) 244-2164<tel:%28217%29%20244-2164>
> jjett2@illinois.edu<mailto:jjett2@illinois.edu><mailto:jjett2@illinois.edu<mailto:jjett2@illinois.edu>>
>
> On Mon, Aug 3, 2015 at 3:45 AM, Suhrbier, Lutz <L.Suhrbier@bgbm.org<mailto:L.Suhrbier@bgbm.org><mailto:L.Suhrbier@bgbm.org<mailto:L.Suhrbier@bgbm.org>>> wrote:
> Hi Jacob,
>
> I must admit, that introducing an expectation subclass of oa:motivation w.r.t the body was the first idea that came into my mind when reading Timothy's idea.
>
> You are right that in our use case any annotation is addressed to the curator of the given collection. Otherwise, not any curators are necessarily known or registered agents to the system. So, the agent expected to take action on a given annotation may be some kind of virtual within the system.
>
> So, when we state that we expect a defined course of action which is related to a body, and - as in our use case - the body relates to a specific target via oa:hasScope property, and the target refers to a unique record in a dataset of e.g. a collection, should it not be clear and a logical chain, that the expectation to (e.g. update, add or delete) applies to whoever is responsible for managing the piece of data referenced via oa:hasScope to that body ?
>
> Also, there is no other location to place that information than attaching it to the body. It can not be attached to the specific target, as it would apply to any resources referencing the specific target (which may not only be bodiy resources). And it can not be attached to the oa:motivatedBy property of the oa:annotation itself, because this would apply to the whole annotation, and not only to that particular body.
>
> Or did I somehow misunderstood your question ?
>
> Lutz
>
>
>
>
>
> Hi Lutz,
>
> I had a quick question about your "expectation" use case. In the conversation below you suggest that expectation could be a sub-class of oa:Motivation, but isn't it the case that motivation records the role relationship of the body w.r.t. the target and expectation records the desired course of action that some agent should take? Semantically speaking, is the latter really a sub-class of the former?
>
> Thanks,
>
> Jacob
>
> _____________________________________________________
> Jacob Jett
> Research Assistant
> Center for Informatics Research in Science and Scholarship
> The Graduate School of Library and Information Science
> University of Illinois at Urbana-Champaign
> 501 E. Daniel Street, MC-493, Champaign, IL 61820-6211 USA
> (217) 244-2164<tel:%28217%29%20244-2164><tel:%28217%29%20244-2164>
> jjett2@illinois.edu<mailto:jjett2@illinois.edu><mailto:jjett2@illinois.edu<mailto:jjett2@illinois.edu>>
>
> On Thu, Jul 30, 2015 at 7:30 AM, Suhrbier, Lutz <L.Suhrbier@bgbm.org<mailto:L.Suhrbier@bgbm.org><mailto:L.Suhrbier@bgbm.org<mailto:L.Suhrbier@bgbm.org>>> wrote:
> Hi Timothy,
>
> please find a comprehensive description of our use case in the Technical Documentation of AnnoSys and our OA implementation in particular here:
>
> http://wiki.bgbm.org/annosys-intern/index.php/TechnicalDocumentation#W3C_Open_Annotation_implementation_of_the_AnnoSys_Annotation_Data_Model

>
> Further comments are inline...
> Lutz-
>
> I strongly agree with you about retaining the option of annotations with multiple bodies and/or multiple targets and about not forcing the creation of artificial annotations that are not annotations.  I’m not sure Ray was proposing a move away from this, but the point is that as you say the current modeling for accommodating multiple bodies (including multiplicity classes) works well for many, many use cases.
>
> But would any of your multi-body use cases benefit from an additional (or modified) predicate in the OA namespace to distinguish the role of each body in a multiple body annotation – that is, a way in the OA namespace to say something about how each body individually relates to the annotation target(s)?  Is this kind of expressivity needed for your implementations? This would introduce an additional complexity not fully covered in the model and is I think the main concern right now. If this is a requirement for you, how do you currently handle it? More examples of use cases having this requirement and how currently addressed would be helpful.
> Actually, we are using the oa:hasScope relationship to relate a specific body to a specific target, which in our use case relates value&comment of an annotated XML Element in the specific body, with an XPointer selector defined in an specific target of an annotation. Semantically, that means that the specific body was created when the annotator has evaluated that what is selected by the specific target (an element in an XML document). This is somewhat like a "soft link", but it is absolutely ok with regard to our use case.
> Even though, I wanted to have a "hard link" relation, I guess that this would contradict to the Open World Assumption...
>
> Of the approaches discussed on Wednesday’s call as to how to best handle this potential requirement, I personally favor first the multiple annotation approach (clean and simple, even if it does create some ‘clutter’), and second a new predicate (or a redefinition of oa:motivatedBy) for use with specificResource bodies allowing annotating agents to describe each body’s role in  a multi-body annotation.
> I agree that the first approach is clean and simple, but semantically, it remains incorrect as it creates real-existing annotations in the model which are definitely not meant as annotations and are only valid in conjunction with other annotations.
>
> Also, I do not see how the addition of a oa:motivatedBy predicate could help to relate specific bodies to specific targets more than oa:hasScope ?
>
> But, in our use case, it would be useful to express an expectation towards the curator (e.g. update, remove or add the element related to that body) what he was expected to do with the given annotation in his collection database. Actually, we simply use rdf:type to express that. Potentially, an oa:motivation subclass "oa:expectation" could do the job much cleaner.
>
>
>
> These solutions are not mutually exclusive.  And the first arguably is already adequately supported in the existing model, although to fully explore the multiple annotation approach, I think we need to talk further about groups of related annotations and/or annotation sets. These topics also came up in the CG, and have come up again in the WG, with the decision so far has been to basically ignore in the formal model – but I think it worth revisiting this as regards both the model and now also the protocol in light of use cases featuring situations where the annotating agent wants to use as bodies multiple different resources each having a distinctive relationship to target(s).
> I would like to extend your notion of distinctive relationship to dedicated specific targets(e.g. by relating bodies to specific selectors), and not only to the parent oa:hasTarget relation.
>
> Separately, there was at one time a separate use case about multi-body annotations in which body A related to the target while body B related to body A, but I think we’ve established (maybe) that this is really a use case that does require multiple annotations.
> Hmm, having a body related to another body appears to not make any sense, if there was no more expressiveness in the relationship, e.g. like body B adds some information to body A.
>
>
> I hope, I our use case and my points are helpful contributions to that discussions.
>
> Best regards
> Lutz
>
>
> Thanks,
>
> -Tim Cole
>
>
> From: Suhrbier, Lutz [mailto:L.Suhrbier@bgbm.org<mailto:L.Suhrbier@bgbm.org>]
> Sent: Thursday, July 23, 2015 8:23 AM
> To: public-annotation@w3.org<mailto:public-annotation@w3.org><mailto:public-annotation@w3.org<mailto:public-annotation@w3.org>>
> Subject: Re: Multiple bodies v. multiple annotations: annotating a base annotation
>
> Hi Ray,
>
> we had that discussion in the CG, about two years ago. Finally, multiple bodies, and the hasScope relationship have been introduced. I must say, within our AnnoSys project, I am very happy that we have these means to assemble multiple annotated parts of a target within a single annotation, and not to clutter our stores with annotation instances, which in fact do not represent annotations.
>
> In our use case, an annotation may consist of several elements in an XML-document, which are belonging together logically and semantically. So, cluttering the store with annotations, which can not stand on its own makes no sense in my opinion, even when they are linked together by a suitable motivation terminologie. Furthermore, performance will be reduced, if you have to query 10 times more annotations and filter out those who are "base" annotations., These are my two main reasons, why multiple bodies are really useful !
>
> Lutz
>
>
> Am 22.07.2015 um 18:12 schrieb Denenberg, Ray:
> Just want to clarify the model I was describing (on the call).
>
> Instead of multiple bodies in an annotation, submit each body in a separate annotation, but first, submit a base annotation (with no body) and then all those “separate” annotations annotate the base annotation.
>
> The complication cited was that this base annotation would be some sort of special type of annotation and that there would have to be some way to designate it as such.  But I don’t think it’s any more complicated than just assigning it the motivation “baseAnnotation” (or come up with some gerund/verb form of that).
>
> Ray
>
>
>
>