A Direct Mapping of Relational Data to RDF

Internal Working Draft

Editor's Draft

$Id: Overview.xml,v 1.37 2011/11/15 17:08:34 eric Exp $ http://www.w3.org/TR/2011/WD-rdb-direct-mapping-20110324/ http://www.w3.org/TR/rdb-direct-mapping/ Marcelo Arenas Pontificia Universidad Católica de Chile marenas@ing.puc.cl Alexandre Bertails W3C bertails@w3.org Eric Prud'hommeaux W3C eric@w3.org Juan Sequeda University of Texas at Austin jsequeda@cs.utexas.edu

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 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 Public Working Draft of the "A Direct Mapping of Relational Data to RDF" for review by W3C members and other interested parties.

This document was developed by the W3C RDB2RDF Working Group. The Working Group expects to advance this Working Draft to Recommendation Status. A complete list of changes to this document is available.

Comments on this document should be sent to public-rdb2rdf-comments@w3.org, a mailing list with a public archive.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

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.

Last Modified: $Id: Overview.xml,v 1.37 2011/11/15 17:08:34 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 also be 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 representation of the data in any relational database with a set of common datatypes (see the definition of literal map below). The direct mapping takes as input a relational database (data and schema), and generates an RDF graph that is called the direct graph. The algorithms in this document compose a graph of relative IRIs which must be resolved against a base IRI to form an RDF graph.

Foreign keys in relational databases establish a 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 row.

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, PRIMARY KEY(ID), city CHAR(10), state CHAR(2) ) CREATE TABLE People ( ID INT, PRIMARY KEY(ID), fname CHAR(10), addr INT, 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 IRI http://foo.example/DB/, the direct mapping of this database produces a direct graph:

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 IRI, 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 IRI, table name and the column name. The values are RDF literals formed from the lexical form of the column value. Each foreign keys produces a triple with a predicate composed from the foreign key column names, the referenced table, and the referenced column names. The object of these triples is the row identifiers (<Addresses/ID-18>) for the referenced triple. Note that these reference row identifiers must coincide with the subject used for the triples generated from the referenced row. Additionally, the direct mapping does not generate triples for NULL values; note however that it is not known how to relate the behaviour of the obtained RDF graph with the standard SQL semantics of the NULL values of the source RDB. For a detailed discussion of this issue, see a forthcoming working group note.

Foreign keys referencing candidate keys

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

CREATE TABLE Addresses ( ID INT, city CHAR(10), state CHAR(2), PRIMARY KEY(ID) ) CREATE TABLE Department ( ID INT, name CHAR(10), city CHAR(10), manager INT, PRIMARY KEY(ID), UNIQUE (name, city) ) CREATE TABLE People ( ID INT, fname CHAR(10), addr INT, deptName CHAR(10), deptCity CHAR(10), PRIMARY KEY(ID), FOREIGN KEY(addr) REFERENCES Addresses(ID), FOREIGN KEY(deptName, deptCity) REFERENCES Department(name, city) ) ALTER TABLE Department ADD FOREIGN KEY(manager) REFERENCES People(ID)

Following is an instance of this schema:

People
PK		→ Addresses(ID)	→ 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		→ People(ID)
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 the columns "deptName" and "deptCity", reflecting the order of the column names in the foreign key. The object of the above predicate is formed from the base IRI, the table name "Department" and the primary key value "ID=23".

In this example, the direct mapping generates the following triples:

@base <http://foo.example/DB/> @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . <People/ID-7> rdf:type <People> . <People/ID-7> <People#ID> 7 . <People/ID-7> <People#fname> "Bob" . <People/ID-7> <People#addr> 18 . <People/ID-7> <People#ref-addr> <Addresses/ID-18> . <People/ID-7> <People#deptName> "accounting" . <People/ID-7> <People#deptCity> "Cambridge" . <People/ID-7> <People#ref-deptName.deptCity> <Department/ID-23> . <People/ID-8> rdf:type <People> . <People/ID-8> <People#ID> 8 . <People/ID-8> <People#fname> "Sue" . <Addresses/ID-18> rdf:type <Addresses> . <Addresses/ID-18> <Addresses#ID> 18 . <Addresses/ID-18> <Addresses#city> "Cambridge" . <Addresses/ID-18> <Addresses#state> "MA" . <Department/ID-23> rdf:type <Department> . <Department/ID-23> <Department#ID> 23 . <Department/ID-23> <Department#name> "accounting" . <Department/ID-23> <Department#city> "Cambridge" . <Department/ID-23> <Department#manager> 8; . <Department/ID-23> <Department#ref-manager> <People#ID-8> .

The green triples above are generated by considering the new elements in the augmented database. Note:

The Reference Triple <People/ID-7> <People#ref-deptName.deptCity> <Department/ID-23> is generated by considering a foreign key referencing a candidate key (different from the primary key).

Multi-column primary keys

Primary keys may also be composite. If, in the above example, the primary key for Department were (name, city) instead of ID, the identifier for the only row in this table would be <Department/name-accounting.city-Cambridge>. The triples involving <Department/ID-23> would be substituted with the following triples:

<People/ID-7> <People#ref-deptName.deptCity> <Department/name-accounting.city-Cambridge> . <Department/name-accounting.city-Cambridge> rdf:type <Department> . <Department/name-accounting.city-Cambridge> <Department#ID> 23 . <Department/name-accounting.city-Cambridge> <Department#name> "accounting" . <Department/name-accounting.city-Cambridge> <Department#city> "Cambridge" . Empty (non-existent) primary keys

If there is no primary key, rows implies a set of triples with a shared subject, but that subject is a blank node. A Tweets table can be added to the above example to keep track of employees' tweets in Twitter:

CREATE TABLE Tweets ( tweeter INT, when TIMESTAMP, text CHAR(140), FOREIGN KEY(tweeter) REFERENCES People(ID) )

The following is an instance of table Tweets:

Tweets
→ People(ID)
tweeter	when	text
7	2010-08-30T01:33	I really like lolcats.
7	2010-08-30T09:01	I take it back.

Given that table Tweets does not have a primary key, each row in this table is identified by a Blank Node. In fact, when translating the above table the direct mapping generates the following triples:

@base <http://foo.example/DB/> @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . _:a rdf:type <Tweets> . _:a <Tweets#ref-tweeter> <People/ID-7> . _:a <Tweets#when> "2010-08-30T01:33"^^xsd:dateTime . _:a <Tweets#text> "I really like lolcats." . _:b rdf:type <Tweets> . _:b <Tweets#tweeter> <People/ID-7> . _:b <Tweets#when> "2010-08-30T09:01"^^xsd:dateTime . _:b <Tweets#text> "I take it back." . Referencing tables with empty primary keys

Rows in tables with no primary key may still be referenced by foreign keys. (Relational database 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) )

