]>
A Direct Mapping of Relational Data to RDF Internal Working Draft Editor's Draft 9 November 2010 $Id: Overview.xml,v 1.60 2011/03/03 18:26:31 eric Exp $ http://www.w3.org/2001/sw/rdb2rdf/directGraph/ http://www.w3.org/2001/sw/rdb2rdf/directGraph/ Eric Prud'hommeaux W3C eric@w3.org

The need to share data with collaborators motivates custodians and users of relational databases (RDB) to expose relational data on the Web of Data. This document defines a very simple direct mapping from relational data to RDF. This definition provides extension points for refinements within and outside of this document.

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This is a Editors' Working Draft.

The documents produced by this Working Group are:

  • RDB2RDF Mapping Language (R2RML) Specification
  • RDB2RDF Mapping Language (R2RML) Conformance Tests

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

 en

Last Modified: $Id: Overview.xml,v 1.60 2011/03/03 18:26:31 eric Exp $

Introduction

Relational databases proliferate both because of their efficiency and their precise definitions, allowing for tools like SQL to manipulate and examine the contents predictably and efficiently. Resource Description Framework (RDF) is a data format based on a web-scalable architecture for identification and interpretation of terms. This document defines a mapping from relational representation to an RDF representation.

Strategies for mapping relational data to RDF abound. The direct mapping defines a simple transformation, providing a basis for defining and comparing more intricate transformations. This document includes an informal and a formal description of the transformation.

The Direct Mapping is intended to provide a default behavior for R2RML: RDB to RDF Mapping Language. It can be also used to materialize RDF graphs or define virtual graphs, which can be queried by SPARQL or traversed by an RDF graph API.

Direct Mapping Description (Informative)

The direct mapping defines an RDF Graph represention of the data in any relational database. The direct mapping takes as input a relational database (data and schema) generates an RDF graph is called the direct graph . This graph is composed of relative IRIs and may be resolved against base URI per Foreign keys in relational databases establish a named reference from any row in a table to exactly one row in a (potentially different) table. The direct graph conveys these references, as well as each value in the rows.

Direct Mapping Example

The concepts in direct mapping can be introduced with an example RDF graph produced by a relational database. Following is SQL (DDL) to create a simple example with two tables with single-column primary keys and one foreign key reference between them:

CREATE TABLE Addresses (ID INT, city CHAR(10), state CHAR(2), PRIMARY KEY(ID)) CREATE TABLE People (ID INT, fname CHAR(10), addr INT, PRIMARY KEY(ID), FOREIGN KEY(addr) REFERENCES Addresses(ID)) INSERT INTO Addresses (ID, city, state) VALUES (18, "Cambridge", "MA") INSERT INTO People (ID, fname, addr) VALUES (7, "Bob", 18) INSERT INTO People (ID, fname, addr) VALUES (8, "Sue", NULL)

HTML tables will be used in this document to convey SQL tables. The primary key of these tables will be marked with the pk class to convey an SQL primary key such as ID in CREATE TABLE Addresses (ID INT, ... PRIMARY KEY(ID)). Foreign keys will be illustrated with a notation like "→ Address(ID)" to convey an SQL foreign key such as CREATE TABLE People (... addr INT, FOREIGN KEY(addr) REFERENCES Addresses(ID)).

People
PK → Address(ID)
ID fname addr
7 Bob 18
8 Sue NULL
Addresses
PK
ID city state
18 Cambridge MA

Given a base of http://foo.example/DB/ the direct mapping of this database produces a direct graph:

@base <http://foo.example/DB/> @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . <People/ID=7> <People#ID> 7 . <People/ID=7> <People#fname> "Bob" . <People/ID=7> <People#addr> <Addresses/ID=18> . <People/ID=8> <People#ID> 8 . <People/ID=8> <People#fname> "Sue" . <Addresses/ID=18> <Addresses#ID> 18 . <Addresses/ID=18> <Addresses#city> "Cambridge" . <Addresses/ID=18> <Addresses#state> "MA" .

