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

On Mon, Aug 3, 2015 at 3:45 AM, Suhrbier, Lutz <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
> 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
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__wiki.bgbm.org_annosys-2Dintern_index.php_TechnicalDocumentation-23W3C-5FOpen-5FAnnotation-5Fimplementation-5Fof-5Fthe-5FAnnoSys-5FAnnotation-5FData-5FModel&d=AwMGaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=npggDwlZ6PziBzPBZthSo0f8iGOgRMf9ulO6o4WwfiA&m=RDQNuUJn1vklRjXNJrRM5HT4BNJ6oqUHksOjXh6I6SY&s=CuTZRxeGA_ppIOAoehNTGdHKZc9Z7zJuHJe7FHRa2IY&e=>
>>
>> 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
>>
>>
>>
>>
>>
>
>