RE: Philosophy, was framing

On Saturday, August 03, 2013 12:00 AM, Robert Sanderson wrote:
> > 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.

Unfortunately it's not that simple.

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

What's the most connected graph? In a lot of cases that would probably be a
type (such as foaf:Person) if you also count the incoming edges. Even if you
would make that logic quite smart it would yield to a lot of surprising
results.


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

Why do you want those bnode ids to be removed? To save a couple of bytes on
the wire? JSON is not XML. Systems normally ignore additional properties
without problems.

The other thing is that JSON is typically not written by hand. You create it
by serializing some in-memory data structure and you work with it by
deserializing it into another in-memory data structure. So in a lot of
cases, developers don't even seem them (unless they dump everything while
debugging).


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

Right.


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

I think we both mean different things when we say "profiled". I mean the
usage of the "profile" media type parameter which allows a client to request
the data in a very specific shape so that it doesn't even have to understand
JSON-LD. The algorithm is hard-coded against the structure of the *JSON*
reponse.


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

Great. I'm still not sure I understand why those bnode ids are a problem!? I
agree that they don't look nice but technically it doesn't matter. Just
ignore them. It may even simplify some of your processing as you can rely on
the fact that every node will have an @id property.


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

Not sure I follow. What are we talking about here if not about reshaping?
The whole purpose of framing is declarative reshaping.


Cheers,
Markus


--
Markus Lanthaler
@markuslanthaler

Received on Wednesday, 7 August 2013 20:22:02 UTC