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

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
jjett2@illinois.edu

On Thu, Jul 30, 2015 at 7:30 AM, Suhrbier, Lutz <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 <L.Suhrbier@bgbm.org>]
> *Sent:* Thursday, July 23, 2015 8:23 AM
> *To:* 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
>
>
>
>
>