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

Need some clarity on the issue of blank nodes.

-- Every annotation has an id.
-- Even without the @id mention, it has a reference url. say a1url.

say JSON at a1url is an object

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


then conceptually I do not see blank nodes

   a1url.a
   a1url.a.b
   a1url.a.c

are all clearly but implicitly id-ed for all needs.

Can someone please explain why we dont have an reference such as a1url
to an annotation out there?

thanks, -dinesh

On Sun, Aug 16, 2015 at 4:20 PM, Ivan Herman <ivan@w3.org> wrote:

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

Received on Sunday, 16 August 2015 17:59:08 UTC