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

On Tue, Aug 18, 2015 at 4:26 PM, Doug Schepers <schepers@w3.org> wrote:
>
> 1) We allow (but don't require) an "id" property on each object, to make
> it addressable;
>

+1. This isn't a change, and we can't require that resources do not have
identity, so I don't see that there's any other option.


> 2) We strive for a single consistent structure that applies equally to
> Body, Target, Tag, and so on, modulo the proposal in #3.
>

+1. One simple way for everything is better than two simple ways, but one
simple way for some things and one complex way for the minority of cases is
better than one complex way for everything that then doesn't get used.


> 3) We make the nested "source" object a SHOULD, while the empty-node
> construct is only a MAY, and only allowed for text-literal resources, and
> (maybe?) only in a non-Linked Data context; we define a clear equivalence
> mapping.
>

Sure. +0.9

Sub proposals:

3.1) I'd go further to be explicit that the nesting is for consistency to
make developers' lives easier.  [one way > two ways, per 2]

3.2) We could also define a subClass of
the-class-currently-known-as-EmbeddedContent for Bodies that allows roles
to be associated with it, which would make it clear that embedded
stylesheets do not get roles.  In the JSON, they could then have different
type property values for clarity, if needed.  [Be explicit and rigorous in
the model, hide the details from developers unless needed]

3.3) We should explicitly state that systems MAY translate between
equivalent structures as desired, similar to the ability to translate from
a literal body to a body as a resource... so even though you sent in one
form, the receiving system may process it into another form.

Essentially the "Role Attached to SpecificResource or EmbeddedContent"
option, with a preference for using SpecificResource.


4) We define the default type of "value" to be "text". We require explicit
> "type" values for all other datatypes.
>

If there was a new EmbeddedTextualBody class per 3.2, it wouldn't be
necessary to have a default.  Systems could infer that specific class for
bodies that have a value property.

4.1) If we wanted to be very explicit, we could define our own property
just for this that wasn't "value".

{
 "body": {
    "role": "tagging",
    "content": { "text" : "+1" }
  }
}

As opposed to value for things that aren't embedded representations of
resources, such as in FragmentSelector:

"body" : {
    "role": "commenting",
    "selector": {"type": "FragmentSelector", "value": "xywh=0,0,100,100"},
    "content": "http://some.url/image.jpg"
}

Reuse when it makes sense ... and maybe it doesn't make sense here. The
original ContentAsText spec invented two such properties (bytes and chars)
so we would still be improving the situation!

So I'm +0 on 4 ... because I think it's unnecessary given 3.2 and 4.1?  But
let us know what you think.


5) We continue to discuss property names that might be more intuitive. For
> example, I find "source" less clear than "content", and I'd like to see
> different proposals for the terms "EmbeddedContent" and "SpecificResource".
>

Sure. Naming, as opposed to correct structure and semantics, is the least
of my concerns :)  You can call it a F5D28594-021D-426A-B169-A1E8167D5BA6
if you want :) [As editor, I'd prefer you didn't tho!] The advantage of
JSON-LD is that others who really prefer a different name can still call it
whatever they want too, by defining a different context for the same
properties and relationships.

Thank you very much for the concrete proposal Doug, it's greatly
appreciated, and I hope that the above agreement is encouraging to everyone.

Rob

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