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
www.semanticwebaustin.org


On Mon, Nov 23, 2009 at 6:09 PM, Juan Sequeda <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
> www.semanticwebaustin.org
>
>
>
> On Mon, Nov 23, 2009 at 11:48 AM, Ezzat, Ahmed <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]
>> 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>
>> >
>> >
>> > 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 Off: 408-447-6380  Fax:
>> 1408796-5427  Cell: 408-504-2603
>> > Personal: Email: AhmedEzzat@aol.com Tel: 408-253-5062  Fax:
>> 408-253-6271
>> > 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> 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
>> >
>> >
>>
>
>