Re: primary key that's already a uri?

I guess we should alter the following text:

"The Direct Mapping is intended to provide a default behavior for R2RML: RDB
to RDF Mapping Language when no specific configurations have been given."


Juan Sequeda
+1-575-SEQ-UEDA
www.juansequeda.com


On Fri, Nov 19, 2010 at 10:00 AM, Ted Thibodeau Jr <
tthibodeau@openlinksw.com> wrote:

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