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

Slightly tangential to the general timbre of where I think this
conversation is going but +1 to providing advice to developers.

For what it's worth Paolo had started developing a cookbook for the OACG (
http://www.w3.org/community/openannotation/wiki/Cookbook). Perhaps this
work needs to be resurrected and resumed.

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

On Tue, Aug 18, 2015 at 3:01 PM, Timothy Cole <t-cole3@illinois.edu> wrote:

> 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
>
>
>