RE: Philosophy, was framing

On Wednesday, August 07, 2013 11:49 PM, Robert Sanderson wrote:
> 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 :)

OK


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

Fair point.


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

And you think explaining a blank node id as an internal identifier, a local
variable or something else familiar to average developers wouldn't do it? In
the end, it's like a memory address that you need to create pointers to.
Those "memory addresses" don't have any meaning outside of the current
process/machine/document.


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

Well, looking at discussions by RDF experts isn't a good measure by any
means I would say :-P httpRange-14, anyone?


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

That's only correct if the document contains *no* blank nodes. If there's
also just a single one, you'll need both checks instead of just one.


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

That's the question. Do they? What if you look at is as a URL (with a _
scheme)? Obviously it doesn't resolve but so what? What problems do you
expect in practice?


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

Couldn't agree more but I'm still not convinced that those additional blank
nodes will result in problems or confusion in practice. We are currently not
working on Framing, so I would suggest we put this discussion on hold till
we pick it up again. I've created ISSUE-293 [1] so that we don't forget it.


[1] https://github.com/json-ld/json-ld.org/issues/293



--
Markus Lanthaler
@markuslanthaler

Received on Thursday, 8 August 2013 21:25:33 UTC