W3C home > Mailing lists > Public > public-rdf-wg@w3.org > February 2013

Re: Blank Node Identifiers and RDF Dataset Normalization

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Wed, 27 Feb 2013 11:36:03 -0500
Message-ID: <512E35F3.3070808@openlinksw.com>
To: Steve Harris <steve.harris@garlik.com>
CC: Manu Sporny <msporny@digitalbazaar.com>, RDF WG <public-rdf-wg@w3.org>, Linked JSON <public-linked-json@w3.org>
On 2/27/13 10:37 AM, Steve Harris wrote:
> I don't want to throw numbers about, but for us the cost of anything that significantly decreases the efficiency of our RDF storage carries a huge monetary cost - we couldn't justify it without a significant upside.
This is a very important point, and from the DBMS engineering 
perspective it's true. There are costs to existing RDF stores and DBMS 

A suggestion:

Manu: JSON-LD should make a note about the use of bnodes to denote 
graphs. That note could then hone into its special use case scenarios 
e.g., where there's high velocity data with little mass.

As already acknowledged above, you are correct about the optimization 
cost to existing RDF stores and DBMS engines (it will hit Virtuoso too) 
. Thus, when our engines encounter such data, we could simply  just 
remap the IRIs as part of our data ingestion (insert | import) routines. 
That's what we'll end up doing.

Naturally, this means tweaking existing code re. data import, ingestion, 
and creation etc.. Personally, I believe we have the ability to close 
out this matter without holding up the various workgroups i.e., RDF 1.1 
stays as is. JSON-LD has a fleshed out version of the note I suggested 
to Manu etc..


What do you think?



Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen

Received on Wednesday, 27 February 2013 16:36:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:02:10 UTC