Re: Detailed comments on new default mapping draft

Eric,

Below are some replies to your comments on my comments on the  
directGraph/alt document.

On 4 Nov 2010, at 13:44, Eric Prud'hommeaux wrote:
> I prefer to keep stem URI distinct from the relative URI, at least for
> FPWD. base, per 2396 <http://tools.ietf.org/html/rfc2396#section-1.4>
> has a specific behavoir, for example, a relative URI <People/ID.7#_>
> resolved against a base URI of <http://foo.example/DB> yields
> <http://foo.example/People/ID.7#_>. If we remedy that with a leading
> slash, </People/ID.7#_>, we get something resolved against the root.

Note that the stem approach assumes that the stem IRI ends in a slash  
and does not contain a hash character, otherwise you get garbage table  
names or cannot HTTP-resolve the IRIs. This should be stated  
explicitly in the document when stem IRI is introduced.

And once you require that the stem IRI ends in a slash, then it is  
equivalent to the resolution of relative IRIs.

Hence I stand by what I said: The requirement for ending slash and no  
fragment should be made explicit, and stem IRI changed to base IRI.  
The less wheels we re-invent ... At least add an issue box noting the  
objection against the introduction of the stem IRI concept.

>>> You write foreign keys as if they reference another *key*. I  
>>> believe that
>>> doesn't reflect SQL. Foreign keys reference other *columns*.  
>>> That's the
>>> mental model that a reader is going to have in their head, and  
>>> that's how it
>>> should be presented in the spec.
>
> Actually, I disagree; foreign keys specifically reference candidate
> keys in other tables.

It is true that the columns referenced by a foreign key must  
constitute a candidate key. Nevertheless, the foreign key references  
*columns* and not a candidate or real key. The formalism in the SQL  
spec, the actual syntax of the SQL DDL, and the mental model that SQL  
users have, all have references to *columns*.

I see this is fixed in the /alt version by replacing “→  
Department.Key1” with “→ Department(name,city)”. Great!

> [[
> The columns in the referencing table must be the primary key or other
> candidate key in the referenced table.
> ]] — http://en.wikipedia.org/wiki/Foreign_key ¶1

The way this is written exactly confirms what I said above.

>>> The use of "_" as a separator between the column/value pairs in
>>> multi-column PK row URIs is a bad idea, because the underscore  
>>> character is
>>> ubiquitous in table and column names. An obvious replacement would  
>>> be ";".
>
> The prob here is that we don't want to step on either a valid fragment
> identifier (for e.g. turtle) or xml local name (for RDF/XML).

Both “;” and “,” are legal in fragment identifiers.

Trying to stay within XML local names is a lost cause. SQL column  
names can contain all sorts of characters that are not allowed in XML  
local names, and URLencoding (like any other encoding scheme I'm aware  
of) relies on an escape character that isn't allowed in XML local  
names either.

Note that all RDF/XML serializers are able to create custom prefixes  
as necessary, which is ugly, but means that there isn't an actual  
problem because any direct graph can be serialized in RDF/XML just fine.

> I've left the "_" until we have a new idea.

The idea is to use “;” or “,” and forget about XML local names.  
That'll have to do.

> Note that url-encoding the column names and lexical values protects us
> from seing the "_"s in e.g. f_name Bob_Smith.

No it doesn't. The URL-encoded form of “_” is still “_”. You  
cannot use the underscore as a separator if you use URLencoding.

(I note that /alt now uses “,”, which is nice, but doesn't do the  
necessary URLencoding to deal with special characters.)

Best,
Richard

Received on Sunday, 7 November 2010 03:51:41 UTC