Re: [model] Clarifying annotation architecture

Jacob

I waited on this message since I wanted to see the wisdom of others, of which there has been quite a bit. Apologies for not indicating that was what I was doing.

One item you mention stands out:

> Is there an expectation that other systems containing the pertinent target documents would consume the serialized edit and then execute it on the target documents within their local context? If yes, then doesn't that also open the trust can of worms?ed as

It seems that relevant trust information could optionally be conveyed as provenance information in the current model, or could be managed 'out of band'.

I suspect this needs to be  a security consideration for the serialization deliverable, maybe also for the model and protocol as well.  

It seems the details are out of scope for the WG, though we might wish to consider the support needed.

regards, Frederick

Frederick Hirsch
Co-Chair, W3C Web Annotation WG

www.fjhirsch.com
@fjhirsch

> On Jul 22, 2015, at 1:54 PM, Jacob Jett <jjett2@illinois.edu> wrote:
> 
> Hi Frederic,
> 
> So I have some additional questions.
> 
> If I understand your suggestion correctly, each annotation (with multiple bodies having their own motivations) would simply be a named graph. From a semweb perspective this raises a question of what the annotation uri identifies -- an annotation or the structure of that annotation? These are distinct concepts and folks that employ semweb tools like reasoners will find their tools drawing different conclusions about the "annotation".
> 
> Something that I think is also missing from this discussion is that the standard we're developing is designed as the data sharing layer between similar clients and is intended more as a "how should I serialize the data" than a "how should I build an annotation client for my users". 
> 
> I think one of the problems with what Doug has suggested is that it complicates how client's that consume annotation's will have to be implemented. The example is also an edge case. With comments, highlights, tags, etc., it's very clear that the client will just display something to the end user. Edit's on the other hand imply much more structured workflows whose end result is the destruction of the target (either through replacement, modification, addition, or subtraction of things). 
> 
> I'm not certain how this kind of annotation would be valid, except during the brief course of time that it exists inside of the client itself (i.e., during the editing process). How meaningful are "editing" annotations going to be outside of their local context? If we have an inkling that they won't be very meaningful then why would we even bother to serialize this kind of annotation?  
> 
> Is there an expectation that other systems containing the pertinent target documents would consume the serialized edit and then execute it on the target documents within their local context? If yes, then doesn't that also open the trust can of worms?
> 
> What are the other use cases that necessitate Doug's proposed solution over one of the alternatives? 
> 
> Is this a situation where a major revision to the model is being proposed to service an edge case?
> 
> Thanks,
> 
> Jacob
> 
> 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
> 
> _____________________________________________________
> 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 Wed, Jul 22, 2015 at 11:28 AM, Frederick Hirsch <w3c@fjhirsch.com> wrote:
> (not as chair)
> 
> I think Doug brought up some important concerns on the call today about the visibility and impact of semantic web constraints on the annotation architecture, in particular the model.
> 
> Here are some statements that I think we agree are true:
> 
> 1. Our goal is wide adoption of Web Annotations by end users and implementers.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 4. We need a clean and straight-forward model to support these use cases.
> 
> 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).
> 
> 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.
> 
> We appear in the discussion to be creating complicated approaches to enable global triples while solving the annotation need.
> 
> 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?
> 
> 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.
> 
> Thanks
> 
> regards, Frederick
> 
> Frederick Hirsch
> 
> www.fjhirsch.com
> @fjhirsch
> 
> 
>

Received on Monday, 10 August 2015 19:19:50 UTC