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

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]
Sent: Thursday, July 23, 2015 8:23 AM
To: 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