The following is an instance of the preceding schema:

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

In this case, the direct mapping generates the following triples from the preceding tables:

@base <http://foo.example/DB/> @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . _:c rdf:type <Projects> . _:c <Projects#lead> <People/ID-8> . _:c <Projects#name> "pencil survey" . _:c <Projects#deptName> "accounting" . _:c <Projects#deptCity> "Cambridge" . _:c <Projects#ref-deptName.deptCity> <Department/ID-23> . _:d rdf:type <Projects> . _:d <Projects#lead> <People/ID-8> . _:d <Projects#name> "eraser survey" . _:d <Projects#deptName> "accounting" . _:d <Projects#deptCity> "Cambridge" . _:d <Projects#ref-deptName.deptCity> <Department/ID-23> . <TaskAssignment/worker-7.project-pencil+survey> rdf:type <TaskAssignments> . <TaskAssignment/worker-7.project-pencil+survey> <TaskAssignments#worker> 7 . <TaskAssignment/worker-7.project-pencil+survey> <TaskAssignments#ref-worker> <People/ID-7> . <TaskAssignment/worker-7.project-pencil+survey> <TaskAssignments#project> "pencil survey" . <TaskAssignment/worker-7.project-pencil+survey> <TaskAssignments#deptName> "accounting" . <TaskAssignment/worker-7.project-pencil+survey> <TaskAssignments#deptCity> "Cambridge" . <TaskAssignment/worker-7.project-pencil+survey> <TaskAssignments#ref-deptName.deptCity> <Department/ID-23> . <TaskAssignment/worker-7.project-pencil+survey> <TaskAssignments#ref-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.

Direct Graph Definition

The Direct Graph is a formula for creating an RDF graph from the rows of each table and view in a database schema. A base IRI defines a web space for the IRIs in this graph; for the purposes of this specification, all IRIs are generated by appending to a base. Terms enclosed in <> are defined in the SQL specification .

An SQL table has a set of uniquely-named columns and a set of foreign keys, each mapping a <column name list> to a <unique column list> (a list of columns in some table).

SQL table and column identifiers compose RDF IRIs in the direct graph. These identifiers are separated by the punctuation characters '#', '.', '/' and '-'. All SQL identifiers are escaped following URL-encoding HTML form data except that only the above punctuation and the characters not permitted in RDF IRIs are escaped.

(a subset of HTML5 form dataset encoding):

Replace each PERCENT SIGN character ('%', U+0025) with the string "%25".
For table names, replace each NUMBER SIGN character ('#', U+0023) with the string "%23".
For table names, replace each SOLIDUS character ('/', U+002f) with the string "%2f".
For attribute names, replace each HYPHEN-MINUS character ('-', U+003d) with the string "%3D".
For attribute values, replace each FULL STOP character ('.', U+002e) with the string "%2E".
Replace each SPACE character (U+0020) with the PLUS SIGN character (+, U+002B).

There are many choices for the custom percent-encoding scheme to use for separating table names, attribute names and values in row nodes and reference property IRIs, described in ISSUE-67. This choice of separators is at risk and may change before this document reaches Candidate Recommendation. Adopt choice 1 of ericP's summary of options.

There is either a blank node or IRI assigned to each each row in a table:

If the table has a primary key, the row node is a relative IRI obtained by concatenating:
- the percent-encoded form of the table name,
- the SOLIDUS character '/',
- for each column in the primary key, in order:
  - the percent-encoded form of the column name,
  - an HYPHEN-MINUS character '-',
  - the percent-encoded form of the column value,
  - if it is not the last column in the foreign key, a FULL STOP character '.'
If the table has no primary key, the row node is a fresh blank node that is unique to this row.

A table forms a table IRI:

the relative IRI consisting of the percent-encoded form of the table name

A column in a table forms a literal property IRI:

the concatenation of:

the percent-encoded form of the table name,
the hash character '#',
the percent-encoded form of the column name,

A foreign key in a table forms a reference property IRI:

the concatenation of:

the percent-encoded form of the table name,
the string '#ref-',
for each column in the foreign key, in order:
- the percent-encoded form of the column name,
- if it is not the last column in the foreign key, a FULL STOP character '.'

The values in a row are mapped to RDF literals:

a mapping from an SQL value with a datatype to:

for the SQL datatypes CHAR and VARCHAR, a Plain literal with the lexical value of the SQL value.
for the SQL datatypes BINARY, BINARY VARYING and BINARY LARGE OBJECT, a xsd:base64Binary with the XML Schema base64 encoding of the SQL value.
for the SQL datatype BOOLEAN, a xsd:boolean with a lexical value of 'true' or 'false'.

for the SQL datatypes listed in this table, a Typed literal with the this datatype and lexical form of the canonical XML Schema lexical representation of this domain:

SQL datatype	RDF datatype
`NUMERIC`, `DECIMAL`	`xsd:decimal`
`SMALLINT`, `INTEGER`, `BIGINT`	`xsd:integer`
`FLOAT`, `REAL`, `DOUBLE PRECISION`	`xsd:double`
`DATE`	`xsd:date`
`TIME`	`xsd:time`
`TIMESTAMP`	`xsd:dateTime`

Extensions to the Direct Mapping should note the spirit of this mapping, i.e. to use the canonical representation of an XML Schema Datatype corresponding to the SQL datatype.

Any input database with a given schema has a direct graph defined as:

the union of the table graphs for each table in a database schema. the union of the row graphs for each row in a table. an RDF graph consisting of the following triples:

the row type triple.
a reference triple for each <column name list> in a table's foreign keys where none of the column values is NULL.
a literal triple for each column in a table where the column value is non-NULL.

an RDF triple with:

subject: the row node for the row.
predicate: the RDF IRI rdf:type.
object: the table IRI for the table name.