In this expression, each row, e.g. (7, "Bob", 18), produces a set of triples with a common subject. The subject is an IRI formed from the concatenation of the base, table name (People), primary key column name (ID) and primary key value (7). The predicate for each column is an IRI formed from the concatenation of the base, table name and the column name. The values are either RDF literals formed from the lexical form of the column value, or, in the case of foreign keys, row identifiers (<http://foo.example/DB/Addresses/ID=18>). Note that these reference row identifiers must coincide with the subject used for the triples generated from the referenced row.

Mapping Rules

Each row in the database produces a set of RDF triples with a subject, predicate, and object composed as follows:

shared subject — The single, unique row identifier may be a an IRI or a Blank Node. If the table has no primary key, this subject is an RDF Blank Node. Otherwise, the subject is a row IRI (described below) composed of the base, table name and column name and value for each column in the primary key. reference triples — Each non-NULL foreign key generates a triple with the shared subject and a: predicate — a property IRI (described below) composed of the base, table name and column name for each column in the foreign key. object — the row identifier created for the referenced row. literal triples — Each non-NULL column value generates a triple with a: predicate — a property IRI composed of the base, table name and column name. object — an RDF Literal with an XML Schema datatype corresponding to the SQL datatype of that value. Per XML Datatypes for SQL Datatypes, string datatypes are expressed as an RDF plain literal. Single-column foreign key — Columns which are also the sole column in a foreign key do not generate a literal triple. (Otherwise, there would be two values for that predicate, which may be single-valued/functional.)

The direct mapping generates relative IRIs; the examples in this document are resolved against a base IRI of http://foo.example/DB/. There are two kinds of IRI composed for the direct mapping: property IRI and row IRI:

property IRI — IRIs in the predicate position are composed by concatenating: the url-encoded (per WSDL urlEncoded ) table name '#' the url-encoded column names, separated by a ',' For example, a table called People with a foreign key with the column names fname, lname would produce the IRI <http://foo.example/DB/People#fname,lname> row IRI — IRIs in the subject or object position include row values, and are composed by concatenating: the url-encoded table name '/' the pairs of url-encoded column name '=' url-encoded column value, separated by a ','. The column value is the lexical value per SQL 2008 Foundation . For example, a row in a table called People with a primary key with the column names fname, lname with values Bob Smith would produce the IRI <http://foo.example/DB/People/fname=Bob,lname=Smith> Multi-column Keys

More complex schemas include compound and composite primary keys. In this example, the columns deptName and deptCity in the People table reference name and city in the Department table:

People
PK → Department(name, city)
ID fname addr deptName deptCity
7 Bob 18 accounting Cambridge
8 Sue NULL NULL NULL
Addresses
PK
ID city state
18 Cambridge MA
Department
PK Unique key
ID name city manager
23 accounting Cambridge 8

Per the People tables's compound foreign key to Department:

The row in People with deptName="accounting" and deptCity="Cambridge" references a row in Department with a primary key of ID=23. The predicate for this key is formed from "deptName,deptCity", reflecting the order of the column names in the foreign key. The referent identifier (object of the above predicate) is formed from the base and "ID=23". @base <http://foo.example/DB/> @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . <People/ID=7> <People#ID> 7 . <People/ID=7> <People#fname> "Bob" . <People/ID=7> <People#addr> <Addresses/ID=18> . <People/ID=7> <People#deptName> "accounting" . <People/ID=7> <People#deptCity> "Cambridge" . <People/ID=7> <People#deptName,deptCity> <Department/ID=23> . <People/ID=8> <People#ID> 8 . <People/ID=8> <People#fname> "Sue" . <Addresses/ID=18> <Addresses#ID> 18 . <Addresses/ID=18> <Addresses#city> "Cambridge" . <Addresses/ID=18> <Addresses#state> "MA" . <Department/ID=23> <Department#ID> 23 . <Department/ID=23> <Department#name> "accounting" . <Department/ID=23> <Department#city> "Cambridge" . <Department/ID=23> <Department#manager> <People#ID=8> .

Primary keys may also be composite. If the primary key for Department were (name, city), the identifier for that first (only) row would be <http://foo.example/DB/Department/name.Accounting,city.Cambridge>.

Empty (Non-existent) Primary Keys

Even if there is no primary key, rows generate a set of triples with a shared subject, but that subject is a blank node:

Tweets
→ People(ID)
tweeter when text
7 2010-08-30T01:33 I really like lolcats.
7 2010-08-30T09:01 I take it back.
@base <http://foo.example/DB/> @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . _:a <Tweets#tweeter> <People/ID=7> . _:a <Tweets#when> "2010-08-30T01:33"^^xsd:dateTime . _:a <Tweets#text> "I really like lolcats." . _:b <Tweets#tweeter> <People/ID=7> . _:b <Tweets#when> "2010-08-30T09:01"^^xsd:dateTime . _:b <Tweets#text> "I take it back." .

It is not possible to dereference blank nodes ("_:a" and "_:b" above). Queries or updates may be made to these nodes via SPARQL queries.

Referencing Tables with Empty Primary Keys

Rows in tables with no primary key may still be refrenced by foreign keys. (Relational theory tells us that these rows must be unique as foreign keys reference candidate keys and candidate keys are unique across all the rows in a table.) References to rows in tables with no primary key are expressed as RDF triples with blank nodes for objects, where that blank node is the same node used for the subject in the referenced row.

This example includes several foreign keys with mutual column names. For clarity; here is the DDL to clarify these keys:

CREATE TABLE Projects (lead INT, FOREIGN KEY (lead) REFERENCES People(ID), name VARCHAR(50), UNIQUE (lead, name), deptName VARCHAR(50), deptCity VARCHAR(50), UNIQUE (name, deptName, deptCity), FOREIGN KEY (deptName, deptCity) REFERENCES Department(name, city)); CREATE TABLE TaskAssignments (worker INT, FOREIGN KEY (worker) REFERENCES People(ID), project VARCHAR(50), PRIMARY KEY (worker, project), deptName VARCHAR(50), deptCity VARCHAR(50), FOREIGN KEY (worker) REFERENCES People(ID), FOREIGN KEY (project, deptName, deptCity) REFERENCES Projects(name, deptName, deptCity), FOREIGN KEY (deptName, deptCity) REFERENCES Department(name, city));
Projects
Unique key
Unique key
→ People(ID) → Department(name, city)
lead name deptName deptCity
8 pencil survey accounting Cambridge
8 eraser survey accounting Cambridge
TaskAssignments
PK
→ Projects(name, deptName, deptCity)
→ People(ID) → Departments(name, city)
worker project deptName deptCity
7 pencil survey accounting Cambridge
@base <http://foo.example/DB/> @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . @prefix pencil: <http://foo.example/DB/TaskAssignment/worker=7_project=pencil+survey#> _:c <Projects#lead> <People/ID=8> . _:c <Projects#name> "pencil survey" . _:c <Projects#deptName> "accounting" . _:c <Projects#deptCity> "Cambridge" . _:c <Projects#deptName,deptCity> <Department/ID=23> . _:d <Projects#lead> <People/ID=8> . _:d <Projects#name> "eraser survey" . _:d <Projects#deptName> "accounting" . _:d <Projects#deptCity> "Cambridge" . _:d <Projects#deptName,deptCity> <Department/ID=23> . pencil:_ <TaskAssignments#worker> <People/ID=7> . pencil:_ <TaskAssignments#project> "pencil survey" . pencil:_ <TaskAssignments#deptName> "accounting" . pencil:_ <TaskAssignments#deptCity> "Cambridge" . pencil:_ <TaskAssignments#deptName,deptCity> <Department/ID=23> . pencil:_ <TaskAssignments#project,deptName,deptCity> _:c .

The absence of a primary key forces the generation of blank nodes, but does not change the structure of the direct graph or names of the predicates in that graph.

The direct graph is arguably more faithful to the conceptual model if it reflects e.g. a person with multiple addresses (some many-to-many Person2Address table) as repeated properties. It is difficult to detect which tables with exactly two foreign keys and no other attributes are many-to-many. As a counter example, a Wedding table may have exactly two spouses but it's still not a many-to-many relation in most places. Notation for this Document Notation for Types

A a type

A? an optional argument of type A

A ⊔ B disjoint union of A and B

( A, B ) tuple (Cartesian product) of types A and B

[ A ] list of elements of type A

{ A } set of elements of type A

{ A→B } finite map of elements of type A to elements of type B

 Notation for Injectors

a an instance of an A

( a1, b1 ) a tuple with elements a1 and b1

[ a1, a2 ] list with elements a1 and a2

{ a1, a2 } set with elements a1 and a2

{ a1→b1, a2→b2 } map with elements with key a1 mapped to b1 and key a2 mapped to b2

 Accessor Functions

AB[a] in a map of A to B, the instance of B for a given A

 Data Model Definition (Normative)

The buttons below can be used to show or hide the available syntaxes.

Reference Database Model Definition (Normative)

There are many models for databases in SQL literature; because the Direct Mapping does not rely on column position, we use a model which assumes a 1:1 correspondance between attribute (column name) and value, i.e. a map. Starting with a traditional model of a relational database we define a Relation (a table) which has a name, a Header, Body and primary/foreign key details. The Body contains maps from attribute names to values and the Header provides the datatypes to interpret those values.

Relational Definition Database { TableName → Table } A relational database is a mapping of relation name to relation. case class Database( m:Map[TableName, Table] ) Table ( Header, [CandidateKey], CandidateKey?, ForeignKeys, Body ) where the 2nd slot is a list of candidate keys that apply to the table, and the 3rd is an optional candidate key use as the primary key A relation has a header, a list of candidate keys, a primary key (of type candidate key), a mapping of foreign keys, and a body. case class Table (header:Header, body:Body, candidates:List[CandidateKey], pk:Option[CandidateKey], fks:ForeignKeys) Header { AttrName → SQLDatatype } A header is a mapping from attribute name to SQL datatype. case class Header (types:Map[AttrName, SQLDatatype]) CandidateKey [ AttrName ] A candidate key is a list of attribute names. type CandidateKey = List[AttrName] ForeignKeys { [AttrName] → ( Table, [AttrName] ) } Foreign keys is a mapping from a list of attribute names to a relation and a list of attribute names. type ForeignKeys = Map[AttrName, Target] case class Target (rel:TableName, attrs:CandidateKey) SQLDatatype { INT | FLOAT | DATE | TIME | TIMESTAMP | CHAR | VARCHAR | STRING } An SQL datatype is an INT, FLOAT, DATE, TIME, TIMESTAMP, CHAR, VARCHAR or STRING as defined in the SQL specification . sealed abstract class SQLDatatype case class SQLInt () extends SQLDatatype case class SQLFloat () extends SQLDatatype … case class SQLString () extends SQLDatatype Body [ Tuple ] A body is a list of (potentially duplicate) tuples. type Body = List[Tuple] Tuple { AttrName → CellValue } A tuple is a mapping from attribute name to cell value. case class Tuple (m:Map[AttrName, CellValue]) CellValue value | Null A cell value is a scalar value in some SQL datatype, or SQL NULL. abstract class CellValue case class LexicalValue (s:String) extends CellValue case class ␀ () extends CellValue RDF Model Definition (Non-normative)

Per RDF Concepts and Abstract Syntax, an RDF graph is a set of triples of a subject, predicate and object. The subject may be an IRI or a blank node, the predicate must be an IRI and the object may be an IRI, blank node, or an RDF literal.

This section recapitulates for convience the formal definition of RDF.

RDF Definition Graph { Triple } An RDF graph is a set of RDF triples. type RDFGraph = Set[Triple] Triple ( Subject, Predicate, Object ) An RDF triple contains a subject, predicate and object. case class Triple (s:Subject, p:IRI, o:Object) Subject IRI | BlankNode A subject is an IRI or a blank node. sealed abstract class Node // factor out IRIs and BNodes case class NodeIRI(i:IRI) extends Node case class NodeBNode(b:BNode) extends Node sealed abstract class Subject case class SubjectNode(n:Node) extends Subject Predicate IRI A predicate is an IRI. sealed abstract class Predicate case class PredicateIRI(i:IRI) extends Predicate Object IRI | BlankNode | Literal An object is an IRI, a blank node, or a literal. sealed abstract class Object case class ObjectNode(n:Node) extends Object case class ObjectLiteral (n:Literal) extends Object IRI RDF URI-reference as subsequently restricted by SPARQL An IRI is an RDF URI reference as subsequently restricted by SPARQL. case class IRI(iri:String) BlankNode RDF blank node A blank node is an arbitrary term used only to establish graph connectivity. case class BNode(label:String) Literal PlainLiteral | TypedLiteral A literal is either a plain literal or a typed literal. sealed abstract class Literal case class LiteralTyped(i:TypedLiteral) extends Literal case class LiteralPlain(b:PlainLiteral) extends Literal PlainLiteral (lexicalForm) | (lexicalForm, langageTag). A plain literal has a lexical form and an optional language tag. case class PlainLiteral(value:String, langtag:Option[String]) TypedLiteral (lexicalForm, IRI). An typed literal has a lexical form and a datatype IRI. case class TypedLiteral(value:String, datatype:IRI) Direct Mapping Definition (Normative)

The direct mapping is a formula for creating an RDF graph from the tuples in a relation. A base IRI defines a web space for the labels in this graph; all labels are generated by appending to the base. The functions scalar and reference extract the non-Null scalar and reference attributes respectively.

references(T, R) { K ∣ ∄(T(A) = Null ∣ A ∈ K) ∧ K ≠ R.PrimaryKey ∣ K ∈ R.ForeignKeys } The references function returns the attributes in any of a relation's foreign keys. def references (t:Tuple, r:Table):Set[List[AttrName]] = { val allFKs:Set[List[AttrName]] = r.fks.keySet val nulllist:Set[AttrName] = t.nullAttributes(r.header) val nullFKs:Set[List[AttrName]] = allFKs.flatMap(a => { val int:Set[AttrName] = nulllist & a.toSet if (int.toList.length == 0) None else List(a) }) /** Check to see if r's primary key is a hierarchical key. * http://www.w3.org/2001/sw/rdb2rdf/directGraph/#rule3 */ if (r.pk.isDefined && r.fks.contains(r.pk.get)) r.fks.keySet -- nullFKs - r.fks(r.pk.get).attrs else r.fks.keySet -- nullFKs } scalars(T) { A in T ∣ A ≠ Null ∧ [A] ∉ references(T) } The scalars function returns the attributes which are NOT in any of a relation's foreign keys. def scalars (t:Tuple, r:Table):Set[AttrName] = { val allAttrs:Set[AttrName] = r.header.keySet val nulllist:Set[AttrName] = t.nullAttributes(r.header) val refs = references(t, r) filter (a => a.length == 1) map (a => a(0)) allAttrs -- refs -- nulllist }

Each tuple in a relation with some candidate key can be uniquely identified by values of that key. A KeyMap(R) maps the candidate keys in a relation to a map of key values to the subject nodes assigned to each tuple.

KeyMap { CandidateKey → { [CellValue] → RDF Node } } A KeyMap is a map from candidate key to a map from list of cell values to RDF nodes. type KeyMap = Map[CandidateKey, Map[List[CellValue], Node]] RowIRI { CandidateKey → KeyMap } A RowIRI is a map from relation name to key map. type RowIRI = Map[TableName, KeyMap]

The function directDB(DB) computes a RowIRI M for each relation with one or more candidate keys. The function directR(R, M) maps the Tuples in a Table R to an RDF graph. The following definitions assume the existance of some BaseIRI U and Database DB.

directDB() { directR(R, M) ∣ R ∈ DB } The directDB of a database DB is a set of RDF triples (RDF graph) created by calling directR on each relation in DB. def directDB (u:BaseIRI, db:Database) : RDFGraph = { val idxables = db.keySet filter { rn => !db(rn).candidates.isEmpty } val rowIRI = idxables map {rn => rn -> relation2KeyMap(u, db(rn))} db.keySet.flatMap(rn => directR(u, db(rn), rowIRI, db)) } directR(R, M) { directT(T, R, M) ∣ T ∈ R.Body } The directR of a relation is a set of RDF triples created by calling directT on each tuple in the body of the database. def directR (u:BaseIRI, r:Table, nodes:RowIRI, db:Database) : RDFGraph = body(r).flatMap(t => directT(u, t, r, nodes, db)) directT(T, R, M) { directS(S, T, R, M) ∣ S = subject(T, R, M) } The directT of a tuple in a relation is a set of RDF triples created by calling directS with an S created by the function subject. def directT (u:BaseIRI, t:Tuple, r:Table, nodes:RowIRI, db:Database) : Set[Triple] = { val s = subject(t, r, nodes, db) directS(u, s, t, r, nodes, db) } subject(T, R, M) if (pk(R) = ∅) then new blank node else rowIRI(R, T[pk(R)]) # references the ultimate referent of hierarchical key The subject identifier for a tuple in a relation is fresh blank node, if there is no primary key, or the IRI returned from rowIRI of that primary key's attribute values in that tuple. def subject (t:Tuple, r:Table, nodes:RowIRI, db:Database):Node = if (r.candidates.size > 0) { // Known to have at least one key, so take the first one. val k = r.candidates(0) val vs = t.lexvaluesNoNulls(k) nodes.ultimateReferent(r.name, k, vs, db) } else /** Table has no candidate keys. */ freshbnode() directS(S, T, R, M) { directL(S, R, A) ∣ A ∈ scalars(T, R) } ∪ { directN(S, As, T, M) ∣ As ∈ references(T, R) } The directS of a subect, tuple and relation is the set of RDF triples created by:
  • calling directL on each scalar attribute in T,
  • calling directN on each foreign key in T
 def directS (u:BaseIRI, s:Node, t:Tuple, r:Table, nodes:RowIRI, db:Database) : Set[Triple] = { references(t, r).map(as => directN(u, s, as, r, t, nodes)) ++ scalars(t, r).map(a => directL(u, r.name, s, a, r.header, t)) } directL(S, R, A) triple(S, propertyIRI(R, [A]), literalmap(A)) The directL of a subject, relation and attribute is the RDF triple with that subject, the predicate returned from propertyIRI, and the object returned from literalmap. def directL (u:BaseIRI, rn:TableName, s:Node, a:AttrName, h:Header, t:Tuple) : Triple = { val p = propertyIRI (u, rn, List(a)) val l = t.lexvalue(a).get val o = literalmap(l, h.sqlDatatype(a)) Triple(s, p, o) } directN(S, R, As) triple(S, propertyIRI(R, As), rowIRI(R, As)) The directN of a subject, relation and list of attributes is the RDF triple with that subject, a predicate returned from propertyIRI, and the object returned by rowIRI of the list of attributes. def directN (u:BaseIRI, s:Node, as:List[AttrName], r:Table, t:Tuple, nodes:RowIRI) : Triple = { val p = propertyIRI (u, r.name, as) val ls:List[LexicalValue] = t.lexvaluesNoNulls(as) val target = r.fks(as) val o:Object = nodes(target.rel)(target.attrs)(ls) Triple(s, p, o) }

rowIRI generates a row IRI. propertyIRI generates a property IRI.

rowIRI(R, As) IRI(base + "/" + UE(R.name) + "/" + (join(',', UE(A.name) + "=" + UE(A.value)) ∣ A ∈ As )) A rowIRI is a concatonation, with punctuation as separators, of a base IRI, url-encoded relation name, and the attribute name/value pairs in the list of attributes. def rowIRI (u:BaseIRI, rn:TableName, as:List[AttrName], ls:List[LexicalValue]) : IRI = { val pairs:List[String] = as.zip(ls).map(x => UE(x._1) + "=" + UE(x._2.s)) u + ("/" + UE(rn) + "/" + pairs.mkString("_")) } RDF Graph (set of triples) propertyIRI(R, As) IRI(base + "/" + (join(',', UE(A.name)) ∣ A ∈ As ) "#" As.name) A propertyIRI is a concatonation, with punctuation as separators, of a base IRI, url-encoded relation name, and the attribute names the list of attributes. def propertyIRI (u:BaseIRI, rn:TableName, as:List[AttrName]) : IRI = u + ("/" + UE(rn) + "#" + as.mkString("_"))

literalmap produces RDF literal with XSD datatypes with this type mapping TM:

literalmap(A) Literal(A[V], SQL2XSD[A]) ∣ SQL2XSD is the mapping from SQL datatypes to XML datatypes below:
XML Datatypes for SQL Datatypes
SQL XSD data type for typed literals, "plain literal" for plain literals
INT http://www.w3.org/TR/xmlschema-2/#integer
FLOAT http://www.w3.org/TR/xmlschema-2/#float
DATE http://www.w3.org/TR/xmlschema-2/#date
TIME http://www.w3.org/TR/xmlschema-2/#time
TIMESTAMP http://www.w3.org/TR/xmlschema-2/#dateTime
CHAR plain literal
VARCHAR plain literal
STRING plain literal

UE (url-encode) is the conventional url encoding used for e.g. HTML CGI forms:

UE(T) url-encode T per WSDL urlEncoded. References SPARQL Query Language for RDF, Eric Prud'hommeaux and Andy Seaborne 2008. SQL. ISO/IEC 9075-1:2008 SQL – Part 1: Framework (SQL/Framework) International Organization for Standardization, 27 January 2009. ISO/IEC 9075-2:2008 SQL – Part 2: Foundation (SQL/Foundation) International Organization for Standardization, 27 January 2009. Resource Description Framework (RDF): Concepts and Abstract Syntax, G. Klyne, J. J. Carroll, Editors, W3C Recommendation, 10 February 2004 Reusable Identifiers in the RDB2RDF mapping language, Michael Hausenblas and Themis Palpanas, 2009. RFC3986 - Uniform Resource Identifier (URI): Generic Syntax RFC3987 - Internationalized Resource Identifier (IRIs) CVS History 
$Log: Overview.xml,v $
Revision 1.60  2011/03/03 18:26:31  eric
- "#_"

Revision 1.59  2011/01/08 15:19:00  eric
- Hierarchical Tables

Revision 1.58  2011/01/08 15:02:45  eric
~ rolled back to pre-collaborative version

Revision 1.57  2010/11/10 14:47:28  marenas
Removing "(Editor)" from the list of authors

Revision 1.56  2010/11/10 02:47:08  eric
~ well-formedness error

Revision 1.55  2010/11/10 02:45:37  eric
~ finished adopting the all-relative-IRI model in order to sync with the merged text from alt/
~ adopted "direct" mapping per the resolution of the 2010-11-09 telecon
~ made Juan and Marcello editors instead of authors
~ fixed a couple typos
: I believe this specification follows the intent of:
  RESOLUTION: http://www.w3.org/2001/sw/rdb2rdf/directMapping/ with Juan,
  Marcelo and Eric as editors based on Richard's proposal as of
  http://lists.w3.org/Archives/Public/public-rdb2rdf-wg/2010Nov/0052.html and
  try to work in J&M's IRI and Triple generations part; move hierarchical
  table and the M-M mappings into Ed note; datalog as a separate section; Eric
  perform merge with review/approval/consensus of Juan, Marcelo, & Eric

Revision 1.54  2010/11/09 22:46:56  eric
+ hier-table-at-risk issue

Revision 1.53  2010/11/09 22:41:02  eric
~ date

Revision 1.52  2010/11/09 22:39:12  eric
~ s/stem/base/g
+ inclusion of collapsible sections from alt/

Revision 1.51  2010/11/09 15:39:46  eric
~ removed collapsible sections per request mid:AANLkTikvnrgXuu5fDAw+c2nUv5ENkmngPAJJ05c2gASk@mail.gmail.com

Revision 1.50  2010/11/09 15:06:34  eric
+ exp sections

Revision 1.49  2010/11/09 14:12:08  eric
~ addressed cygri's comments of 2010-11-09T06:46:12Z

Revision 1.48  2010/11/09 04:11:35  eric
~ addressed cygri's comments of 2010-11-07T04:13Z
+ inclusion of some explanatory details from alt

Revision 1.47  2010/11/04 12:42:21  eric
~ working on style for editorial choices

Revision 1.46  2010/11/04 06:10:08  eric
~ hilit triples in query in Use of Direct Mapping

Revision 1.45  2010/11/04 05:42:55  eric
~ incorporated Richard Cyganiak's comments targeted at alt

Revision 1.44  2010/11/02 08:18:07  eric
~ updates per DanC's feedback

Revision 1.43  2010/10/29 03:10:12  eric
~ s/relational terminology/SQL terminology/

Revision 1.42  2010/10/17 13:46:48  eric
+ SQL constraints

Revision 1.41  2010/10/12 14:21:36  eric
~ renumbered

Revision 1.40  2010/10/12 12:14:52  eric
+ SQL for example 1

Revision 1.39  2010/10/11 03:12:21  eric
~ prettied up mutual-hilights

Revision 1.38  2010/10/10 22:09:55  eric
+ pfkexception

Revision 1.37  2010/10/10 14:25:41  eric
~ re-worked front-loaded informative rules

Revision 1.36  2010/10/10 11:59:01  eric
~ prettied-up pre@class=turtle
~ experimenting with new presentation of transformation rules
~ validated XSLT output

Revision 1.35  2010/10/09 15:12:40  eric
+ crosslinks for hier-tabl

Revision 1.34  2010/10/09 14:52:31  eric
+ crosslinks for ref-no-pk

Revision 1.33  2010/10/09 13:45:17  eric
~ symmetric xrefs between tables and triples for emp-addr and multi-key

Revision 1.32  2010/10/08 21:59:54  eric
+ hilights

Revision 1.31  2010/09/29 19:53:37  eric
~ align with https://dvcs.w3.org/hg/stemGraph/

Revision 1.30  2010/09/29 15:13:18  eric
~ align with https://dvcs.w3.org/hg/stemGraph/rev/75cf39ef7d74

Revision 1.29  2010/09/29 03:34:55  eric
+ 2nd gen hierarchical example

Revision 1.28  2010/09/28 03:10:53  eric
validation

Revision 1.27  2010/09/28 03:08:52  eric
+ hierarchical (untested)

Revision 1.26  2010/09/27 21:49:18  eric
~ XML validation (per xsltproc)

Revision 1.25  2010/09/27 21:46:42  eric
~ fixed reference table name

Revision 1.24  2010/09/27 18:48:46  eric
+ noticed another key in ref-no-pk

Revision 1.23  2010/09/27 18:13:03  eric
+ ref-no-pk

Revision 1.22  2010/09/27 14:50:44  eric
+ nodemap
+ a rough pass on <scala>scala code</scala>

Revision 1.21  2010/09/26 04:50:07  eric
~ fix load state for syntax display

Revision 1.20  2010/09/25 18:40:39  eric
+ some tips

Revision 1.19  2010/09/24 16:34:02  eric
+ some tips

Revision 1.18  2010/09/24 16:00:53  eric
+ some tips

Revision 1.17  2010/09/24 15:50:41  eric
+ buttons for different languages

Revision 1.16  2010/09/07 12:14:44  eric
~ fixed pk invocation errors per  mid:04C1B62C-42A5-424C-974B-6E894ED7B11A@cyganiak.de

Revision 1.15  2010/08/30 18:37:19  eric
+ Empty (Non-existent) Primary Keys section

Revision 1.14  2010/08/30 14:05:45  eric
+ fks

Revision 1.13  2010/08/30 13:27:01  eric
~ content-free prettying-up

Revision 1.12  2010/08/23 14:24:22  eric
~ simplified per Richard's suggestions

Revision 1.11  2010/07/18 21:33:21  eric
~ proof-reading for an explanatory email

Revision 1.10  2010/07/12 23:15:42  eric
~ typos revealed when geeking with Sandro

Revision 1.9  2010/06/15 15:23:43  eric
~ validating

Revision 1.8  2010/06/15 14:33:59  eric
~ s/Heading/Header/ per google fight

Revision 1.7  2010/06/15 14:27:08  eric
~ s/∀/∣/g per cygri's comment

Revision 1.6  2010/06/07 15:49:34  eric
+ Extending the Direct Mapping section

Revision 1.5  2010/06/07 14:35:18  eric
+ finished mappings

Revision 1.4  2010/06/03 23:02:58  eric
~ SNAPSHOT

Revision 1.3  2010/06/03 13:06:00  eric
+ start on literal map

Revision 1.2  2010/06/03 12:43:30  eric
~ made algebra all symboly

Revision 1.1  2010/06/02 15:03:34  eric
CREATED