Re: Bodies resource from Benjamin

On Tue, Sep 1, 2015 at 11:21 AM, Robert Sanderson <azaroth42@gmail.com>
wrote:

>
>
>
>> Where this is trending now in my head is that we *keep* motivation on the
>> annotation, but create classes for bodies. What this *might* look like in
>> JSON-LD is something like:
>>
>> ```
>> {
>>   "type": "Annotation"
>>   "motivation": "editing",
>>   "bodies": {
>>     "tags": ["correction", "typo"],
>>     "comment": "wow...I should learn to type...",
>>     "edit": {
>>       "original": "itinirary",
>>       "replacement": "itinerary"
>>     },
>>     "related": ["http://dictionary.reference.com/browse/itinerary"]
>>   },
>>   "target": "http://example.com/doc1"
>> }
>> ```
>>
>> Obviously, this is pretty loverly JSON, but unlikely to be accurate (or
>> terribly extensible) JSON-LD in its current form.
>>
>
>
>> However, I do think this addresses the potential tangle we'll have by
>> using the SKOS concept-based motivations as Roles on bodies, it likely
>> deals with Bill's concern about performance, and MAY still provide
>> extensiblity without too much pain...I hope.
>>
>> The summary would be:
>>  - keep `motivation` on Annotation
>>  - create a `bodies` JSON-LD @set object (which would differ from `body`
>> in its use)
>>  - craft custom classes (/me ducks) for things in the `bodies` set for
>> our currently known use cases
>>  - create a pattern for extending these classes and the creation of new
>> ones
>>
>
> -0.999
>
> * Added complexity of the bodies resource in both JSON and RDF
> * Duplication of motivation as instance and properties of bodies resource
> * Current use cases would very quickly get unmanageably large in this
> scenario, where you need specific support for something rather than just
> minting a new motivation instance
> * A pattern for extension that doesn't involve subProperties is what we
> have now.
> * The class would be necessary in the serialization if the intent is that
> it is the extension point
>
> I think we're at the point of recording a decision and moving on, but I'll
> grant that a new resource under the annotation has not been discussed or
> proposed previously.
>

Yeah...sorry this is late in the game (re: this CfC vote). It came out of
exploring the multiple tags example last night (tnx for the merge, btw!):
http://w3c.github.io/web-annotation/model/wd/roles.html#text-tag-example

I wanted to see if there was a way to do that more simply and intuitively
from the JSON perspective--from what I understand this is what Bill was
after originally (more or less).

Using this "body classes" idea, developers can get the list of tags by
doing:
```
tags = doc.bodies.tags; // no loop
```

Vs. the current role on body proposal:
```
tags = doc.body.map(function(body) {
  if (body.role === 'tagging') {
    return body.content.text; // assuming text tags
  }
});
```

That's a performance hit on a single annotation, but given Bill's use case
of 20k annotations + multiple bodies...that would get painful.

However, I'm also willing to say that "this isn't that format"--meaning,
this isn't the format that UI developers should plan to consume directly
"at scale" and that we should expect (and even encourage) some level of
conversion...somewhere...prior to it hitting the UI. But...if that's the
case, then do we need/want to spec that to?

Here's a quote from our charter for reference:
> The goal of this Working Group is to provide an open approach for
annotation, making it possible for browsers, reading systems, JavaScript
libraries, and other tools, to develop an annotation ecosystem where users
have access to their annotations from various environments, can share those
annotations, can archive them, and use them how they wish.

Obviously, if this is the interchange / interop format, then we can put
some amount of "loop performance" cost complaints aside in favor of
expressiveness and extensibility--which is our current focus (and really
should remain the central one).

If this is also meant to be what browsers, readers, etc. someday directly
consume (from a server, disk, cache, etc), then we MAY want to have a
keener eye toward dealing with these concerns.

Can we do both? :) Should we discuss (again) a "plain JSON" format (similar
to the above, perhaps) that focused entirely on the 80% "social annotation"
use cases and sets aside (some) extensibility in favor of performance and
encouraging adoption?


>
> If you get any further, please do write up a proposal.
>

In all honesty, I'm at odds within myself on this one. :-/

This, if done, would start to look like the class hierarchy of
schema.org--with all it's....depth.

I'm going to keep chewing on it, but if others who try to bridge the divide
between the RDF-and-JSON worlds want to pitch in thoughts, concerns, or
code (!), that would be a great help.

Sorry if this is distracting noise. :-/ Regardless of these concerns, I
think the Roles document is a Good Thing and a positive iteration on the
current model FPWD.

Onward annotators!
Benjamin
--
Developer Advocate
http://hypothes.is/


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