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