RE: multiple bodies and motivations

Bill, no.  What I envisioned in my example is someone submitting both bodies in the same annotation.    --Ray

From: Bill Kasdorf [mailto:bkasdorf@apexcovantage.com]
Sent: Friday, March 20, 2015 5:14 PM
To: Denenberg, Ray; 'Web Annotation'
Subject: RE: multiple bodies and motivations

And you are talking about two separate annotations, correct? One for the cover image and one for the holding?

From: Denenberg, Ray [mailto:rden@loc.gov]<mailto:[mailto:rden@loc.gov]>
Sent: Friday, March 20, 2015 4:57 PM
To: 'Web Annotation'
Subject: RE: multiple bodies and motivations

Well yes, I am agreeing with you and Rob that if you want to convey an annotation-specific role more specific than that conveyed by the global class of the body, it is not appropriate to use class to convey that role.    I suppose my point was that for the cover art it would not be sufficient to only indicate class schema:Image; that would not convey that it is cover art.

Ray

From: jgjett@gmail.com<mailto:jgjett@gmail.com> [mailto:jgjett@gmail.com] On Behalf Of Jacob Jett
Sent: Friday, March 20, 2015 4:41 PM
To: Web Annotation
Subject: Re: multiple bodies and motivations

Hi Ray,

Could you explain more. I feel like I'm missing some important aspect of your example because I can't figure out what body 1 being a bf:CoverArt and body 2 being a bf:HeldItem have to do with their roles within the annotation.

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

On Fri, Mar 20, 2015 at 3:35 PM, Denenberg, Ray <rden@loc.gov<mailto:rden@loc.gov>> wrote:
Rob said:  “… it can't be a class on the Body   …..  The class would be a global assertion, whereas the body may have different roles in different annotations.”

I agree, you can’t use class to represent the role a body plays in an annotation. However, what about the case where such a global assertion is appropriate.

For example (granted this example is BIBFRAME oriented but it’s off the top of my head)  let’s say I want to annotate a BIBFRAME Instance with a cover art and a holding.  I  have a bf:CoverArt and a bf:HeldItem appropriately classed as such respectively.  (The bf:CoverArt would have additional class schema:ImageObject.)

Ray


From: Robert Sanderson [mailto:azaroth42@gmail.com<mailto:azaroth42@gmail.com>]
Sent: Friday, March 20, 2015 12:38 PM
To: public-annotation@w3.org<mailto:public-annotation@w3.org>

Cc: Web Annotation
Subject: Re: multiple bodies and motivations


Thanks all for this great discussion!

I agree that it can't be a class on the Body (or Target) -- that's the issue we solved with the change to the Semantic Tag construction.  The class would be a global assertion, whereas the body may have different roles in different annotations.

Multiple annotations is a possibility, but there's a lot of situations where you want to keep all of the bodies together (such as export from a bookmarking system, like Firefox, where there's both comments and tags together).

To add another option into the mix...

Could we simply allow, but not require, hasMotivation to be added to the SpecificResource class?
Then if it's important to have body-specific motivations, then the model allows it without introducing any new predicates or nodes, but the majority of annotations can just have it associated with the Annotation itself, as per the current model.

Thus add the possibility for the pattern:

<> a oa:Annotation ;
  oa:hasBody _:sp1, _:sp2 ;
  oa:hasTarget <some-uri> .

_:sp1 a oa:SpecificResource ;
  oa:hasMotivation oa:commenting ;
  ... .

_:sp2 a oa:SpecificResource ;
  oa:hasMotivation oa:tagging ;
  ... .


Thoughts?

Rob


On Wed, Mar 18, 2015 at 2:53 PM, Jacob Jett <jjett2@illinois.edu<mailto:jjett2@illinois.edu>> wrote:
Right. And because the roles of bodies in an annotation relative to the targets in that same annotation are contingent on interpretation and context I think that it's beyond the scope of our model to remark on them beyond what the model already says, i.e., whatever is at the body node is playing the role of the body in the annotation. I don't know what more we might say that wouldn't actually begin to interfere with annotation interoperability.

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<tel:%28217%29%20244-2164>
jjett2@illinois.edu<mailto:jjett2@illinois.edu>

On Wed, Mar 18, 2015 at 4:39 PM, Denenberg, Ray <rden@loc.gov<mailto:rden@loc.gov>> wrote:
“there is very little we can realistically do to mandate how specific communities will make extensions for use cases that are outside of the annotation model.”

Right, we can’t mandate interoperability.

But I don’t understand the part about outside the annotation model.  If it’s an annotation outside the model then it is out of scope for us anyway, right?  Anything we spec would pertain to annotations within the model, right?

Ray

From: jgjett@gmail.com<mailto:jgjett@gmail.com> [mailto:jgjett@gmail.com<mailto:jgjett@gmail.com>] On Behalf Of Jacob Jett
Sent: Wednesday, March 18, 2015 5:34 PM
To: Web Annotation

Subject: Re: multiple bodies and motivations

