Bodies resource from Benjamin

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

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

Rob


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