W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2009

Re: [BlankNodeRefs] Questions on blank node refs

From: Ivan Mikhailov <imikhailov@openlinksw.com>
Date: Thu, 19 Mar 2009 12:40:49 +0600
To: Lee Feigenbaum <lee@thefigtrees.net>
Cc: SPARQL Working Group <public-rdf-dawg@w3.org>
Message-Id: <1237444849.4902.5216.camel@octo.iv.dev.null>

I'd say that blank nodes are especially useful due to their "volatile"
nature. If a thing may have some meaningful name and continue to exists
even if its properties change then a thing can be named by an IRI.

There existed funny processors for crypto and other security-aware
applications. They do not allow cast from scalar to pointer or back,
they restricts pointer arithmetic and they do not allow storing pointers
to some regions of address space in main memory. As a result, the
internal security is simple: a procedure can not perform unwanted access
to sensitive data because there is no way to place an arbitrary pointer
to the register or to save a legally obtained pointer and to try using
it much later in hope that it will point to others' sensitive data that
are occasionally placed into same place in memory. The only way to
access important data is to start from some pointer to one of "boot"
structures that are given by supervisor and dereference structure after
structure till the needed datum at the end of path, and no one pointer
"survive" after completion of the procedure.

Blank node refs resemble that security-aware pointers to me, and they
let us keep data integrity only while all their uses are short in time
or serialized by an explicit transaction mechanism. When persistent,
there's too much room for race conditions. That does not prevent a
developer from writing good applications, of course, but it adds too
much new ways of writing bad code :)

The need in persistent bnode ref could be seriously reduced by extending
the language in other ways and providing convenient ways of referring to
nodes by their connections. Many uses of the feature could be eliminated
by good expressivity for phrases like "fourth member of the list that is
property P of S" or "node that is N-th item of ordered list and N is one
plus index of X in same list".

These reasons are informal and a bit messy, they explain only why I
don't want to give "+1" to the feature. In addition to them, there's a
formal reason for "-1". Persistent bnode refs will prevent us from
running round-robin load balanced services on "almost identical" but not
identical boxes, when bnodes may get different internal IDs on different

Best Regards,
Ivan Mikhailov
OpenLink Software
Received on Thursday, 19 March 2009 06:41:30 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:56 UTC