Re: primary key that's already a uri?

On 11/20/2010 07:40 PM, Juan Sequeda wrote:
>
>
>
> On Sat, Nov 20, 2010 at 9:35 PM, Drew Perttula <drewp@bigasterisk.com
> <mailto:drewp@bigasterisk.com>> wrote:
>     little unclear to say you're not using the table content. The PK
>     values are in the table. For all you know, they could be strings,
>     and they could even be strings starting with 'http://'. I realize
>     that plain ints are the most popular PK type, but I suspect that
>     RDF-inclined people use URIs for their PK more often than the
>     general population :)
>
>
> You mean that in the case of a relational database, the primary key
> values are of the form
>
> "http://.... "
>
> We are considering "legacy" relational databases in a way.. not
> relational databases that have been made to store RDF.
>

I kind of blurred together the two points I wanted to make. I think 
we're all clear about the notion of using URIs that are already in the 
table, which does indeed imply a RDB design that was thinking about RDF.

But when it comes to arbitrary source databases, I hope rdf2rdb is 
prepared for primary keys like "f6f863ac-560d-4f28-aaad-131803c73aea" or 
"105.22#006" or "date(2010-11-20)". If there is to be no configuration 
system in this level of the spec, it seems that you have to pick one of 
these options:
1) fail to support some databases
2) always use the RowID
3) stringify any PK value and escape it to be a safe URI component

The spec seems to be leaning towards #3, though it's not clear about how 
to handle anything besides an int. #2 is a nice, simple, no-config 
choice, but it has other disadvantages (is RowID even available? is it 
ok for row nodes to potentially change value after an update to an 
unrelated row?).

Received on Sunday, 21 November 2010 04:03:42 UTC