Re: [All] Proposal: RDF Graph Identification

On 8/17/12 8:34 AM, Andy Seaborne wrote:
> On 17/08/12 13:21, Kingsley Idehen wrote:
>> On 8/17/12 7:37 AM, Andy Seaborne wrote:
>>> Like Steve, the name "space" does not work for me either because of,
>>> for example, "data spaces".  We aren't naming from a clean sheet.
>>> "container" works for me in the figure.  Something with the idea of
>>> containing (like 'slot' graph store).  "box"?
>> What about any of the following:
>> 1. RDF data spaces
> The whole idea of aligning to "data spaces" does not work for me as 
> I'd expect it to be a collection of graphs with ontology mappings if 
> taken from the whole adapter-"pay-as-you-go" meta meme in current 
> database research.
> (for anyone lost here :

Note, that doc complete ignores the fact that RDBMS engines have offered 
TableSpaces [1] for eons. The concept of "Data Spaces" (like many 
contemporary DBMS technology efforts) is about decoupling in such a way 
that's RDBMS engine agnostic. Same applies to Views, Triggers, Tables 
(Relations) etc..

RDF, SPARQL, so called RDF stores etc.. are ultimately contributions to 
the intensional DBMS dimension (where relational property graphs are 
strong) that's been overlooked for years.

Deductive database [2] systems tried to tackle these issues with little 
success at a time when we didn't have Internet and Web ubiquity. Thus, 
most failed. Same applies to OODBMS and ORDBMS efforts. These failures 
don't render the work (and associated terminology) from these realms 
useless, hence my eternal tendency to encourage alignment re., terminology.
>> 2. RDF data source names.
> There is something worth considering in "source";
> RDF source
> RDF data source
> Triple source
> Graph source

An RDF data source is a natural compliment to a SQL, ODBC, JDBC etc. 
data source. But, you get better qualification when you as "name" .

ODBC data source names originate from X.500 names.


-- about TableSpaces
-- Deductive DBMS
-- DBMS engines in general .

> ...
>> Backdrop:
>> The terminology alignment between RDF + SPARQL and the broader realm of
>> DBMS technology (esp. because of SPARQL) is ultimately a win-win. In the
>> RDBMS realm (as you and Steve know) we have:
> I agree about the desirability of alignment but getting too close has 
> it's own issues.
>> RDBMS - Relational Tables (while RDF stores are basically Relational
>> Property Graphs)
>> Tables -- Named Relations comprised of n-tuples
>> Data Source Names (DSNs) -- for ODBC,  JDBC etc. access scoped to
>> Tables/Views re. data access by reference pattern
>> Views -- for all intents an purposes this aligns well with
>> backward-chained inference
>> Triggers -- for all intents an purposes this aligns well with
>> forward-chained inference .
>     Andy



Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web:
Personal Weblog:
Twitter/ handle: @kidehen
Google+ Profile:
LinkedIn Profile:

Received on Friday, 17 August 2012 12:59:16 UTC