Re: Philosophy, was framing

Hi Markus,

Flattening the conversation to just the bnode issue, as I think that's
something that we can either make progress on or at least would be
helpful for the community :)

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

Certainly not the bytes over the wire, a few bytes here and there
isn't a big deal, especially with compression.

The issue in my view is one of documentation and understanding why
they're there, and hence what to do with them when they are
encountered.  Yes, I agree that /additional/ properties can easily be
ignored, but @id isn't an additional property, it's one they're going
to encounter frequently with a URI as the value.  If blank node ids
are generated when not necessary, then the developer needs to
understand what a blank node is and its relationship to a resource
identified by a URI.  I'm sure I don't need to point out the many,
many discussions by RDF experts about the nature and use of blank
nodes to demonstrate that this is not something that is obvious or to
be taken lightly.

For example, testing to see if the object has the key '@id' is easier
than testing to see if the value of
'@id' is a URI or a blank node name. Yes, that test is (not
object.has_key('@id') or object['@id'][0] == '_') but developers have
to know to do that, and what that implies.  It's Kingsley's
"deceptively simple" notion.  They're working with blank nodes, but
they don't need to know it. Currently, they do need to know it.


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

Agreed, making it more desirable that the algorithms do the "right"
thing.  Not having to implement the entire RDF stack to interpret the
information is highly desirable, especially in browsers. And not
having to understand the entire RDF stack is even more important when
that isn't necessary to get the job done.

Rob

Received on Wednesday, 7 August 2013 21:49:56 UTC