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

On Wed, Aug 19, 2015 at 9:11 AM, TB Dinesh <dinesh@servelots.com> wrote:

> > 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:-)
>
> JSON-LD is JSON
>

So...this is actually not true...as it turns out. :) The underlying data
models are different. The only hope is to make them not collide (too often).

For instance, according to JSON-LD's spec, the first 4 tabs on any example
in the JSON-LD playground are *equivalent*:
http://json-ld.org/playground/

In JSON, they don't match in the least, and would each have separate
parsing code to handle the "crazy" format changes.

To JSON-LD, they're all the same graph, just serialized differently.

It's analogous to RDFa in HTML.


> so the pattern should be normal way of pointing


> i.e.,
>
> >> a1url a a1url/a ;
> >> a1url/a b "something" ;
> >> a1url/a c "something else" ;
>
> from outside the document
>
>  a1url a a1url.a ;
>  a1url.a b "something" ;
>  a1url.a c "something else" ;
>
> provided that we assume the root id a1url is where the JSON document is.
>
> b and c are also pointed by a1url.a.b and a1url.a.c
>
> Just that this thought helps reduce the blankness of Bnodes a bit for me.
>

This conversation definitely needs it's own thread. :)

Turning blank nodes into something meaningful is as easy as setting "@id"
to some value. Now...that value should be an absolute URI (URL, URN, IRI,
et al) or if it's a relative URI, it is relative to a) @context's @base (if
set) or b) the URL the JSON-LD was served from. @base is analogous to
HTML's base tag, so it acts essentially the same.

Does that solve the problem?

If not, could you start a separate thread for it? ^_^

Cheers!
Benjamin
--
Developer Advocate
http://hypothes.is/


>
> -dinesh
>
>
> On Wed, Aug 19, 2015 at 9:53 AM, Ivan Herman <ivan@w3.org> wrote:
> >
> >> 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
> >
> >
> >
> >
>
>