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

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.

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

Manu/Steve:

What do you think?

-- 

Regards,

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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:54 GMT