an RDF triple with:

subject: the row node for the row.
predicate: the literal property IRI for the column.
object: the literal map for the column value.

an RDF triple with:

subject: the row node for the row.
predicate: the reference property IRI for the columns.
object: the row node for the referenced row.

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) Translating SQL Applications to the Semantic Web. Syed Hamid Tirmizi, Juan Sequeda and Daniel Miranker. 2008 Direct Mapping Algebra (Informative) Notations

The RDB and RDF data models make use of the commonly defined Abstract Data Types Set, List and MultiSet, used here as type constructors. For example, Set(A) denotes the type for the sets of elements of type A. We assume that they come with their common operations, such as the function size : Set → Int.

The definitions follow a type-as-specification approach, thus the models are based on dependent types. For example, { s:Set(A) | size(s) ≤ 1 } is a type denoting the sets for elements of type A, such that those sets have at most one element.

The denotational RDF semantics makes use of the set-builder notation for building the RDF sets.

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

Relational Data Model RDB Abstract Data Type Database Set(Table) Database { Table } A relational database is a set of tables. Table (TableName, Set((ColumnName, Datatype)), Set(CandidateKey), Set(PrimaryKey) | size() ≤ 1, Set(ForeignKey), Body) Table ( TableName, { ColumnName → Datatype }, { CandidateKey }, PrimaryKey?, { ForeignKey }, Body ) A relation has

a name uniquely defining this table in the database;
an associative array mapping each column to a SQL datatype;
a potentially empty list of candidate keys, possibly including a primary key;
a potentially empty set of foreign keys;
a body containing the rows of data.

Body MultiSet(Row) Body [ Row ] A body is a set of potentially duplicate rows. Row Set((ColumnName, CellValue)) Row { ColumnName → CellValue } A row is a associative array mapping each column in a row to a value. CellValue Value | NULL CellValue Value | Null A cell value is either a lexical value or NULL, denoting the absence of value. ForeignKey (List(ColumnName), Table, CandidateKey) ForeignKey { [ColumnName] → ( Table, [ColumnName] ) } A foreign key constrains the values of a <column name list> to be equivalent (by the SQL = operator) to the values of a <unique column list> in some row of the referenced table. PrimaryKey CandidateKey PrimaryKey CandidateKey A primary key is a candidate key with the additional constraint that none of the columns can have a NULL value. CandidateKey List(ColumnName) CandidateKey [ ColumnName ] A candidate key is an SQL <unique column list> in some table. This constrains that no two rows in the table have values for the <unique column list> which are all equivalent (by the SQL = operator). Datatype Int | Float | Date | … Datatype { INT | FLOAT | DATE | TIME | TIMESTAMP | CHAR | VARCHAR | STRING } A datatype is a common SQL datatype. TableName String TableName String A table name is a string. ColumnName String ColumnName String A column name is a string. RDB accessor functions tablename Table → TableName Given a table, tablename returns its name. header Table → Set((ColumnName, Datatype)) Given a table, header returns its header. candidateKeys Table → List(CandidateKey) Given a table, candidateKeys returns the list of candidate keys. primaryKey Table → { s:Set(CandidateKey) | size(s) ≤ 1 } Given a table, primaryKey returns a set containing the primary key if it exists, otherwise it returns an empty set. foreignKeys Table → Set(ForeignKey) Given a table, foreignKeys returns the set of foreign keys. unary ForeignKey → Boolean Given a foreign key, unary tells if this is a unary foreign key, meaning it has exactly one column. lexicals Table → Set({ c:ColumnName | ! unary(c) }) Given a table, lexicals returns the set of columns that do not constitute a unary foreign key. body Table → Body Given a table, body returns its body. datatype { h:Set((ColumnName, Datatype)) } → { c:ColumnName | ∃ d, (c,d) ∈ h } → { d:Datatype | (c,d) ∈ h } Given a header and a column in this header, datatype returns the datatype associated with this column. table { r:Row } → { t:Table | r ∈ t } Given a row, table returns the table to which this row belongs. value { r:Row } → { a:ColumnName | a ∈ r } → CellValue Given a row and a column in this row, value returns the cell value (can be NULL) for this column. dereference { r:Row } → { fk:ForeignKey | fk ∈ foreignKeys(table(r)) }
→ { targetRow:Row | (columnNames, targetTable, ck) = fk
                    targetRow ∈ body(targetTable)
                     ∀ c_i^fk ∈ columnNames, ∀ c_j^ck ∈ ck,
                        ∀ (c_k^r, v_k^r) ∈ r, ∀ (c_l^target, v_l^target) ∈ targetRow,
                        i = j → c_i^fk = c_k^r → c_j^ck = c_l^target → v_k^r = v_l^target } Given a row and a foreign key from the table containing this row, dereference returns the row which is referenced by this foreign key, i.e. the row for which the values of the foreign key's <unique column list> are all equivalent (by the SQL = operator) to the values for the foreign key's <column name list> in the referring table. RDF Data Model

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.

Graph Set(Triple) Graph { Triple } An RDF graph is a set of RDF triples. Triple (Subject, Predicate, Object) Triple ( Subject, Predicate, Object ) An RDF triple is composed of a subject, predicate and object. Subject IRI | BlankNode Subject IRI | BlankNode A subject is either an IRI or a blank node. Predicate IRI Predicate IRI A predicate is always an IRI. Object IRI | BlankNode | Literal Object IRI | BlankNode | Literal An object is either an IRI, a blank node, or a literal. BlankNode RDF blank node BlankNode RDF blank node A blank node is an arbitrary term used only to establish graph connectivity. Literal PlainLiteral | TypedLiteral Literal PlainLiteral | TypedLiteral A literal is either a plain literal or a typed literal. PlainLiteral lexicalForm | (lexicalForm, langageTag) PlainLiteral (lexicalForm) | (lexicalForm, langageTag) A plain literal has a lexical form and an optional language tag. TypedLiteral (lexicalForm, IRI) TypedLiteral (lexicalForm, IRI) An typed literal is composed of lexical form and a datatype IRI. IRI RDF URI-reference as subsequently restricted by SPARQL IRI RDF URI-reference as subsequently restricted by SPARQL An IRI is an RDF URI reference as subsequently restricted by SPARQL. lexicalForm a Unicode String lexicalForm a Unicode String SQL string representing a value. Denotational semantics

