Re: ISSUE-3

Some ramblings from me just to make sure we are on the same page as far 
as understanding of "DDL" mapping goes and also to suggest an alternate 
term for "DDL" for the group's consideration:

Let us assume that there are two roles: 1) the Mapper (specifies the 
mapping from RDB to RDF) and 2) the Querier (designs the SPARQL query 
against the RDF view of RDB data).

To directly work with data in an already-created database, a Mapper has 
to first look at the data dictionary tables to find out the list of 
definitions for types, tables/views (including columns), and 
constraints. The SQL DDL statements (CREATE / ALTER  + TYPE / TABLE / 
CONSTRAINT) used for creating or modifying these items happened over 
time and are *not *available at the time of mapping. So, to determine 
the RDF (actually RDFS/OWL) classes and properties, the Mapper needs to 
look at the DB-vendor-specific data dictionary tables.

Presumably the Mapper knows about the data dictionary tables of the 
server database (i.e., where the data that s/he wants to map to RDF is 
located) or we could have an adapter for each DB-vendor to expose this 
info in a uniform way.

Based upon his/her understanding of the database, s/he specifies a 
mapping, using a RDB2RDF mapping language to be determined (D2RQ / SQL / 
... / something-very-simple / ...), of the DB objects to RDFS/OWL 
classes and properties. (If there is a simple mapping, one can write a 
DB-vendor-specific program to generate this mapping based upon some 
conventions, e.g., URIfy the table/view/col names.)

Leaving out the DB object references and other such details included in 
the mapping, one can then create an RDFS/OWL ontology (or schema: i.e., 
classes and properties).

The Querier sees the RDFS/OWL ontology/schema and designs his/her SPARQL 
query based upon that. (Translation of the SPARQL query, as I 
understand, is outside the scope of this WG.)

So, instead of calling it a mapping of SQL DDL statements (which the 
Mapper never sees directly), can we consider calling it a mapping of 
"RDB Data Definitions" (DB table/view/"named-"query/column/constraint 
definitions available from the data dictionary).

Thanks,
- Souri.

