Re: Proposal for ISSUE-65

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 12:29:27 UTC