-1 for this. I think it's already well-documented in practice on how to extend vocabularies. We've been doing it for decades with xml.

Also, there is very little we can realistically do to mandate how specific communities will make extensions for use cases that are outside of the annotation model. Since there isn't any mandate that annotation consumers understand community specific specializations of the annotation model, its highly likely that specialized predicates and extraneous typing or graph nodes will probably be ignored by the consumer.

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<tel:%28217%29%20244-2164>
jjett2@illinois.edu<mailto:jjett2@illinois.edu>

On Wed, Mar 18, 2015 at 4:19 PM, Denenberg, Ray <rden@loc.gov<mailto:rden@loc.gov>> wrote:
Depends what is meant by “spec any of this”.  The model should specify or at least recommend how this should be done.  The actual extensions should be developed by the interested communities.

So how is a role conveyed? There are three possibilities:

1.       Intermediate resource

2.       Via property

3.       Via class
If the body is an RDF resource than a property works fine. But if it is, say, an image, it doesn’t.  So a role property won’t work for all cases. I think that classing bodies will work for some of the cases.

In any case the model should provide guidance.  It could say, for example, use a role property if possible; if not, use a class, if appropriate; if not, create an intermediate resource.

Ray

From: Randall Leeds [mailto:randall@bleeds.info<mailto:randall@bleeds.info>]
Sent: Wednesday, March 18, 2015 5:11 PM
To: Denenberg, Ray; Web Annotation

Subject: Re: multiple bodies and motivations

So is there any need for us to spec any of this or should we just leave it to the communities to start experimenting with roles on their bodies?

On Wed, Mar 18, 2015 at 12:25 PM Denenberg, Ray <rden@loc.gov<mailto:rden@loc.gov>> wrote:
Yes, it is recognized (and was mentioned this morning) that the annotation itself has  a primary motivation, which is to be expressed as a property of the annotation.    But I don’t agree with the suggestion if there are multiple bodies with different motivations then these should be expressed as multiple annotations.  I think perhaps these may be “roles” rather than motivations, i.e., what role is a body playing in the annotation.  There have been a number of use cases calling for multiple bodies, where different bodies play different roles, and where creating separate annotations for each body would not be work.  The intermediate resource solves the problem, but as you note, it complicates the model.

And of course (to address Jacob’s point) this would be left to individual communities to develop in the form of extensions.  There is no suggestion intended that we try to develop the entire taxonomy among ourselves.

Ray

From: Randall Leeds [mailto:randall@bleeds.info<mailto:randall@bleeds.info>]
Sent: Wednesday, March 18, 2015 2:41 PM
To: Jacob Jett; Denenberg, Ray
Cc: Web Annotation
Subject: Re: multiple bodies and motivations

More or less +1 to Jacob.
Other concerns are the open world problem of assigning motivations to the body, which may be a resource owned by a different authority than the annotation and a semantic issue that the motivation is really a motivation for involving the body in the annotation activity rather than a motivation for the existence of the body resource itself.
It seems like the most conceptually sound way to handle it would be to have an intermediate resource. That definitely complicates the model.
I think it was suggested in GitHub that perhaps even if the bodies have different purposes the annotation itself has a primary, over-arching motivation and if it seems like there are multiple perhaps multiple annotations is more appropriate.

On Wed, Mar 18, 2015 at 11:12 AM Jacob Jett <jjett2@illinois.edu<mailto:jjett2@illinois.edu>> wrote:
Hi Ray,

My question would be, are we conflating motivation with structural implications? That a thing is a tag seems to me to say more about its intrinsic nature, i.e., a tag is a sort snippet of text, a semantic tag is a named entity, rather than the role it plays in the annotation. That being said I do think that there is likely room in the model for a motivation (or more properly a role) property on the body.

We may want to be cautious here because there will likely be cases where the role a body plays in an annotation is sensitive to the environment the annotation finds itself in. In some environments some text might be explaining the target and in others it might be describing it. Since the model is extensible it might be best to leave it to individual communities to develop value added extensions particular to their annotation repositories rather than try to develop an over-arching taxonomy of body types that will likely be incomplete.

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<tel:%28217%29%20244-2164>
jjett2@illinois.edu<mailto:jjett2@illinois.edu>

_____________________________________________________
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 Wed, Mar 18, 2015 at 12:55 PM, Denenberg, Ray <rden@loc.gov<mailto:rden@loc.gov>> wrote:
We ran out of time while I was on-Q so I’ll carry my thoughts to email.

The issue is multiple bodies with multiple motivations. In the model currently,   a  motivation, applies to the entire annotation. How do you  associate a motivation with a  body.

It seems to me that a straightforward approach is for each body to have a class  (with implied motivation).   Someone mentioned, if it’s a tag, you know it’s a tag. If it’s a sematic tag, you know it’s a semantic tag.  How do you know? Because the body is classed as oa:Tag or oa:SemanticTag.   So it works for those two, why wouldn’t that work in general?

Ray






--
Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305