RE: ISSUE-3

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
[X]
From: Juan Sequeda [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