In this model, Databases are inhabitants of RDB and they are denoted by mathematical objects living in the RDF domain. This denotational semantics is what we call the Direct Mapping.

ue String → String A percent-encoding of the argument.

Most of the functions defining the Direct Mapping are higher-order functions parameterized by a function φ(r) row_node(r) which maps any row to a unique IRI or Blank Node:

φ ∀ db:Database, ∀ r:Row, r ∈ db
primaryKey(table(r)) ≠ ∅
    ue(tablename(table(r))) + '/' + ue(c₀) + '-' + value(r, c₀) + '.' + ⋯ + '.' + ue(c_n-1) + '-' + value(r, c_n-1)

    a BlankNode unique to r row_node (pk(R) ≠ ∅)
    IRI(UE(R.name) + "/" + (join('.', UE(A.name) + "=" + UE(A.value)) ∣ A ∈ As ))

    a BlankNode unique to r If a row belongs to a table with no primary key then φ maps this row to a unique BlankNode.

If the table has a primary key, the row node is a relative IRI obtained by concatenating:
- the percent-encoded form of the table name,
- the SOLIDUS character '/',
- for each column in the primary key, in order:
  - the percent-encoded form of the column name,
  - an HYPHEN-MINUS character '-',
  - the percent-encoded form of the column value,
  - if it is not the last column in the foreign key, a FULL STOP character '.'
If the table has no primary key, the row node is a fresh blank node that is unique to this row.

, (Row, Column) → IRI A mapping from a list of columns in a row to an IRI. r, c ue(tablename(table(r))) + '#' + ue(c)) literal_property_IRI(R, A) IRI(R.name + "#" + A.name) A concatenation, with punctuation as separators, of the url-encoded table name and the url-encoded column names. the concatenation of:

the percent-encoded form of the table name,
the hash character '#',
the percent-encoded form of the column name,

, (Row, ForeignKey) → IRI A mapping from a list of columns in a row to an IRI. r, fk (from*, reftable, to*) = fk
ue(tablename(table(r))) + '#'
+ ue(from₀) + '.' + ⋯ + '.' + ue(from_n-1) + '.'
+ ue(reftable) + '.'
+ ue(to₀) + '.' + ⋯ + '.' + ue(to_n-1)) reference_property_IRI(R, As) IRI(R.name + "#" + join('.', UE(A.name)) ∣ A ∈ As ) A concatenation, with punctuation as separators, of the url-encoded table name and the url-encoded column names. the concatenation of:

the percent-encoded form of the table name,
the hash character '#',
for each column in the primary key, in order:
- the percent-encoded form of the column name,
- if it is not the last column in the foreign key, a FULL STOP character '.'

The ⟦ ⟧^φ_datatype literal_map(r) function maps SQL values to XML Schema datatypes.

Datatype → IRI A mapping from a SQL datatype to an XML Schema datatype IRI. d d is Int XSD:integer
d is Float XSD:float
d is Date XSD:date
⋯ The XML Schema datatype for d as defined by IWD 9075 §9.5

The Direct Mapping is defined by induction on the structure of RDB. Thus it is defined for any relational database. The entry point for the Direct Mapping is the function ⟦ ⟧^φ_database direct_graph(r).

   Database → Graph A mapping from a relational database to an RDF graph. db { triple | triple ∈ t | t ∈ db } direct_graph() { table_graph(R) ∣ R ∈ DB } The union of the triples expressing each table in the database. the union of the table graphs for each table in a database schema. Table → Set(Triple) A mapping from a table to a set of RDF triples. t { triple | triple ∈ r | r ∈ body(t) } table_graph(R) { row_graph(T, R) ∣ T ∈ R.Body } The triples expressing each row in the table t the union of the row graphs for each row in a table. noNULLs Row → ForeignKey → Boolean A statement between a row and a foreign key, telling if the absence of NULL values noNULLs(r, fk) (columnNames, _, _) = fk
∀ c ∈ columnNames, value(r, c) ≠ NULL true if there is no NULL value in this row for this foreign key. Row → Set(Triple) A mapping from a row to a set of RDF triples. r s = φ(r)
  { r }
