RE: [model] Clarifying annotation architecture

Was writing in parallel with Frdrick, so this replies primarily to the overall proposal, not Fredrick's comments.

The proposed approach does stretch the meaning of motivation.  

Annotations clearly can have motivation -- i.e., why am I motivated enough to create an annotation connecting a body(ies) to a target(s).  Applied to individual specific resource bodies, I'm saying something a little different. In part at least I am describing the nature of the relation between a specific body and the annotation target(s) in order to differentiate it from the relation that another body in the annotation has to the same target(s). Or else I am providing hints about how an application needs to treat a specific body (as different from how it might treat another body in the annotation) -- for example, in the copy edit case, I want to make sure the application knows which of the 2 bodies in my annotation is meant to replace the existing text.  

But this is a small matter. I'm basically okay with the proposal. If there is consensus we can discuss separately whether we need to rename the predicate and/or whether an additional predicate is required (e.g., along the lines of the expectation predicate proposed early on in the Community Group. 

However, (IMO) this only solves some of the use cases raised.  I think we separately may still have use cases where the intent in adding a body is to provide additional information about the connection between other bodies present in the annotation and the target. For example, again returning to the 2-body copy edit case, a second body, explaining why the edit is needed, does not really stand alone as an annotation of the target (or at least it would not given the way that most people would use it ). The comment / explanation only make sense in the context of the proposed edit. In prior discussion of annotations without a multiplicity construct, the test has been that the annotation could be decomposed into multiple annotations of 1 body each with out changing the meaning. or put another way, you could drop any body in the annotation and not invalidate the annotation (see 3.2.9 of the data model -- "This construction may be used so long as dropping any of the Bodies or Targets would not invalidate the Annotation's meaning.").   So for this variation of the copy-edit use case I prefer the annotation of an annotation approach. 

And this still suggests that a means in the protocol (separate from the data model) of posting and retrieving a single graph containing multiple annotations that an implementer or a server has seen fit to generate or make available as a single graph would be useful. Given our reliance on LDP and allowing annotations to be in direct / indirect containers, this seems relatively easy to include as an option. Users not interested in bundling annotations would not make use of this feature. Clients who wanted to think of multiple related annotations as a single JSON could do so. The bar would be raised slightly for server implementations that wanted to include this functionality, but again it's mostly built into LDP.

-Tim Cole


________________________________________
From: Frederick Hirsch [w3c@fjhirsch.com]
Sent: Wednesday, July 22, 2015 13:27
To: Robert Sanderson
Cc: W3C Public Annotation List
Subject: Re: [model] Clarifying annotation architecture

Rob

Thanks for the detailed response.

see inline for my core question.

regards, Frederick

Frederick Hirsch

www.fjhirsch.com
@fjhirsch



> On Jul 22, 2015, at 2:01 PM, Robert Sanderson <azaroth42@gmail.com> wrote:
>
>
> I'd like to focus on the goal:
>
> Our goal is to build on a linked data/semantic web technology foundation while making it invisible to implementers or users that don't know or care.
>
> We already have this, thanks primarily to JSON-LD and then further constraining the serialization structure with framing, as identified by the profile.  The (IMO) easiest change to support the desired functionality is to allow motivations on specific resources (broken record, I know).  We already have all of these in the model, so we're not introducing anything new. We already have all of the properties and values. It's just allowing an existing property to be used with an existing type of resource.  That seems about as clean and straight forward as we can get.
>
> And it's invisible to implementers that don't know or don't care ... they can construct the JSON as per the specification and it will just work.
>
> For people who want to understand *why* we're doing it that way, they clearly care. And if they care enough they can understand the requirements that brought us to the solution.  If they don't care enough to understand, that's perfectly fine too.
>
>
>
>
>
> On Wed, Jul 22, 2015 at 9:28 AM, Frederick Hirsch <w3c@fjhirsch.com> wrote:
> 1. Our goal is wide adoption of Web Annotations by end users and implementers.
>
> +1
>
> 2. Many of these users and implementers neither know nor care about the semantic web; however we see value in having an underlying semantic web basis, hidden from those who don't care. We expect this will offer power and flexibility enabling more use cases in the future.
>
> +1
>
> Our goal is to build on a linked data/semantic web technology foundation while making it invisible to implementers or users that don't know or care.
>
> +1
>
> 3. We have use cases such as associating multiple 'tasks' in a single annotation: e.g comment on target and also provide replacement action on same target.
>
> +1
>
> 4. We need a clean and straight-forward model to support these use cases.
>
> +1
>
>
>
> Here is the issue that appears to have come up:
> Without understanding linked data, it seems that we could model the related tasks as a single annotation with different roles on each part (per use case task).
>
> Without understanding the full set of requirements, there could be easier ways to accomplish the various tasks individually. I think that's true of any non-trivial system with more than one requirement.  It just so happens that the way to accomplish this task is not the simplest possibility, without taking in to account the rest of the system.
>
>
>
>
> From a linked data perspective, the issue appears to be that all triples (assertions) are global scope leading to complexities that make no sense to those unaware of the semantic web relationship to annotations.
>
> Yes.   That is a requirement of linked data.
>
> We appear in the discussion to be creating complicated approaches to enable global triples while solving the annotation need.
>
> I strongly disagree.  It's not complicated to add an existing motivation to an existing class with an existing property.
>
>
> I am not a semantic web expert, but wouldn't treating each annotation as a separate graph (in the case where there are multiple 'tasks') solve the global triple scope problem, without requiring any more than a note to semantic web implementers?
>
> As previously, we don't have that option.  The global triple scope "problem" is a design decision of RDF, and is acting as intended.  To throw out the global scope of assertions is to throw out linked data.  To do that would be to start again from zero. That's a possible route, but there would be more appropriate chairs and editors than myself.
>
>
> Perhaps someone can elaborate with a clear and short summary of the problem we need to solve and the potential solutions to date.  Corrections on what I noted above are also welcome.
>
> The problem is being able to determine the specific role of a body within an annotation that has multiple bodies.
>
> The solutions proposed:
>
> * Associate the role with the body directly.  Fails because it makes the body un-reusable, which for the image/video or similar case is not acceptable.

This statement is a key issue and I think Doug was asking about this as well during the call.

The failure scenario is not clear. Un-resuable  : re-used by whom and for what?

If I forget the semantic web (for a moment) I can have an object, say a body, that has properties, including hasSegment or role and two bodies could have different values for the properties.

The only re-use issue would be an implementation optimization (e.g. I don't want to duplicate an embedded image/video to save space)

In semantic web terms:

annotation1 has body1.

annotation1 has body2.

body1 hasRole A.

body2 hasRole B.

so where is the problem, and where is the re-use?


> * Use different relationships for the roles, such as hasComment rather than hasBody.  Fails because motivations are community and use case specific, and without semantic web inferencing you couldn't tell whether hasComment was a body or not.  Not acceptable to require inferencing [per invisibility], nor to have an annotation that you can't do anything with.
> * Use multiple annotations (in various ways).  Fails as being more complex than all other alternatives, and we have no way at the moment to treat the set as a single entity.
>
> * Associate the role (motivation) with a specific resource. Works as expected without changing the semantics, breaking linked data, or introducing any new classes or properties.

isn't a body a resource? If it isn't a resource, what is it?

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

Received on Wednesday, 22 July 2015 18:44:08 UTC