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

> On 18 Aug 2015, at 04:04 , TB Dinesh <dinesh@servelots.com> wrote:
> 
> Thanks Ivan,
> 
> Trying to read-up more on JSON-LD. It seems like JSON and JSON-LD are
> not intuitively like each other when it comes to pointers.
> 
> What I am asking is, is not
> 
> a1url a _:SomeBnodeIdentifierTheSystemGenerates ;
> _:SomeBnodeIdentifierTheSystemGenerates b "something" ;
> _:SomeBnodeIdentifierTheSystemGenerates c "something else" ;
> 
> is simply this
> 
> a1url a a1url/a ;
> a1url/a b "something" ;
> a1url/a c "something else" ;
> 
> I am thinking of how deeper structures would be natural as in
> @specificResource case
> and this would then simply id1/attr1/deeper2/attr1 like pointers to
> substructures.
> If there are also @ids explicit in substructures they would be many
> ways of reaching there,
> like in XPath and all

Well… the only thing I can say is that this may indeed be a way to define things but this is not what JSON-LD does:-)

Ivan

> 
> -d
> 
> 
> On Mon, Aug 17, 2015 at 10:32 AM, Ivan Herman <ivan@w3.org> wrote:
>> 
>>> On 16 Aug 2015, at 19:58 , TB Dinesh <dinesh@servelots.com> wrote:
>>> 
>>> 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?
>> 
>> In an RDF graphs, there are three different types of nodes in a graph: Literals, URI references, and blank nodes. Blank nodes do not identify a specific resource on the Web (like URI References do). They can be seen as 'anonymous nodes' or, put it another way, as existential statements; a triple of the form (B p o), where B is a blank node, can be read as "there is a node related to 'o' via 'p'", but there is no known identifier. Consequently, a blank node is considered to be purely local to an RDF graph; ie, two RDF graphs' blank nodes should be considered as strictly different.
>> 
>> Putting it in an annotation, if the pattern is:
>> 
>> {
>>  "@id" : "a1url",
>>  "a" : {
>>       "b" : "something",
>>       "c" : "something else"
>>   }
>> }
>> 
>> (Note that I explicitly give an ID to the annotation!) the JSON-LD rules means that we have created a new B node, and we do not even care to give it a name (the RDF system is supposed to provide a fully unique name behind the scenes that is not considered as a URI) that is the object of "a". Ie, in an RDF system, this pattern gives
>> 
>> a1url a _:SomeBnodeIdentifierTheSystemGenerates ;
>> _:SomeBnodeIdentifierTheSystemGenerates b "something" ;
>> _:SomeBnodeIdentifierTheSystemGenerates c "something else" ;
>> 
>> Ivan
>> 
>> 
>> 
>> 
>>> 
>>> 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
>>>> 
>>>> 
>>>> 
>>>> 
>> 
>> 
>> ----
>> 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
>> 
>> 
>> 
>> 
> 


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