Re: primary key that's already a uri?

Drew, all --


On Nov 19, 2010, at 02:50 AM, Drew Perttula wrote:

> http://www.w3.org/TR/2010/WD-rdb-direct-mapping-20101118/#row_iri
> 
> "The IRI that identifies a row is created by  ..."
> 
> Please consider the cases where people do have the freedom to use a complete URI as the primary key in their RDB. When I can build my RDB with RDF mapping in mind, that is the most natural thing to do. I would like to see an alternate row node scheme that simply takes the PK string and treats it as the row node.

If nothing else, this option should not be part of the *Direct 
Mapping*.  The Direct Mapping *cannot* take into account *any* of
the table content.

I don't think that your described option will really be viable, for
a number of reasons, but if someone wants to try to implement it, 
that should be a part of the later R2RML process (and document).


> This use case will come up especially often when people are designing hybrid systems that store what they can in RDF, but keep some data as RDB rows for reasons of performance, space economy, existing tool support, etc.
> 
> 
> 
> I also wonder if users will have tables with a boring PK (e.g. an int) but with another column that contains URIs. Generating <People/ID=8#_> <People#URI> "http://foaf.org/person/Bob" is silly; we should be able to indicate that the 'URI' column *is* the row node, even if it's not the PK. This would also be a general solution for people who want other URI forms for their rows: they could always augment their tables with a hand- or auto-generated URI column that's used instead of your built-in algorithm.


That's fine ... but *again*, is not part of Direct Mapping.

Optimizations, refinements, special cases ...  All of these belong
in the *next stage* of things, which we've been treating as the
R2RML document.  

Direct Mapping is explicitly and exactly that -- *DIRECT* mapping 
of 

1. RowIDs (whether taken from DBMS RowIDs, PKs, composite keys  
   constructed by concatenating column, or other) to Entities, 
2. Columns to Attributes, 
3. Values to Values,
4. Tables to Classes, 
5. PK/FK relations to Relationships

Yes -- that's really all it is -- and really what it MUST be.

(Yes, this hopefully shows that RDB is a special case of EAV+CR,
just as RDF is, albeit with slightly different rules in each case.)

Both RowIDs and Columns must be explicitly tied to their containing 
TableID, as there will always be multiple RowID=1, and there may
as well always be multiple ColumnName='ID' ... and likewise, TableID
must be explicitly tied to containing Schema/Owner, and Catalog, and
ultimately DBMS-Instance, but this should be obvious to anyone 
spending more than a few minutes on the question, and exactly how 
the ties are made may be left as an implementation detail.

Regards,

Ted



--
A: Yes.                      http://www.guckes.net/faq/attribution.html
| Q: Are you sure?
| | A: Because it reverses the logical flow of conversation.
| | | Q: Why is top posting frowned upon?

Ted Thibodeau, Jr.           //               voice +1-781-273-0900 x32
Evangelism & Support         //        mailto:tthibodeau@openlinksw.com
                             //              http://twitter.com/TallTed
OpenLink Software, Inc.      //              http://www.openlinksw.com/
        10 Burlington Mall Road, Suite 265, Burlington MA 01803
                                 http://www.openlinksw.com/weblogs/uda/
OpenLink Blogs              http://www.openlinksw.com/weblogs/virtuoso/
                               http://www.openlinksw.com/blog/~kidehen/
    Universal Data Access and Virtual Database Technology Providers

Received on Friday, 19 November 2010 16:51:15 UTC