⋃ { r, c | value(r, c) ≠ NULL | c ∈ lexicals(r) }
⋃ { r, fk | noNULLs(r, fk) | fk ∈ foreignKeys(table(r)) } row_graph(T, R)   { type_triple(R) }
∪ { literal_triple(R, A) ∣ A ≠ Null ∧ [A] ∉ R.ForeignKeys(T) }
∪ { reference_triple(As, T) ∣ ∄(T(A) = Null ∣ A ∈ As) ∧ As ≠ R.PrimaryKey ∣ As ∈ R.ForeignKeys(T) The union of the triples coming from

the NOT NULL foreign keys
the NOT NULL lexical values (not contributing to a unary foreign key)
the table name, which denotes an RDF type information

an RDF graph consisting of the following triples:

the row type triple.
a reference triple for each <column name list> in a table's foreign keys where none of the column values is NULL.
a literal triple for each column in a table where the column value is non-NULL and where that column is NOT the sole column in any foreign key.

(Row) → Triple A mapping from a column in a row to an optional pair of RDF predicate and object. r s = φ(r)
{ (s, rdf:type, ue(tablename(table(r)))) } type_triple(R) triple(row node(R), rdf:type, ue(R.name)) If the cell value for this column is NULL: nothing;
Otherwise: a predicate based on the column name and a typed type made of the value in the cell plus the corresponding RDF datatype. an RDF triple with:

subject: the row node for the row.
predicate: the RDF IRI rdf:type.
object: the relative IRI consisting of the percent-encoded form of the table name.

,   (Row, Column) → Triple //@@ I can't explain why this was: { s:Set((Predicate, Object)) | size(s) ≤ 1 } A mapping from a column in a row to an optional pair of RDF predicate and object. r, c s = φ(r)
p = table(r), c
v = value(r, c)
d = datatype(header(table(r))(c))
v is NULL ∅
d is String {(s, p, v)}
      datatype_iri = d
          {(s, p, (v, datatype_iri))} literal_triple(R, A) triple(row node(R), literal_property_IRI(R, [A]), literal_map(A)) If the cell value for this column is NULL: nothing;
Otherwise: a predicate based on the column name and a typed literal made of the value in the cell plus the corresponding RDF datatype. an RDF triple with:

subject: the row node for the row.
predicate: the literal property IRI for the column.
object: the literal map for the column value.

, (Row, ForeignKey) → Triple A mapping from a foreign key in a row to an RDF predicate and an RDF object. r, fk s = φ(r)
targetSpec = dereference(r, fk)
p = table(r), fk
o = φ(row(targetSpec))
(s, p, o) reference_triple(R, As) triple(row node(R), reference_property_IRI(R, As), row_node(dereference(R, As))) The predicate based on the column name and the object refered by the foreign key fk. an RDF triple with:

subject: the row node for the row.
predicate: the reference property IRI for the columns.
object: the row node for the referenced row.

Direct Mapping as Rules (Informative)

In this section, we formally present the Direct Mapping as rules in Datalog syntax, inspired by previous approach . The left hand side of each rule is the RDF Triple output. The right hand side of each rule consists of a sequence of predicates from the relational database and built-in predicates. The built-in predicates are divided into three groups. The first group contains some built-in predicates for dealing with repeated rows in a table without a primary key.

card(r, l, k): Given a table name r without a primary key and the list l of values [v₁, ..., v_n] for a row of table r, it returns in k the multiplicity of l in r (that is, k is the number of times row l appears in r) n ≤ m: This is the usual order on positive integer values (given positive integers n and m, it holds if n is smaller than or equal to m)

The second group contains a predicate to deal with null values.

nonNull(v): Given a value v, it holds if v is not null

Finally, the third group of built-in predicates is used to generate IRIs for identifying tables and the columns in a table, and to generate IRIs or blank nodes for identifying each row in a table.

generateTableIRI(r, i): Given a table name r, it generates the table IRI i of r generateLiteralPropertyIRI(r, l, i): Given a table name r and a non-empty list of columns l, it generates the literal property IRI i for l generateReferencePropertyIRI(r, l, i): Given a table name r and a non-empty list of columns l, it generates the reference property IRI i for l generateRowIRI(r, l₁, l₂, i): Given a table name r, a non-empty list l₁ of columns and a non-empty list l₂ of values (for the columns in l₁), it generates the row node (or Row IRI) i for the given row generateRowBlankNode(r, l, n, i): Given a table name r without a primary key, a list l of values for a row of table r and a positive integer n, it generates the row node i for the n-th occurrence of row l in r (which is a Blank Node in this case). It is assumed that n is smaller than or equal to the multiplicity of l in r (that is, if card(r, l, k) holds, then 1 ≤ n ≤ k)

Throughout the section, boxes containing Direct Mapping rules and examples will appear. These boxes are color-coded. Gray boxes contain Direct Mapping rules: This box contains a Direct Mapping rule

Yellow boxes contain examples of applying the previous Direct Mapping rule:

This box contains examples of applying a Direct Mapping rule

Consider again the example from Section Direct Mapping Example. It should be noticed that in the rules presented in this section, a formula of the form Addresses(X, Y, Z) indicates that the variables X, Y and Z are used to store the values of a row in the three columns of the table Addresses (according to the order specified in the schema of the table, that is, X, Y and Z store the values of ID, city and state, respectively). In particular, uppercase letters like X, Y, Z, S, P and O are used to denote variables. Moreover, double quotes are used in the rules to refer to the string with the name of a table or a column. For example, a formula of the form generateRowIRI("Addresses", ["ID"], [X], S) is used to generate the row node (or Row IRI) for the row of table "Addresses" whose value in the primary key "ID" is the value stored in the variable X. The value of this Row IRI is stored in the variable S.

Generating Row Type Triples Table has a primary key

Assume that r is a table with columns a₁, ..., a_m and such that [a_p₁, ..., a_{p_n}] is the primary key of r, where 1 ≤ n ≤ m and 1 ≤ p₁ < ... < p_n ≤ m. Then the following is the direct mapping rule to generate row type triples from r:

Triple(S, "rdf:type", O) ← r(X₁, ..., X_m), generateRowIRI("r", ["a_p₁", ..., "a_{p_n}"], [X_p₁, ..., X_{p_n}], S), generateTableIRI("r", O)

For example, table Addresses in the Direct Mapping Example has columns ID, city and state, and it has column ID as its primary key. Then the following is the direct mapping rule to generate row type triples from Addresses:

Triple(S, "rdf:type", O) ← Addresses(X₁, X₂, X₃), generateRowIRI("Addresses", ["ID"], [X₁], S), generateTableIRI("Addresses", O)

As a second example, consider table Department from the example in Section Foreign keys referencing candidate keys, which has columns ID, name, city and manager, and assume that (name, city) is the multi-column primary key of this table (instead of ID). Then the following is the direct mapping rule to generate row type triples from Department:

Triple(S, "rdf:type", O) ← Department(X₁, X₂, X₃, X₄), generateRowIRI("Department", ["name","city"], [X₂, X₃], S), generateTableIRI("Department", O)

Table does not have a primary key

Assume that r is a table with columns a₁, ..., a_m and such that r does not have a primary key. Then the following is the direct mapping rule to generate row type triples from r:

Triple(S, "rdf:type", O) ← r(X₁, ..., X_m), card("r", [X₁, ..., X_m], U), V ≤ U, generateRowBlankNode("r", [X₁, ..., X_m], V, S), generateTableIRI("r", O)

For example, table Tweets from Section Empty (non-existent) primary keys has columns tweeter, when and text, and it does not have a primary key. Then the following is the direct mapping rule to generate row type triples from Tweets:

Triple(S, "rdf:type", O) ← Tweets(X₁, X₂, X₃), card("Tweets", [X₁, X₂, X₃], U), V ≤ U, generateRowBlankNode("Tweets", [X₁, X₂, X₃], V, S), generateTableIRI("Tweets", O)

Generating Literal Triples Table has a primary key

Assume that r is a table with columns a₁, ..., a_m and such that [a_p₁, ..., a_{p_n}] is the primary key of r, where 1 ≤ n ≤ m and 1 ≤ p₁ < ... < p_n ≤ m. Then for every a_j (1 ≤ j ≤ m), the direct mapping includes the following rule for r and a_j to generate literal triples:

Triple(S, P, X_j) ← r(X₁, ..., X_m), nonNull(X_j), generateRowIRI("r", ["a_p₁", ..., "a_{p_n}"], [X_p₁, ..., X_{p_n}], S), generateLiteralPropertyIRI("r", ["a_j"], P)

For example, table Addresses in the Direct Mapping Example has columns ID, city and state, and it has column ID as its primary key. Then the following are the direct mapping rules to generate literal triples from Addresses:

Triple(S, P, X₁) ← Addresses(X₁, X₂, X₃), nonNull(X₁), generateRowIRI("Addresses", ["ID"], [X₁], S), generateLiteralPropertyIRI("Addresses", ["ID"], P) Triple(S, P, X₂) ← Addresses(X₁, X₂, X₃), nonNull(X₂), generateRowIRI("Addresses", ["ID"], [X₁], S), generateLiteralPropertyIRI("Addresses", ["city"], P) Triple(S, P, X₃) ← Addresses(X₁, X₂, X₃), nonNull(X₃), generateRowIRI("Addresses", ["ID"], [X₁], S), generateLiteralPropertyIRI("Addresses", ["state"], P)

As a second example, consider again table Department from the example in Section Foreign keys referencing candidate keys, which has columns ID, name, city and manager, and assume that (name, city) is the multi-column primary key of this table (instead of ID). Then the following are the direct mapping rules to generate literal triples from Department:

Triple(S, P, X₁) ← Department(X₁, X₂, X₃, X₄), nonNull(X₁), generateRowIRI("Department", ["name", "city"], [X₂, X₃], S), generateLiteralPropertyIRI("Department", ["ID"], P) Triple(S, P, X₂) ← Department(X₁, X₂, X₃, X₄), nonNull(X₂), generateRowIRI("Department", ["name", "city"], [X₂, X₃], S), generateLiteralPropertyIRI("Department", ["name"], P) Triple(S, P, X₃) ← Department(X₁, X₂, X₃, X₄), nonNull(X₃), generateRowIRI("Department", ["name", "city"], [X₂, X₃], S), generateLiteralPropertyIRI("Department", ["city"], P) Triple(S, P, X₄) ← Department(X₁, X₂, X₃, X₄), nonNull(X₄), generateRowIRI("Department", ["name", "city"], [X₂, X₃], S), generateLiteralPropertyIRI("Department", ["manager"], P)

Table does not have a primary key

Assume that r is a table with columns a₁, ..., a_m and such that r does not have a primary key. Then for every a_j (1 ≤ j ≤ m), the direct mapping includes the following rule for r and a_j to generate literal triples:

Triple(S, P, X_j) ← r(X₁, ..., X_m), nonNull(X_j), card("r", [X₁, ..., X_m], U), V ≤ U, generateRowBlankNode("r", [X₁, ..., X_m], V, S), generateLiteralPropertyIRI("r", ["a_j"], P)

For example, table Tweets from Section Empty (non-existent) primary keys has columns tweeter, when and text, and it does not have a primary key. Then the following are the direct mapping rules to generate literal triples from Tweets:

Triple(S, P, X₁) ← Tweets(X₁, X₂, X₃), nonNull(X₁), card("Tweets", [X₁, X₂, X₃], U), V ≤ U, generateRowBlankNode("Tweets", [X₁, X₂, X₃], V, S), generateLiteralPropertyIRI("Tweets", ["tweeter"], P) Triple(S, P, X₂) ← Tweets(X₁, X₂, X₃), nonNull(X₂), card("Tweets", [X₁, X₂, X₃], U), V ≤ U, generateRowBlankNode("Tweets", [X₁, X₂, X₃], V, S), generateLiteralPropertyIRI("Tweets", ["when"], P) Triple(S, P, X₃) ← Tweets(X₁, X₂, X₃), nonNull(X₃), card("Tweets", [X₁, X₂, X₃], U), V ≤ U, generateRowBlankNode("Tweets", [X₁, X₂, X₃], V, S), generateLiteralPropertyIRI("Tweets", ["text"], P)

Generating Reference Triples

For each foreign key from a table r₁ to a table r₂, one of the following four cases is applied.

Table r₁ has a primary key and table r₂ has a primary key

Assume that:

r₁ is a table with columns a₁, ..., a_i and such that [a_p₁, ..., a_{p_j}] is the primary key of r₁, where 1 ≤ j ≤ i and 1 ≤ p₁ < ... < p_j ≤ i

r₂ is a table with columns c₁, ..., c_k and such that [c_q₁, ..., c_{q_m}] is the primary key of r₂, where 1 ≤ m ≤ k and 1 ≤ q₁ < ... < q_m ≤ k

the foreign key indicates that the columns a_s₁, ..., a_{s_n} of r₁ reference the columns c_t₁, ..., c_{t_n} of r₂, where (1) 1 ≤ s₁, ..., s_n ≤ i, (2) 1 ≤ t₁, ..., t_n ≤ k, and (3) n ≥ 1

Then the direct mapping includes the following rule for r₁ and r₂ to generate Reference Triples:

Triple(S, P, O) ← r₁(X₁, ..., X_i), generateRowIRI("r₁", ["a_p₁", ..., "a_{p_j}"], [X_p₁, ..., X_{p_j}], S), r₂(Y₁, ..., Y_k), generateRowIRI("r₂", ["c_q₁", ..., "c_{q_m}"], [Y_q₁, ..., Y_{q_m}], O), nonNull(X_s₁), ..., nonNull(X_{s_n}), X_s₁ = Y_t₁, ..., X_{s_n} = Y_{t_n}, generateReferencePropertyIRI("r₁", ["a_s₁", ..., "a_{s_n}"], P)

For example, table Addresses in the Direct Mapping Example has columns ID, city and state, where column ID is the primary key. Table People in this example has columns ID, fname and addr, where column ID is the primary key, and it has a foreign key in the column addr that references the column ID in the table Addresses. In this case, the following is the direct mapping rule to generate Reference Triples:

Triple(S, P, O) ← People(X₁, X₂, X₃), generateRowIRI("People", ["ID"], [X₁], S), Addresses(Y₁, Y₂, Y₃), generateRowIRI("Addresses", ["ID"], [Y₁], O), nonNull(X₃), X₃ = Y₁, generateReferencePropertyIRI("People", ["addr"], P)

Table r₁ has a primary key and table r₂ does not have a primary key

Assume that:

r₁ is a table with columns a₁, ..., a_i and such that [a_p₁, ..., a_{p_j}] is the primary key of r₁, where 1 ≤ j ≤ i and and 1 ≤ p₁ < ... < p_j ≤ i

r₂ is a table with columns c₁, ..., c_k, and it does not have a primary key

Then the direct mapping includes the following rule for r₁ and r₂ to generate Reference Triples:

Triple(S, P, O) ← r₁(X₁, ..., X_i), generateRowIRI("r₁", ["a_p₁", ..., "a_{p_j}"], [X_p₁, ..., X_{p_j}], S), r₂(Y₁, ..., Y_k), card("r₂", [Y₁, ..., Y_k], U), V ≤ U, generateRowBlankNode("r₂", [Y₁, ..., Y_k], V, O), nonNull(X_s₁), ..., nonNull(X_{s_n}), X_s₁ = Y_t₁, ..., X_{s_n} = Y_{t_n}, generateReferencePropertyIRI("r₁", ["a_s₁", ..., "a_{s_n}"], P)

For example, assume that table Addresses in the Direct Mapping Example has columns ID, city and state, and that column ID is a candidate key (instead of a primary key), so that table Addresses does not have a primary key. Moreover, assume that table People in this example has columns ID, fname and addr, it has column ID as its primary key, and it has a foreign key in the column addr to the candidate key ID in the table Addresses. In this case, the following is the direct mapping rule to generate Reference Triples:

Triple(S, P, O) ← People(X₁, X₂, X₃), generateRowIRI("People", ["ID"], [X₁], S), Addresses(Y₁, Y₂, Y₃), card("Addresses", [Y₁, Y₂, Y₃], U), V ≤ U, generateRowBlankNode("Addresses", [Y₁, Y₂, Y₃], V, O), nonNull(X₃), X₃ = Y₁, generateReferencePropertyIRI("People", ["addr"], P)

Table r₁ does not have primary key and table r₂ has a primary key

Assume that:

r₁ is a table with columns a₁, ..., a_i, and it does not have a primary key

r₂ is a table with columns c₁, ..., c_k and such that [c_q₁, ..., c_{q_m}] is the primary key of r₂, where 1 ≤ m ≤ k and 1 ≤ q₁ < ... < q_m ≤ k

Then the direct mapping includes the following rule for r₁ and r₂ to generate Reference Triples:

Triple(S, P, O) ← r₁(X₁, ..., X_i), card("r₁", [X₁, ..., X_i], U), V ≤ U, generateRowBlankNode("r₁", [X₁, ..., X_i], V, S), r₂(Y₁, ..., Y_k), generateRowIRI("r₂", ["c_q₁", ..., "c_{q_m}"], [Y_q₁, ..., Y_{q_m}], O), nonNull(X_s₁), ..., nonNull(X_{s_n}), X_s₁ = Y_t₁, ..., X_{s_n} = Y_{t_n}, generateReferencePropertyIRI("r₁", ["a_s₁", ..., "a_{s_n}"], P)

For example, table People in the Direct Mapping Example has columns ID, fname and addr, and it has column ID as its primary key, while table Tweets from Section Empty (non-existent) primary keys has columns tweeter, when and text, it does not have a primary key, and it has a foreign key in column tweeter that references column ID in table People. In this case, the following is the direct mapping rule to generate Reference Triples:

Triple(S, P, O) ← Tweets(X₁, X₂, X₃), card("Tweets", [X₁, X₂, X₃], U), V ≤ U, generateRowBlankNode("Tweets", [X₁, X₂, X₃], V, S), People(Y₁, Y₂, Y₃), generateRowIRI("People", ["ID"], [Y₁], O), nonNull(X₁), X₁ = Y₁, generateReferencePropertyIRI("Tweets", ["tweeter"], P)

Table r₁ does not have primary key and table r₂ does not have a primary key

Assume that:

r₁ is a table with columns a₁, ..., a_i, and it does not have a primary key

r₂ is a table with columns c₁, ..., c_k, and it does not have a primary key

Then the direct mapping includes the following rule for r₁ and r₂ to generate Reference Triples:

Triple(S, P, O) ← r₁(X₁, ..., X_i), card("r₁", [X₁, ..., X_i], U₁), V₁ ≤ U₁, generateRowBlankNode("r₁", [X₁, ..., X_i], V₁, S), r₂(Y₁, ..., Y_k), card("r₂", [Y₁, ..., Y_k], U₂), V₂ ≤ U₂, generateRowBlankNode("r₂", [Y₁, ..., Y_k], V₂, O), nonNull(X_s₁), ..., nonNull(X_{s_n}), X_s₁ = Y_t₁, ..., X_{s_n} = Y_{t_n}, generateReferencePropertyIRI("r₁", ["a_s₁", ..., "a_{s_n}"], P)

For example, assume that table People in the Direct Mapping Example has columns ID, fname and addr, and that column ID is a candidate key (instead of a primary key), so that People does not have a primary key. Moreover, assume that table Tweets from Section Empty (non-existent) primary keys has columns tweeter, when and text, it does not have a primary key, and it has a foreign in column tweeter that references candidate key ID in table People. In this case, the following is the direct mapping rule to generate Reference Triples:

Triple(S, P, O) ← Tweets(X₁, X₂, X₃), card("Tweets", [X₁, X₂, X₃], U₁), V₁ ≤ U₁, generateRowBlankNode("Tweets", [X₁, X₂, X₃], V₁, S), People(Y₁, Y₂, Y₃), card("People", [Y₁, Y₂, Y₃], U₂), V₂ ≤ U₂, generateRowBlankNode("People", [Y₁, Y₂, Y₃], V₂, O), nonNull(X₁), X₁ = Y₁, generateReferencePropertyIRI("Tweets", ["tweeter"], P)

CVS History

$Log: Overview.xml,v $
Revision 1.37  2011/11/15 17:08:34  eric
~ reflect http://www.w3.org/mid/20111030231138.GA31372@w3.org

Revision 1.36  2011/11/15 05:59:24  jsequeda
Addressed the following last minute comments:

http://www.w3.org/2001/sw/rdb2rdf/wiki/Last_Call#5_DM_and_R2RML:_comments_on_working_drafts

http://www.w3.org/2001/sw/rdb2rdf/wiki/Last_Call#9_DM:_.28Editorial.29_Last_Call_Comments_on_the_Direct_Mapping_document

http://www.w3.org/2001/sw/rdb2rdf/wiki/Last_Call#11_DM:_Small_typographical_mistake

Revision 1.35  2011/09/20 13:33:04  marenas
fix some typos

Revision 1.34  2011/09/20 03:02:19  eric
~ finished with literal map

Revision 1.33  2011/09/19 20:59:07  eric
...

Revision 1.32  2011/09/19 20:57:37  eric
...

Revision 1.31  2011/09/19 20:34:38  eric
- issue 64
+ captured http://www.w3.org/2001/sw/rdb2rdf/r2rml/#datatype-conversions

Revision 1.30  2011/09/16 04:46:57  eric
~ cleaned up directory

Revision 1.16  2011/09/14 18:42:17  jsequeda
Updated Rules section to reflect the resolutions of the past issues.

Revision 1.15  2011/09/13 17:17:02  eric
...

Revision 1.14  2011/09/13 17:10:13  eric
...

Revision 1.13  2011/09/13 17:03:48  eric
...

Revision 1.12  2011/09/13 15:57:14  eric
+ separators issue

Revision 1.11  2011/09/09 03:50:04  eric
~ migrate to ① attr¹-val¹.attrⁿ-valⁿ   ref-attr¹.attrⁿ

Revision 1.10  2011/09/06 17:16:32  eric
~ update to '.'s and '-'s

Revision 1.9  2011/08/30 16:55:04  eric
+ custom-url-encode

Revision 1.8  2011/08/30 16:05:23  eric
+ anchors for examples

Revision 1.7  2011/08/30 16:02:41  eric
~ use '.' instead of '-'

Revision 1.6  2011/08/13 13:53:35  eric
~ refined explicitFK semantics
+ document keypress switches

Revision 1.5  2011/08/13 08:01:31  eric
~ re-ordered
+ alg delta for explicitFK

Revision 1.4  2011/08/10 19:02:46  eric
~ validation

Revision 1.3  2011/08/10 18:58:29  eric
~ editorial changes addressed in a response to David McNeil <dmcneil@revelytix.com> comments of 2011-08-10 10:12-0500

Revision 1.2  2011/08/10 12:16:14  eric
+ unary scalar triples
~ changed reference keys to include referenced table and columns
- property IRI
+ reference propety IRI
+ literal propety IRI
~ updated informative text to document construction of reference property IRIs

Revision 1.1  2011/08/10 11:09:44  eric
CREATED

Revision 1.10  2011/08/09 17:24:33  eric
...

Revision 1.9  2011/08/09 17:22:33  eric
...

Revision 1.8  2011/08/09 17:16:31  eric
...

Revision 1.7  2011/08/09 16:20:19  eric
- issues

Revision 1.6  2011/08/09 15:53:48  eric
~ merging in formal notation from ../directGraph/

Revision 1.5  2011/08/05 18:07:37  eric
~ fixing markup in the irc log

Revision 1.4  2011/08/05 14:26:41  eric
~ addressing cygri's comments

Revision 1.3  2011/08/05 03:13:48  eric
~ roll in marenas's 1.29 Overview.xml updates

Revision 1.2  2011/08/03 19:27:23  eric
~ s/attribute/column/

Revision 1.1  2011/08/03 17:26:31  eric
+ EGP.html

Revision 1.24  2011/07/06 17:13:56  bertails
~ emphasize keywords: let in if then else

Revision 1.23  2011/07/06 15:03:55  bertails
+ noNulls statement from K-CAP paper

Revision 1.22  2011/07/06 13:45:27  bertails
~ WD is pubrules compliant + new editor

Revision 1.21  2011/03/23 20:53:12  bertails
~ cleaning before moving to TR space

Revision 1.20  2011/03/17 23:16:34  eric
- fragments on node IRIs

Revision 1.19  2011/03/08 04:14:06  bertails
~ fix some typos

Revision 1.18  2011/03/07 00:48:06  bertails
+ phi function mapping rows to RDF nodes

Revision 1.17  2011/03/07 00:13:06  bertails
+ RDB accessor functions

Revision 1.16  2011/03/06 21:56:29  bertails
~ migrating to cleaner denotational semantics

Revision 1.15  2011/03/02 17:26:34  marenas
Datalog rules in Section 4 were simplified

Revision 1.14  2011/03/01 02:35:49  marenas
Section 4 now includes all the Datalog rules that define the direct mapping

Revision 1.13  2011/02/01 16:15:17  marenas
Section 4 now includes an example for each type of Datalog rule used to define the direct mapping

Revision 1.12  2011/01/27 01:16:42  marenas
New version of Datalog rules to deal with repeated tuples in a table without a primary key

Revision 1.11  2010/11/17 21:36:44  eric
~ validated HTML, CSS, links for publication

Revision 1.10  2010/11/16 17:45:35  eric
~ xml well-formed

Revision 1.9  2010/11/16 17:43:47  eric
~ 2010-11-16T17:34:38Z <ericP> mhausenblas: s/very simple direct mapping/direct mapping/
~ re-title notation
~ addressed nunolopes's issue with rule 23
~ text from #rdb2rdf 2010-11-16T17:40:18Z <juansequeda>...

Revision 1.8  2010/11/16 17:30:18  eric
~ fixed Notation title

Revision 1.7  2010/11/16 17:25:52  eric
~ re-oranized algebra section

Revision 1.6  2010/11/16 17:22:39  eric
~ re-ordered authors

Revision 1.5  2010/11/11 18:39:27  marenas
rephrasing the definition of table tuples

Revision 1.4  2010/11/11 17:58:25  marenas
New Section 2.2: "Preliminaries: Generating IRIs"
Examples are now grouped in Section 2.4: "Additional Examples and Corner Cases"

Revision 1.3  2010/11/10 14:54:48  marenas
Removing "(Editor)" from the list of authors

Revision 1.2  2010/11/10 12:56:22  eric
+ formalism-model issue

Revision 1.1  2010/11/10 02:51:03  eric
moved from ../directMapping

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