RE: [model] Clarifying annotation architecture

Specific resource approach works for me.

(For the record, just because pointed out the additional potential approach of annotating the annotation, doesn’t mean I necessarily think it’s the best approach.)

Ray

From: Robert Sanderson [mailto:azaroth42@gmail.com]
Sent: Wednesday, July 22, 2015 2:01 PM
To: Frederick Hirsch
Cc: W3C Public Annotation List
Subject: Re: [model] Clarifying annotation architecture


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<mailto: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.
* 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.


Rob

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