Juan Sequeda wrote:
>
>
> On Mon, Nov 23, 2009 at 10:45 PM, Ezzat, Ahmed <Ahmed.Ezzat@hp.com 
> <mailto:Ahmed.Ezzat@hp.com>> wrote:
>
>      
>
>      
>
>     Thanks Juan…
>
>      
>
>     Tomorrow we are continuing presentations.  It might be a good idea
>     to use email to exchange thoughts till we are done with the
>     presentations next week.
>
> Sounds good 
>
>     One observation that I have which is kind of border line is the
>     notion of R2RML supporting SQL DDL statements.  I think what we
>     mean is RDFS/OWL equivalence to SQL DDL statements.  In other
>     words, we are not creating SQL table but rather creating a class
>     that maps an existing SQL table to the RDF world, etc..
>
> Yes!  
>
>     If the above makes sense, one possibility is to have a table with
>     3 columns: SQL column (DDL statement): RDFS column (equivalence):
>     OWL column (equivalence).  In the SQL column you would have create
>     table, then in OWL the equivalent is to create a class, etc…
>
> That is exactly what I was thinking of. I was just trying to figure 
> out how to create a table in a wiki.  
>
>      
>
>     Ahmed
>
>      
>
>     *From:* Juan Sequeda [mailto:juanfederico@gmail.com
>     <mailto:juanfederico@gmail.com>]
>     *Sent:* Monday, November 23, 2009 19:22
>     *To:* Ezzat, Ahmed
>     *Cc:* Marcelo Arenas; Sören Auer; Michael Hausenblas; Harry
>     Halpin; RDB2RDF WG
>     *Subject:* Re: ISSUE-3
>
>      
>
>     I have now updated the list and added justification
>
>      
>
>     http://www.w3.org/2001/sw/rdb2rdf/wiki/Requirements/DDLCoverage
>
>      
>
>     I have based this on our previous work [1] and a technical report
>     of ours which is a survey of different approaches that take DDL
>     and convert it to an ontology [2].
>
>      
>
>     Looking forward to a discussion about this tomorrow.
>
>      
>
>     [1] http://www.springerlink.com/content/mv58805364k31734/
>
>     [2] ftp://ftp.cs.utexas.edu/pub/techreports/tr09-04.pdf
>
>      
>
>      
>
>     Juan Sequeda, Ph.D Student
>     Dept. of Computer Sciences
>     The University of Texas at Austin
>     www.juansequeda.com <http://www.juansequeda.com>
>     www.semanticwebaustin.org <http://www.semanticwebaustin.org>
>
>     On Mon, Nov 23, 2009 at 6:09 PM, Juan Sequeda
>     <juanfederico@gmail.com <mailto:juanfederico@gmail.com>> wrote:
>
>     I'm sure we will all have different points of views and opinions
>     on this.
>
>      
>
>     For example, the way we have done this (and we have shown this in
>     our dexa paper [1]): We have mapped the create table to classes,
>     except if the tables are binary relations, then they would map to
>     object properties. How do we automatically do this? Reading the
>     data dictionary or using describe operation. 
>
>      
>
>     I apologize for being a bit behind on this but I've been under the
>     weather. I'm in the processing of finishing the list and I will
>     take Ahmed's suggestion of writing justifications. We can then
>     discuss this tomorrow.
>
>      
>
>     [1] http://www.springerlink.com/content/mv58805364k31734/
>
>
>     Juan Sequeda, Ph.D Student
>     Dept. of Computer Sciences
>     The University of Texas at Austin
>     www.juansequeda.com <http://www.juansequeda.com>
>
>     www.semanticwebaustin.org <http://www.semanticwebaustin.org>
>
>
>
>     On Mon, Nov 23, 2009 at 11:48 AM, Ezzat, Ahmed <Ahmed.Ezzat@hp.com
>     <mailto:Ahmed.Ezzat@hp.com>> wrote:
>
>
>
>     Here is my 2 cents:
>
>     The format of the information Juan is collecting needs to be
>     modified.  I do not know if Juan read his email or not?  The list
>     he is collecting is the list of features that the mapping language
>     needs to support on the SQL side, i.e., ability to find out the PK
>     for a given relation R; this is doable using DESC (describe)
>     operation. I asked Juan to put usage scenarios for each item
>     suggested on his page.  For example, scenario where creating a
>     table is needed?  I did not want to go and edit the format of the
>     page, and instead asked Juan to do that. Then myself and others
>     can edit content.
>
>     There is another dimension to the mapping issue on the other side,
>     which is not part of what Juan is doing, i.e., RDFS or OWL usage
>     of the information you get from the RDBMS side.
>
>     Ahmed
>
>
>
>     -----Original Message-----
>     From: Marcelo Arenas [mailto:marcelo.arenas1@gmail.com
>     <mailto:marcelo.arenas1@gmail.com>]
>     Sent: Monday, November 23, 2009 07:56
>     To: Ezzat, Ahmed
>     Cc: Juan Sequeda; Sören Auer; Michael Hausenblas; Harry Halpin;
>     RDB2RDF WG
>     Subject: Re: ISSUE-3
>
>     Hi,
>
>     I am a bit confused about what we mean by "supporting a feature" of
>     DDL.  Assume that we are given a relation schema R(A, B) where A is
>     the primary key of R. The list says that primary keys should be
>     supported,  so should attribute A be a primary key of R(A, B) in the
>     RDF representation of this database? The problem with this is that
>     there is no way to enforce a key in RDF (RDFS). Are we just going to
>     describe in RDF that A is a primary key without enforcing it?
>     What about OWL? Are we planning to use owl:FunctionalProperty to
>     indicate that A is a primary key? Thanks!
>
>     All the best,
>
>     Marcelo
>
>     2009/11/18 Ezzat, Ahmed <Ahmed.Ezzat@hp.com
>     <mailto:Ahmed.Ezzat@hp.com>>
>     >
>     >
>     > Hi Juan,
>     >
>     > You can approach this problem from different angles. Request: on
>     the discussion page as an example:
>     >
>     > Tables item:
>     >
>     > Create Table
>     > Must be supported
>     >
>     >
>     > Let me suggest one of two formats: you can list for the Table
>     bullet: create table, delete table, alter table, describe table or
>     just list the ones you want to support?  I see as an example
>     Describe table is the obvious one as a must.
>     >
>     > In either scenario you want to adopt, please have next to any
>     DDL statement you want a justification, i.e., scenario(s)
>     justifying its use.
>     > Thanks,
>     >
>     > Ahmed
>     >
>     > Ahmed K. Ezzat, Ph.D.
>     > HP Fellow, Business Intelligence Software Division
>     > Hewlett-Packard Corporation
>     > 11000 Wolf Road, Bldg 42 Upper, MS 4502, Cupertino, CA 95014-0691
>     > Office:      Email: Ahmed.Ezzat@hp.com
>     <mailto:Ahmed.Ezzat@hp.com> Off: 408-447-6380  Fax: 1408796-5427 
>     Cell: 408-504-2603
>     > Personal: Email: AhmedEzzat@aol.com <mailto:AhmedEzzat@aol.com>
>     Tel: 408-253-5062  Fax:  408-253-6271
>     > From: Juan Sequeda [mailto:juanfederico@gmail.com
>     <mailto:juanfederico@gmail.com>]
>     > Sent: Wednesday, November 18, 2009 7:00 AM
>     > To: Sören Auer
>     > Cc: Michael Hausenblas; Harry Halpin; RDB2RDF WG; Ezzat, Ahmed
>     > Subject: Re: ISSUE-3
>     >
>     > On Tue, Nov 17, 2009 at 3:32 PM, Sören Auer
>     <auer@informatik.uni-leipzig.de
>     <mailto:auer@informatik.uni-leipzig.de>> wrote:
>     > Michael Hausenblas wrote:
>     > Though I see your point, DDL is the most general form of what we
>     are talking
>     > about, here, covering data model elements
>     >
>     > I actually think DDL is not a very general form, but rather a
>     very specific language for creating and manipulating relational
>     schema objects.
>     >
>     >
>     > IMO, we should stick to the specifics. Hence, using DDL should
>     be appropriate.
>     >
>     >
>     > (for sure DROP, ALTER is not in
>     > scope, but this is a no-brainer, I guess ;)
>     >
>     > Ok, but DDLs consist *only* of such statements, cf. e.g.:
>     >
>     >
>     http://dev.mysql.com/doc/refman/5.1/en/sql-syntax-data-definition.html
>     >
>     >
>     > What is missing from that list, that we should take in account?
>     >
>     > I'm fine with DDL and think we have used it in the discussion
>     throughout as
>     > such ...
>     >
>     > We can use the term DDL if everybody in the group got used to
>     it, but from a conceptual point of view I think this is wrong and
>     in order to avoid confusion with the outside world we should
>     rather talk about /data model elements/ or /schema objects/.
>     >
>     > I think we can combine the two in this list that we are going to
>     make. But we should also be on the same page. I see that you have
>     Foreign Key, Integrity Constraints and Referential Integrity
>     separate. Why? Aren't referential constraints a subset of
>     integrity constraints. And a foreign key is a referential
>     constraints. Those shouldn't be separate, but express them as
>     subclasses.
>     >
>     > Sören
>     >
>     >
>
>      
>
>      
>
>