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

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 ?


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?



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

On Thu, Jul 30, 2015 at 7:30 AM, Suhrbier, Lutz <<>> 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:

Further comments are inline...

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


-Tim Cole

From: Suhrbier, Lutz []
Sent: Thursday, July 23, 2015 8:23 AM
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 !


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


Received on Monday, 3 August 2015 08:45:32 UTC