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

Guys,

Reviewing the multi-body annotation pages triggered some comments/thoughts for me. Hopefully these will help in closing this issue soon.

As a reminder, we have five different patterns on that page:

1. role assignments (originally proposed by Ray)
2. role attached to resources (specific or not), originally proposed by Rob
3. roles as subproperties
4. roles as classes, ie, typed bodies or targets

Here are my (random) thoughts:


- I believe that the pattern

  "a" : {
     "b" : "something",
     "c" : "something else"
  }

is a fairly natural pattern in JSON. To be specific, the fact that

"body" : "This image is worth viewing on my desktop."

is transformed into something like

"body" : {
	"source": "This image is worth viewing on my desktop.",
	"role" : "commenting"
}

is not, as far as I can judge, shocking for a JSON user.

Except when "b" or "c" is "id", this pattern translates perfectly well through JSON-LD to RDF: it is a anonymous blank node, ie, where there is even no attempt to provide an identifier. (This is the equivalent of the [...] idiom in Turtle and I changed the Turtle codes to make this analogy very visible). That usage of blank nodes is (should be...) perfectly all right even for the most fervent defenders of the Linked Data principles. (There have even been proposals to define the concept "Well behaved RDF"[1] using that pattern to 'tame' blank nodes...)

In other words, I believe that using that pattern should be something we embrace.

- However, if the blank node is not anonymous, ie, we *must* add an "id": that I think is a problem. It forces the user either to mint a (fairly artificial) URI (eg, a urn:XXXX) or use the _:XXX pattern for a blank node ID. Something that makes the structure more complex, and forces a JSON user to use a notion (the blank node id) which is far from obvious. I believe we should try to avoid that.

This is the reason that I have to agree with Doug that the 'role assignment' approach is probably way too complex for a JSON user, and we should drop it. This in spite of the fact that, from a Semantics point of view, it is certainly attractive (that is why I was in favour of it, originally). Sorry Ray:-)

- The subproperty approach seems to be very simple; the JSON structure (see, eg, [2]) is structurally very close to the serialization without any role assignment (eg, [3]). What worries me the most is the proliferation of additional predicates, and the fact that the environment (including in JSON) has to, in effect, implement the subproperty relationship. Looks a bit as a spaghetti code, and may not be obvious to extend

- The 'role attached to a resource', and the 'role as a class' have a very similar structure when serialized (eg, [4] and [5]). In fact, as I said, the current SemanticTag notion is already a representation of the 'role as a class' pattern. I must admit that I cannot make a big difference between the two; they look fairly similar to me, and I am not sure how I would choose among the two. I can live with both.

A side issue, though: we should align, imho, the Semantic tagging structure to whichever we choose. If we go for the 'role attached to a resource' approach, having semantic tagging as it is now seems to conflate different models; never a good thing...

- As far as I am concerned, the issue on when to use typing[6] is also part of this discussion. Again trying to make life of JSON users easier I would like to try to reduce the usage of "type" to a strict minimum. Following a separate thread, I did not use the embedded resource approach for something like

{
  "value": This image is worth viewing on my desktop.",
  "role" : "commenting"
}

which I would find superfluous. I am also not sure that explicitly typing the oa:SpecificResource is necessary and useful, and it would nevertheless pollute the serialization (again, trying to prune the JSON encoding as much as I can to hide the Linked Data aspects).

- I was a bit mixed up by the presence of oa:item and oa:source. Tim's original examples used oa:item for the target (third scenario) and it was unclear to me why not use, uniformly, oa:source. I changed this to oa:source, but there may be some misunderstanding on my part. Nevertheless, we may want to unify this, too.

I hope these thoughts may be useful...

Ivan

[1] http://dbooth.org/2013/well-behaved-rdf/Booth-well-behaved-rdf.pdf
[2] https://www.w3.org/annotation/wiki/Expressing_Role_in_Multi-Body_Annotations#Role_as_Subproperty_of_hasBody.2FhasTarget
[3] https://www.w3.org/annotation/wiki/Expressing_Role_in_Multi-Body_Annotations#Current_Model_.28no_role_descriptions.29
[4] https://www.w3.org/annotation/wiki/Expressing_Role_in_Multi-Body_Annotations#Role_Attached_to_resources_.28e.g.2C_SpecificResource.29
[5] https://www.w3.org/annotation/wiki/Expressing_Role_in_Multi-Body_Annotations#Role_as_Class.2FTyped_Bodies_and_Targets
[6] https://github.com/w3c/web-annotation/issues/61




----
Ivan Herman, W3C
Digital Publishing Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704