- From: Juan Sequeda <juanfederico@gmail.com>
- Date: Sat, 20 Nov 2010 22:05:29 -0600
- To: Drew Perttula <drewp@bigasterisk.com>
- Cc: public-rdb2rdf-comments@w3.org
- Message-ID: <AANLkTikRVJkdNaHcLJMi6KBNgDRi6pK7UL_xvGkPinhO@mail.gmail.com>
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