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

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?

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?

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 Tue, Aug 4, 2015 at 6:50 AM, Suhrbier, Lutz <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 [jgjett@gmail.com] on behalf of Jacob Jett [
> jjett2@illinois.edu]
> > Sent: Monday, August 03, 2015 09:40
> > To: Suhrbier, Lutz
> > Cc: Cole, Timothy W; 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
> > 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>> 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>
> > 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>> 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]
> > 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
> >
> >
> >
> >
>