Simple Textual Bodies

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

Received on Wednesday, 12 November 2014 22:50:58 UTC