Re: primary key that's already a uri?

On Sat, Nov 20, 2010 at 10:03 PM, Drew Perttula <drewp@bigasterisk.com>wrote:

> 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,


Yes

> though it's not clear about how to handle anything besides an int.


Thanks for bringing this up.

> #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?).
>

Exactly. RowID may not always be available and AFAIK, row ids can
potentially change. Therefore this is not a safe option.

Received on Sunday, 21 November 2010 04:06:22 UTC