- 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>
Lee, 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 boxes. Best Regards, Ivan Mikhailov OpenLink Software http://virtuoso.openlinksw.com
Received on Thursday, 19 March 2009 06:41:30 UTC