Re: Philosophy, was framing

Hi Markus,

TL;DR version:  I think we're in violent agreement :)

> > As the framing issue is solved, thanks!, I changed the subject.
> >
> > I have to disagree philosophically with you here.  I think that the
> > JSON-ness (is "jsonic" a word?) of JSON-LD is a huge strength.
> I probably should have been a bit clearer in my last email. I completely
> agree that it is the JSON-ness that makes JSON-LD so powerful and graspable
> for average web developers.

Sorry, I must have misunderstood!

> > If you want to understand why your tools are adding this stupid
> > "@graph" and "@id": "_:b1" crud all over your nice JSON, the answer
> > is... RDF.
>
> Not entirely. The main reason is that the data JSON-LD is serializing is a
> graph and not a tree.

Yes, I understand that. And agree that compaction removes it when it
isn't necessary, which is very helpful.

> There are multiple ways to serialize exactly the same
> graph. The simplest form is to flatten everything and to connect the
> different nodes with links (edges).

Which should be avoided whenever possible, for the same reasons as the
basic rdf/xml being so terrible.

(snip helpful context examples)

There's another way, which would be to do both. Embed the most
connected graph in the root, and then if there are other unconnected
subjects, then /also/ have @graph.  I'm not necessarily promoting
this, mostly as I haven't thought through the consequences, just
throwing it out there.

> But typically, you don't even want such a structure because typically
> there's a single node which could be thought of as the root of a tree
> because it contains links (direct or indirect) to all other nodes. We could
> try to write a complex algorithm to find that node automatically but I think
> that would be too much magic. Publishers know which node it is in most cases
> so it would be unnecessary anyway.

Completely agree, which is why it's a shame that even an extremely
limited version of framing isn't in 1.0, but I look forwards to a time
when it is standardized :)


> > But not even just RDF, it's a choice in the algorithms to
> > include them as there's nothing in the spec that says they have to be
> > there when not necessary.
>
> Right, but as soon as you flatten those bnode ids become necessary because
> otherwise you couldn't connect the different nodes anymore.

True, and as the framing algorithm first flattens everything, it's
hard to tell whether they're needed or not. However the point is when
they're not needed, it would be appropriate to remove them in the same
way as @graph.  I concur that the algorithm to do this is
significantly harder than len(root["@graph"]) == 1


> > That a JSON developer can look at an RDF
> > serialization and instantly understand what is going on, without
> > knowing the underlying model, is /the/ saving grace for the semantic
> > web, IMO.  It is all about being easy /and/ semantic.
>
> Fully agreed. That's exactly the reason why I said you shouldn't use @graph
> in your examples. That however doesn't mean that a (JSON-LD) client can
> safely assume that it will never be there. Or that there won't be a
> top-level array... or different property names.

Right.  This is a 80/20 sort of thing.  Or really a 99/1 sort of thing
for many cases.  If everything is framed+compacted, and the algorithms
do a thorough job, then a client can ignore @graph (etc) 99% of the
time and barf on the 1%.  Whether that's acceptable or not is
situation dependent, of course.


> > So I would implore you to please reconsider the "anti-pattern" stance.
>
> When I talked about anti-pattern I meant the coupling of the client to a
> specific document structure. JSON-LD is all about eliminating that. If that
> wouldn't be the case, all we would have to do is to add a profile media type
> parameter to application/json and call it a day. The profile would then tell
> your client how to interpret that specific structure. But we are not
> interested in the structure, we are interested in the data.
>
> We want be able to mix it with other data. We want to be able to use
> different vocabularies. We want to empower consumers so that they can
> declaratively reshape the data to the most useful form for their use case.
> We want them to be able to easily create an in-memory representation of the
> serialized graph so that they can walk it as they want.
>
> I hope this helps to understand my position.

Yes, thanks for the clarification!

Having the document structure able to be profiled is, in my opinion,
important, and not just in legacy cases.  If you can write extremely
simple code for the 99% of cases by relying on a uniform structure,
that's extremely helpful. And you can do that with framing+compaction,
as discussed.
So far the result of these is almost exactly what you would expect,
other than the unnecessary blank node ids (at least so far in my
experience).

The reshaping use case is much more advanced, probably the 1% of
cases.  While I appreciate it, it's not normally possible at all, so I
wouldn't expect most developers to consider it without having it
really promoted.  Certainly I didn't see it from reading the
documentation.

Rob

Received on Friday, 2 August 2013 22:00:34 UTC