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

On Tue, Aug 18, 2015 at 11:59 AM, Timothy Cole <t-cole3@illinois.edu> wrote:

> Rob-
>
> 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?)
>

Yes ... particularly if we could automate it rather than having to update
it by hand.



> These additional uses of EmbeddedContent Class do make attaching hasRole
> less desirable (though not out of the question).
>

Agreed with less desirable but possible.


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

If we can require that pattern I would quite honestly be overjoyed.




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

Yes. The @id makes it stand out as special. "@id" is the identity of the
object that has the properties and relationships.  "id" is less obviously
special.



>  Lastly, I wanted to confirm one edge case regarding use of
> SpecificResource, hasSource and dc:format. Is the following okay (assuming
> a community wanted to define an xPathSelector subclass of oa:Selector,
> details not defined here)?
>
>
>
> "body": {
>
>    "role": "commenting" ,
>
>    "format": "text/plain" ,
>
>    "source": {   "id": "http://example.org/tei.xml" ,
>
>                             "format": "text/tei" } ,
>
>   "selector": { ... an xPathSelector ... }
>
> }
>
>
I personally don't have a problem with that.  The result of applying the
selector to the source is some plain text.   The same way that the result
of getting a segment of an image is an image and so on.

That said, I don't think we need to document it in the model?


Rob