On Thu, 12 Nov 2009, Ezzat, Ahmed wrote:

> The current charter has some ambiguity and the purpose of this discussion is to come up with a more precise statement that reflects what the team thinks but also taking into consideration time constraints.

Note that the charter does specify only the following as MUST [1]:

"The mapping language MUST define the mapping of relational data and 
relational schemas to RDF and OWL"

"The mapping language MUST define the set of relational algebra to be 
supported in the first release."

"The mapping language MUST allow for a mechanism to create identifiers for 
database entities"

What we need to clarify is exactly the nature of the first must, but I 
concur with Ahmed and the general consensus that we should be "read" only 
and that mapping should be done so that it allows a database to be directly 
exported into RDF, not in response to a specific mapping of a 
particular SPARQL query into SQL. One can imagine how work in doing so 
could be built from the work of a general semantic mapping from relational 
data to RDF that the syntax of R2RML will embody, but this is not within 
the scope of the R2RML syntax.

With particular issues such as "The mapping language SHOULD be able to 
support vendor specific SQL data types", this is precisely what needs to 
be hashed out in the WG. It seems there should be some kind of general 
extensibility mechanism for vendor-specific data-types and functions. I 
would like to see links to such work if it exists.


> The first issue was to clarify that mapping SPARQL to SQL is not part of what we are talking about, i.e., removing relational algebra mapping from the charter.  From the dialogue we are having I am reading that the answer is NO to SPARQL/SQL mapping.
> Now, the language is limited to mapping data types and there is desire and interest to explore a means to support vendor specific data types; this would be desirable.
> As an example, in traditional, 30-years old RPC, you define structure (object) in an IDL file and the stub compiler generates the functions that marshal / un-marshal this structures, and also generate stub and skeleton routines which in turn calls these marshal/un-marshal functions.  Good RPC stub compilers would allow you as a user to define the marshalling/un-marshalling functions for a given structure/object your self, but the compiler provides the framework to support integrating your marshalling/un-marshalling functions with the generated stub/skeleton routines.  This is meant as an example to possibly address supporting vendor specific data types.
> It is the purpose of this initial period, few months after the presentations are complete, to pin down what is included and what is not.   In other words, it is the goal of this group to answer the scope of your suggestions below about XML data type, etc.
> Ahmed
> -----Original Message-----
> From: Richard Cyganiak []
> Sent: Thursday, November 12, 2009 2:23 PM
> To: Ezzat, Ahmed
> Subject: Re: ISSUE-3
> On 12 Nov 2009, at 16:26, Ezzat, Ahmed wrote:
>> Given that the goal of the WG is to create a mapping from RDB
>> Schemas to RDF/OWL classes only.  This require us to be able to read
>> the schema but not necessarily to modify it.
> +1 for scoping this WG to read-only access.
>> This leads me: R2RML mapping language MUST support as complete as
>> possible all SQL data and object types and any exceptions will be
>> identified as soon as possible after the WG launch.
> +1 for supporting as many SQL data types as possible. But what's the
> target for "all" data types? Does this include, say, the XML type of
> SQL:2003? What about types that are not in the standard but commonly
> used in popular RDBMS? I don't even know if SQL:2008 adds any new
> datatypes...
> Are you saying that user-defined object types should be supported in
> the language? I'm opposed to that idea. My impression is that this is
> implemented very inconsistently across different RDBMS, if at all; it
> adds a lot of complexity to the already big overall task of the WG;
> I'm not aware of any existing RDB2RDF system that handles them from
> which we could learn, so we move from standardisation into research
> territory; I would have no idea how methods with arguments should be
> handled; and only a small minority of RDBMS users seem to be using
> user-defined object types. So from my POV the case for including them
> is weak; certainly not good enough for a MUST at this stage.
> Best,
> Richard
>> All, does the above capture what the goal is.
>> Feel free to edit/agree/disagree, etc..
>> Regards,
>> Ahmed
>> -----Original Message-----
>> From: ashok malhotra []
>> Sent: Thursday, November 12, 2009 05:34
>> To: Ezzat, Ahmed
>> Subject: Re: ISSUE-3
>> Hello Ahmed:
>> I envision that the work of the WG is one-way: from RDB to RDF/OWL.
>> So, to answer your question, I do not envision creating SQL tables in
>> the RDBMS from SPARQL application using R2RML.
>> All the best, Ashok
>> Ezzat, Ahmed wrote:
>>> Hi Ashok,
>>> Thanks for the follow up. I agree with your clarification regarding
>>> the mapping SPARQL to SQL is out of scope; having discussion about
>>> it if the team want to pursue is fine - I am trying to separate
>>> what we discuss, with time constraints, from what we will commit to
>>> deliver which we need to pin down early 2010.
>>> I liked the D2R presentation scope in the mapping area; is
>>> reasonable.
>>> Regarding DDL statements mapping support: do you envision creating
>>> SQL tables in the RDBMS from SPARQL application using R2RML or do
>>> you envision the ability through the R2RML to read the different
>>> schema objects definitions in the RDBMS from a SPARQL application?
>>> I agree that the latter is a must and would be interested in
>>> getting your input as well as others on the first.
>>> Regards,
>>> Ahmed
>>> -----Original Message-----
>>> From: [
>>> ] On Behalf Of ashok malhotra
>>> Sent: Wednesday, November 11, 2009 13:58
>>> To: RDB2RDF WG
>>> Subject: ISSUE-3
>>> Since the goal of the WG is to create a mapping from RDB Schemas to
>>> RDF/OWL classes, perhaps
>>> we should rephrase the bullet point in the requirements as
>>>    * The mapping language MUST define the set of SQL DDL
>>>      to be supported in the first release. The set to be supported
>>>      SHOULD be as complete as possible and be defined as soon as
>>>      possible after the WG official launch.
>>> This will let us exclude Table Types if we wish.
>>> I apologize that the original bullet was interpreted to mean that the
>>> the WG should define
>>> a mapping from SPARQL to SQL.  That was not the intention.  In my
>>> view,
>>> the mapping of
>>> SPARQL to SQL should be left open as a technology on which various
>>> implementations
>>> can compete. .

Received on Monday, 16 November 2009 18:23:33 UTC