Proposal for three tier RDB2RDF standard - and relationship with SQL core

		
We are already down a path for a multipart standard

- with and with out schema
- SQL or RIF etc.


Please consider the following framework for the RDB2RDF standard.   
(where framework means a starting point for discussion.)


I suggest three elements for an implementation of the RDB2RDF  
standard wrt an implementation claiming to be standard compliant;
kind of like levels in SQL and many other systems.


1. Required
-- All implementations must provide this part in a consistent way

2. Optional
-- If an implementation includes these parts, the details are specified

3. Suggested
-- For implementations of these parts, the standard has some  
suggestions, but these are not binding on an implementation


// I see I just crossed emails with Richards email "the minimum we  
need"....


In this structure I see a basis for putting some of our issues to  
rest, and benefit from the concomitant concrete for forward progress.


A) Required

I suggest we can probably agree that there should be
- a standard mapping of SQL data types to RDF,
and
- a standard way of forming URIs

and, that this is required of all implementations.

B) Optional

An implementation may omit schema mapping and thus still be compliant.

Every system that does implement schema mapping will do so in a  
standard way.


C) Suggested

Example - how to deal with aggregation and/or other things that might  
be introduced by looking
at advanced features of SQL, RIF, SPARQL 2 vs. SPARQL


I introduce this third part as a kind of engineering solution for  
those parts of the system that
it is sort-of-obvious wrt what this means for engineers, but the  
formalization is either tough
or premature.


To elaborate using aggregation as an example:  The SQL side of the  
group has a clear idea, syntax and semantics,
of what it will mean to include aggregation in mapping rules  
expressed in a SQL syntax.

On the Semantic Web language side of the group (actually beyond),  
aggregation is something that is in flux.

So, "suggested", is a bucket where we can go on record for a direction
for functional parts of the standard where any of the following is true:

- Either due to limits on our own time, or lack of maturity on things  
out of our control, we can only sketch
an implementation example.

- We're all in agreement on something, but the formal semantics is  
tricky.  Where tricky means, either, it is beyond convenient
systems for defining semantics (e.g. beyond the scope of pure  
datalog.)  and/or until we implement some of these we really
don't know.  It would never the less be useful to get everyone on  
roughly the same page.


--------------

In regard to the current discussion of SQL levels, this structure may  
enable us to either choose, or define, different SQL
subsets.

e.g. A minimal SQL, say Basic Select From Where, a la SQL 1, is required
our choice of very fat SQL standard is suggested,
the place in between, where we were headed anyway, becomes optional.


Sincerely,

Dan

Received on Wednesday, 21 July 2010 20:41:09 UTC