Re: Simple Textual Bodies

Hi Stian,

I agree with your a through e, and that the distinction between {"value":
"comment"} and "comment" is minimal.

I would also add:

f)  It only affects people reading and implementing the specification
directly, rather than those using a library that can (trivially) take care
of the distinctions for them.  It does not affect end users in any way. As
such, it is a temporary problem that will become a non-issue before long.

g) It means that we have to talk about JSON-LD serialization directly.  For
systems based on linked data, and might do sensible things like data typing
or language detection, they have to manage the body very carefully to avoid
the natural serializations and instead use a resource instead of a
language/data-typed literal.

h)  As we need to distinguish tags from comments, or otherwise have a very
poor user experience, it makes tags actually harder to produce than
comments... as Doug brought up in the call today.  Then we need body,
tagValue, bodyValue. Until someone wants to have HTML or Markdown or other
format also special cased, and then we need bodyHTMLValue ...  it's a very
short, very slippery slope.


The consensus, if I might try to represent at least my understanding of it,
at the F2F was that it was acceptable on the grounds that it can be put in
only for the most basic clients.  In the current spec there isn't a notion
of conformance requirements or levels, as that will take quite some
discussion to determine which features should be grouped together at which
levels, however plain literal bodies was almost universally agreed to be a
level 0 (easiest) feature that would act as an onramp to more useful and
fully-developed clients at higher levels.

We have had the advantage of three very good years worth of experience,
discussion, and implementation in the CG which others starting out don't
have immediate access to.  And it was extremely contentious over most of
those three years too! Leading developers towards the best path, rather
than requiring that they start at the end when they don't understand why,
does seem like a good idea to me, and I hope to everyone.

So ... I would propose another "solution" which doesn't address the
reasoning requirements, but at least (hopefully) means that it can be
avoided:

3)  Allow literal bodies as per the current ED.  State clearly that this is
a level 0 feature, and that level 1 and above systems SHOULD transform them
into the equivalent resource construction of {"value": "comment"}
Then document that reasoning systems can treat hasBody as it was an
objectProperty once they've done this.

It doesn't resolve your (d), which is the cost of allowing the simplest
case to be the most simple formulation.
To me, this cost is acceptable, as we recommend typing every resource
anyway so literal bodies are something you SHOULD NOT do as it avoids the
easily testable point that you SHOULD have a class.

Rob


On Wed, Nov 12, 2014 at 2:50 PM, Stian Soiland-Reyes <
soiland-reyes@cs.manchester.ac.uk> wrote:

> I have fleshed out some (late-night) comments on my views of having
> literal "body" in (Simple Textual Bodies)
>
> https://github.com/w3c/web-annotation/issues/13
>
> (with examples)
>
>
> In summary, I am fairly strongly against the whole sub-section
>
> http://w3c.github.io/web-annotation/model_fpwd/#simple-textual-bodies
>
> I feel this is breaking the whole model just for the syntactic sugar
> of saving two characters. We are not just proposing a JSON syntax, we
> are proposing a model.
>
>
> http://w3c.github.io/web-annotation/model_fpwd/#embedded-textual-body
>
> should be sufficient.
>
> I don't see a big difference between:
>
>     { "body": "My value" }
>
> and
>
>     { "body": { "value": "My value" } }
>
>
> Specially as this mean you will have predictable typing of the thing
> of the "body" - in many languages it is much nicer to check for
> existence of "value" or not (which you might need to do anyway later)
> - than dispatching on different object types.
>
>
>
>
> My detailed reasons:
>
> a) It means oa:hasBody has to be an owl:AnnotationProperty to cater
> for both literals and resources. This means no OWL reasoning with
> bodies (e.g. classes like "(Part of) this resource is involved in an
> annotation)".
>
> b) It's bad design. It was OK back in the days when Dublin Core
> Element was made (before RDF and OWL). The ambiguous dc:creator has
> caused issues for everyone trying to do any kind of semantics about
> document creators. In 2014 we should know better.
>
> c) Using the "value" key is almost no additional effort - and also
> means that embedded/literal values are always represented the same way
> as Tags, which then can gracefully degrade to be rendered in the same
> way by a consumer .
>
> d) It also means that "body" to an external resource HAVE to be
> expressed as the long-form {"@id": "http://example.com/body.txt" } --
> which is inconsistent with "target".
>
> e) A decision was made about this at the F2F, but I am of the opinion
> that this was informed and not properly considering compatibility with
> existing technology and specifications.  It's possible to vote again.
>
>
>
> I propose two solutions:
>
> 1) Simply promote the "value" solution - show it first without
> format/language etc.  The format/language section can then be a nice
> 'add-on' that implementers see they can add at any later stage without
> changing their JSON structure.
>
> 2) If and only if someone screams - give them { "bodyValue": "The
> Value" }. We can deal with this - but it basically highlight the same
> issue of "having to decide how literal the literal is".)
>
>
> --
> Stian Soiland-Reyes, myGrid team
> School of Computer Science
> The University of Manchester
> http://soiland-reyes.com/stian/work/ http://orcid.org/0000-0001-9842-9718
>
>


-- 
Rob Sanderson
Technology Collaboration Facilitator
Digital Library Systems and Services
Stanford, CA 94305