W3C home > Mailing lists > Public > public-annotation@w3.org > August 2015

RE: My thoughts on the multi-body alternatives (as shown on Tim's wiki page)

From: Timothy Cole <t-cole3@illinois.edu>
Date: Tue, 18 Aug 2015 15:01:48 -0500
To: "'Doug Schepers'" <schepers@w3.org>, "'Robert Sanderson'" <azaroth42@gmail.com>
CC: "'Ivan Herman'" <ivan@w3.org>, "'W3C Public Annotation List'" <public-annotation@w3.org>
Message-ID: <008001d0d9f0$b8284650$2878d2f0$@illinois.edu>
Doug-

I do tend to agree with others that we have at times conflated tree vs. graph serialization issues with data model complexity required to support extensibility, a broad range of use cases and interoperability.  Obviously we all recognize that if we were dealing exclusively with textual targets in bodies the data model could be simplified. Similarly if were dealing exclusively with use cases in which all annotation bodies are created at the time of annotation, things would be easier.  But we're not.

For me, the defense for excluding the 2 serializations illustrated below stem in one case from a desire to support aggregation and data mining of annotations (interoperability) and in the other case from wanting to be cautious about laying traps for developers embedding textual content in their annotations. See embedded below.

> -----Original Message-----
> From: Doug Schepers [mailto:schepers@w3.org]
> Sent: Tuesday, August 18, 2015 2:22 PM
> To: t-cole3@illinois.edu; 'Robert Sanderson' <azaroth42@gmail.com>
> Cc: 'Ivan Herman' <ivan@w3.org>; 'W3C Public Annotation List' <public-
> annotation@w3.org>
> Subject: Re: My thoughts on the multi-body alternatives (as shown on Tim's
> wiki page)
> 
> Hi, Tim–
> 
> On 8/18/15 2:59 PM, Timothy Cole wrote:
> >
> > [Some of this may be moot given the thread Doug started, but I wanted to
> > close the loop (and had some computer issues last night).]
> 
> Yes, this topic has spawned many threads, and I'm as guilty of that as
> anyone. It's making it hard to follow coherently, at least for me. :(
> 
> 
> > Indeed, I had forgotten the non-body use of EmbeddedContent for the
> > stylesheet and selector. (Would it be worthwhile creating a class and
> > predicate name index for the model document?)  These additional uses of
> > EmbeddedContent Class do make attaching hasRole less desirable (though
> > not out of the question). I also take your point that allowing hasRole
> > only on the SpecificResource class simplifies the filter pattern for
> > including proper default type:value via framing (so they don't have to
> > be explicit in the JSON). So assuming the following patterns are what
> > you have in mind, I concur:
> >
> > "body": {
> >     "role": "tagging" ,
> >     "source": "http://example.org/tagPlus1"
> > }
> >
> > "body": {
> >     "role": "tagging" ,
> >     "source": { "value": "+1" }
> > }
> >
> > Which look quite reasonable. The trade-off of not allowing hasRole on
> > EmbeddedContent is that we'll need to explain / defend why the
> > following, which will likely seem intuitive and natural to at least some
> > JSON developers, is not considered equivalent:
> >
> > "body": {
> >     "role": "tagging" ,
> >     "value": "+1"
> >   }
> 
> Yes, thank you! This is what I've been trying to convey all along… if we
> must require a more complex structure, then we need to explain why in a
> way that's relevant to those JSON developers, not simply as a
> justification for a technology that that is irrelevant to them.
> 
> Rob's notion of multiple-structure consistency is the best explanation
> I've seen yet. But in most explanations, that's taken a backseat to all
> the RDF requirements.
> 

So, here, for me, while the reuse argument is technically correct (and is already well covered by Rob's most recent post), I am persuaded more by being willing to exclude a serialization approach that doesn't save you much and might lead developers down the path of thinking they could put a role on any EmbeddedContent, e.g., on stylesheets (e.g., section 4.4.1, Serialization Example 55) and text-based selectors (e.g., an SVG (XML) area selector, Section 4.2.3.1, Serialization Example 43).  I'm generally not enthusiastic about protecting developers from themselves, but I can see a developer saying well if I can put a role on an embedded annotation body then I can put a role on an embedded CSS stylesheet I'm including to help make sure my annotation looks the way I want it to.  If we collectively feel this kind of thing is so remote (at least as remote as reusing text snippets created for one annotation in another), then maybe we could allow. 
    
> 
> This is important because I expect that other implementors are likely to
> extend the data model to add their own implementation-specific metadata,
> and if they don't understand the structure of the data model, and why
> the data model has that structure, they may produce content that breaks
> that model.
> 
> On that point, maybe it might be worthwhile to include some advice in
> the spec on how to extend the data model in a way that's consistent and
> compatible.

+1 (or in an adjacent document if explanation gets too long)
> 
> 
> > And of course regardless we will still need to explain / defend why the
> > following is not considered equivalent:
> >
> > "body": {
> >     "role": "tagging" ,
> >     "id": "http://example.org/tagPlus1"
> > }
> >
> > I think this can be done, but we should think about how best to do so.
> 
> I don't think it's likely that JSON folks would do that, but it's
> possible, and I admit that I don't understand why that's not equivalent.
> 

Here re-use of an external resource is much more likely annotation to annotation, and I think Rob has answered well in his most recent post.  I will add that this would especially be a problem for use cases involving the aggregation / sorting / mining of annotations and annotation bodies which was thought by the Community Group (and I agree) to be an important use case.

Thanks,
Tim Cole


> 
> […snipping the extra question…]
> 
> Regards–
> –Doug
Received on Tuesday, 18 August 2015 20:04:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:39 UTC