W3C home > Mailing lists > Public > public-rdb2rdf-wg@w3.org > August 2011

Re: Proposal for ISSUE-65

From: Juan Sequeda <juanfederico@gmail.com>
Date: Thu, 25 Aug 2011 12:26:05 -0500
Message-Id: <8C1B3394-3879-455F-BADE-E91B1BE50EFA@gmail.com>
Cc: "public-rdb2rdf-wg@w3.org" <public-rdb2rdf-wg@w3.org>
To: Richard Cyganiak <richard@cyganiak.de>
Richard

IMO, I see it has a hack. But that is my opinion. Nevertheless, you have strong arguments. Thanks for the other use cases

On a side note, I believe that the DM must be usable. And it's going to be the solution for db users to generate RDF from their RDB in the quickest fashion.  They won't want to learn a mapping language, they want something automatic. DM + SQL views has the same expresivity as R2RML (well almost) At the end of the automatic process, it's a simple string substitution from automatic generated IRIs to well known IRIs. I've always been for having the many-to-many case. I believe that implementers will have the W3C DM standard and then and extension where many-to-many will be considered and the user can choose which tables/views to direct map. 

Having said that, I guess you agree with the proposal of generating two different IRIs for literal and reference properties which will allow to address ISSUE-65. 

Question is: how do we create those IRIs:

Literal: <Table#Lattr>
Reference: <Table#Rattr>

Is that enough? Are people happy with it?

Juan Sequeda
www.juansequeda.com

On Aug 25, 2011, at 7:28 AM, Richard Cyganiak <richard@cyganiak.de> wrote:

> On 23 Aug 2011, at 23:53, Juan Sequeda wrote:
>> HOWEVER, honestly, this in a way can be seen as a hack.
> 
> I wouldn't call it a hack. The two properties -- one based on a column, one based on a foreign key -- are two different things, so it's reasonable to model them as two different IRIs.
> 
> Quoting AWWW:
> [[
> Constraint: Assign distinct URIs to distinct resources.
> ]]
> http://www.w3.org/TR/webarch/#id-resources
> 
>> We would be
>> sticking the semantics inside the IRI which is really weird.
>> Nevertheless, it works.
> 
> No, we wouldn't be sticking the semantics inside the IRI. We would just give two different names to two different things.
> 
>> I would still like to hear more use-cases and motivations to why we
>> should generate a literal triple for foreign key columns. From Souri's
>> initial email, I have:
>> 
>> - Uniformity: For multi-column foreign keys we are already creating
>> literal triples, so why not keep it uniform and do it for unary-column
>> foreign keys.
> 
> The case for Uniformity is stronger than that: All columns, always, are mapped in the same predictable way; with the single exception of unary foreign keys.
> 
>> - Performances: introduces need for unnecessary join with the parent
>> table to retrieve the value of the foreign key column.
> 
> I agree that performance shouldn't be a big deal. It's easy enough to recognize the case where a join is used to retrieve the ID, and optimize the join away.
> 
> Other reasons against having the exception:
> 
> 1. See above -- different things should have different IRIs. A single-column FK is not the same as a column.
> 
> 2. Some DB schemas don't contain explicit FKs. In this case, one has to do joins using the DM like this:
> 
> SELECT ?name ?city WHERE {
>    ?person <PERSON#NAME> ?name .
>    ?person <PERSON#ADDRESS> ?aid .
>    ?address <ADDRESS#CITYNAME> ?city .
>    ?address <ADDRESS#ID> ?aid .
> }
> 
> And this, while requiring one extra triple pattern, is actually the direct translation of how one does joins in SQL: by requiring that a referenced PK value is the same. So why does the DM stop me from using that approach if an FK happens to be declared?
> 
> 3. Adding an FK to a DB schema doesn't break SQL queries, so it shouldn't break SPARQL queries either.
> 
> 4. You decided not to handle many-to-many relationships in the DM. The arguments were that the DM should be kept predictable and super-simple, and there shouldn't be any exceptions in the DM. The counter-argument that this reduces the usability of the DM was rejected as irrelevant – the DM isn't supposed to be usable, because it's not used directly. So why are you now insisting on an exception that makes the DM less predictable, only on a usability argument? And on a trivial usability argument – it just means adding more namespaces if one wants to do everything with namespaces?
> 
> Best,
> Richard
Received on Thursday, 25 August 2011 17:26:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:00:26 UTC