A Default Mapping of Relational Data to RDF

Internal Working Draft

Editor's Draft 30 October 2010

$Id: alt.xml,v 1.9 2010/11/08 15:20:14 marenas Exp $ http://www.w3.org/2001/sw/rdb2rdf/directGraph/alt http://www.w3.org/2001/sw/rdb2rdf/directGraph/alt Marcelo Arenas Pontificia Universidad Católica de Chile marenas@ing.puc.cl 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 very simple default 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.

Last Modified: $Id: alt.xml,v 1.9 2010/11/08 15:20:14 marenas 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, as well as a number of refinements intended both to meet use cases and establish a pattern for defining extensions.

Transformation Description (Informative)

This document defines a mapping from a relational database to RDF, which defines an RDF Graph representation of the data in a relational database. This is called the default mapping, which can be considered as the mapping to be used when an RDB2RDF system maps a relational database to RDF without any customization.

Transformation Example

Consider a relational database consisting of the following tables:

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

This database is used to store information about people and the places where they live. The following is an instance of the above relational schema:

People
PK		→ Addresses(ID)
ID	fname	addr
7	Bob	18
8	Sue	NULL

Addresses
PK
ID	city	state
18	Cambridge	MA

In the following sections, we explain how the default mapping translates a relational database into an RDF graph. In particular, we show that for the above relational schema and database instance, the output of the default mapping is the following set of triples:

@base <http://foo.example/DB/> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . <People/ID=7> <rdf:type> <People> . <People/ID=7> <People/ID> 7 . <People/ID=7> <People/fname> "Bob" . <People/ID=7> <People/addr> <Addresses/ID=18> . <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" . Preliminaries: Generating IRIs

In the process of translating relational data into RDF, the default mapping must create IRIs for identifying tables, the columns in a table, and each row in a table. In this document we define http://foo.example/DB as the base URI. All the examples in this document will contain relative URIs which are to be understood as relative to this base URI. The following are the IRIs that need to be generated:

Table IRI: The IRI that identifies a table is created by concatenating the base IRI with the table name. Specifically, if base_IRI is the base IRI and table_name is the table name, then base_IRI/table_name is the Table IRI for the table. Column IRI: Single-column IRI: The IRI that identifies a column of a table is created by concatenating the base IRI with the table name and the column name. Specifically, if base_IRI is the base IRI, table_name is the table name and column_name is the column name, then base_IRI/table_name/column_name is the Column IRI for the column. Multi-column IRI: The IRI that identifies a sequence of two or more columns of a table is created by concatenating the base IRI with the table name and the column names. Specifically, if base_IRI is the base IRI, table_name is the table name and column_name_1, column_name_2, ..., column_name_k is a sequence of k columns (k > 1), then base_IRI/table_name/column_name_1,column_name_2,...,column_name_k is the Column IRI for the columns. Row RDF Node: Row RDF Node for a row with a single-column primary key: The IRI that identifies a row is created by concatenating the base IRI with the table name, the column name of the primary key and the value of the row in that column. Specifically, if base_IRI is the base IRI, table_name is the table name, column_name is the column name of the primary key and value is the value of the row in that column, then base_IRI/table_name/column_name=value is the Row RDF Node (or Row IRI) for the row. Row RDF Node for a row with a multi-column primary key: The IRI that identifies a row is created by concatenating the base IRI with the table name, the names of the columns that constitute the primary key and the values of the row in those columns. Specifically, if base_IRI is the base IRI, table_name is the table name, column_name_1, column_name_2, ..., column_name_k is the sequence of k columns (k > 1) that constitute the primary key, and value_1, value_2, ..., value_k is the sequence of values of the columns that constitute the primary key of the row, then base_IRI/table_name/column_name_1=value_1,column_name_2=value_2,...,column_name_k=value_k is the Row RDF Node (or Row IRI) for the row. Row RDF Node for a row without a primary key: A fresh Blank Node is created, which is used as the Row RDF Node for the row.

For example, consider again the relational schema and the instance given in Section Transformation Example. Given the base IRI http://foo.example/DB, the following are some the IRIs that are used when translating the above relational data into RDF.

For the table People, the following IRIs are considered in the translation process:

Table IRI:

Column IRIs:

Row IRIs:

For the table Addresses, the following IRIs are considered in the translation process:

Table IRI:

Columns IRIs:

Row IRI:

<Addresses/ID=18> The Translation Process

In this section, we describe the three types of triples that are generated by the default mapping when translating information from a relational database, showing the different components of each one of these types of triples. As shown below, the default mapping considers the possible combinations of keys and foreign keys in relational databases [KEY-COMB] when generating these triples. In this section, we also present examples of the triples that are generated by the default mapping when considering some of these combinations.

The default mapping translates each table in a relational database into RDF, considering the schema and the rows of the table. Each row in the relational database produces a set of triples with a subject, predicate and object composed as follows:

Table Triples: Each row in a table generates a triple with the following: Subject: the Row RDF Node for the row Predicate: the rdf:type property Object: the Table IRI for the table Literal Triples: Each column with a non-null value, including the column(s) that constitute the primary key, and that either is not the only constituent of a foreign key or is the only constituent of a foreign key that references a candidate key, generates a triple with the following: Subject: the Row RDF Node for the row Predicate: the Column IRI for the column Object: an RDF Literal for the value of the row in the column, with an XML Schema datatype corresponding to the SQL datatype of that column [SQL2XSD] Reference Triples: Columns that constitute a foreign key and with non-null values in the row generate triples with the following: Subject: the Row RDF Node for the row Predicate: the Column IRI for the columns that constitute the foreign key Object: the Row RDF Node for the corresponding referenced row (according to the foreign key)

As an example of the above types of triples, we show how the 11 triples in the example of Section Transformation Example are classified into the above categories:

Triples generated from table People:

Table Triples:

<People/ID=7> <rdf:type> <People> . <People/ID=8> <rdf:type> <People> .

Literal Triples:

<People/ID=7> <People/ID> 7 . <People/ID=7> <People/fname> "Bob" . <People/ID=8> <People/ID> 8 . <People/ID=8> <People/fname> "Sue" .

Reference Triple:

<People/ID=7> <People/addr> <Addresses/ID=18> .

Triples generated from table Addresses:

Table Triple:

<Addresses/ID=18> <rdf:type> <Addresses> .

Literal Triples:

<Addresses/ID=18> <Addresses/ID> 18 . <Addresses/ID=18> <Addresses/city> "Cambridge" . <Addresses/ID=18> <Addresses/state> "MA" .

More complex relational schemas include multi-column primary keys and potentially incomplete foreign keys. Besides, SQL foreign keys may reference primary or candidate keys in the referenced relations. Thus, as a second example, assume that a table Department is included in the relational schema given in Section Transformation Example, which is used to store information about departments. Besides, assume that columns deptName and deptCity are added to the table People, for storing the name of the department where a person works, and the city where this department is located. The following is the schema of the augmented database:

CREATE TABLE Addresses { ID INT, city CHAR(10), state CHAR(2), PRIMARY KEY(ID) } CREATE TABLE Deparment { ID INT, name CHAR(10), city CHAR(10), manager INT, PRIMARY KEY(ID), UNIQUE (name, city), FOREIGN KEY(manager) REFERENCES People(ID) } 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) }

The following is an instance of the augmented relational 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

In this example, the default mapping generates the following Table Triples:

<People/ID=7> <rdf:type> <People> . <People/ID=8> <rdf:type> <People> . <Addresses/ID=18> <rdf:type> <Addresses> . <Department/ID=23> <rdf:type> <Department> .

The green triple above is generated by considering the new elements in the augmented database. Moreover, the default mapping generates the following Literal Triples in this example:

<People/ID=7> <People/ID> 7 . <People/ID=7> <People/fname> "Bob" . <People/ID=7> <People/deptName> "accounting" . <People/ID=7> <People/deptCity> "Cambridge" . <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" .

The green triples above are generated by considering the new elements in the augmented database. Notice that although deptName is a column of table People that is part of a foreign key, the Literal Triple

<People/ID=7> <People/deptName> "accounting" .

is generated by the default mapping because deptName is not the sole column of a foreign key of table People.

In this example, the translation process concludes with the generation of the following Reference Triples:

<People/ID=7> <People/addr> <Addresses/ID=18> . <People/ID=7> <People/deptName,deptCity> <Department/ID=23> . <Department/ID=23> <Department/manager> <People/ID=8> .

As in the previous cases, the green triples above are generated by considering the new elements in the augmented database. Notice that the second triple above is generated by considering a foreign key referencing a candidate key (instead of the primary key): (deptName, deptCity) is a multi-column foreign key in the table People which references the multi-column candidate key (name, city) in the table Department.

As a third example, we note that primary keys may also be composite. If the primary key for Department were (name, city) instead of ID in the running example, then the identifier for the only row in this table would be <Department/name=accounting,city=Cambridge>, and the following rows would have been generated by the default mapping:

<Department/name=accounting,city=Cambridge> <Department/ID> 23 . <Department/name=accounting,city=Cambridge> <Department/name> "accounting" . <Department/name=accounting,city=Cambridge> <Department/city> "Cambridge" .

As a final example, lets assume that a table Tweets is also included in the database considered in this section, which keeps track of tweets in Twitter. The following is the schema of this table:

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 default mapping will generate the following triples:

@prefix xsd: <http://www.w3.org/2001/XMLSchema#> . _:a <Tweets/when> "2010-08-30T01:33"^^xsd:dateTime . _:a <Tweets/text> "I really like lolcats." . _:b <Tweets/when> "2010-08-30T09:01"^^xsd:dateTime . _:b <Tweets/text> "I take it back." .

We conclude this section by showing the output of the default mapping in the complete example:

@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> . _: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." . Default Mapping as Rules

In this section, we formally present the Default Mapping as rules in Datalog syntax. 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: generateTableIRI(x, y): Given a table name x, it generates the Table IRI y generateColumnIRI(x, y, z): Given a table name x and a non-empty list of columns y, it generates the Column IRI z generateRowIRI(x, y₁, y₂, z): Given a table name x, a non-empty list y₁ of columns and a non-empty list y₂ of values (for the columns in y₁), it generates the Row RDF Node (or Row IRI) z. generateRowBlankNode(x, y, z): Given a table name x without a primary key and the list y of values for a row of table x, it generates the Row RDF Node z for the row (which is a Blank Node in this case).

Consider again the example from Section Transformation Example. It should be noticed that in the rules presented in this section, a formula of the form Addresses(x, y, z) indicates that 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). 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], p) is used to generate the Row RDF Node (or Row IRI) p for the row of table "Addresses" whose value in the primary key "ID" is the value stored in the variable x.

Generating Table Triples Table has a single-column primary key

Assume that r(a, b₁, ..., b_n) is a table with columns a, b₁, ..., b_n and such that [a] is the primary key of r. Then the following is the default mapping rule to generate Table Triples from r:

Triple(s, "rdf:type", o) ← r(x, y₁, ..., y_n), generateRowIRI("r", ["a"], [x], s), generateTableIRI("r", o)

Table has a multi-column primary key

Assume that r(a₁, ..., a_m, b₁, ..., b_n) is a table with columns a₁, ..., a_m, b₁, ..., b_n and such that [a₁, ..., a_m] is the primary key of r (m > 1). Then the following is the default mapping rule to generate Table Triples from r:

Triple(s, "rdf:type", o) ← r(x₁, ..., x_m, y₁, ..., y_n), generateRowIRI("r", ["a₁", ..., "a_m"], [x₁, ..., x_m], s), generateTableIRI("r", o)

Table does not have a primary key

Assume that r(b₁, ..., b_n) is a table with columns b₁, ..., b_n and such that r does not have a primary key. Then the following is the default mapping rule to generate Table Triples from r:

Triple(s, "rdf:type", o) ← r(y₁, ..., y_n), generateRowBlankNode("r", [y₁, ..., y_n], s), generateTableIRI("r", o)

Generating Literal Triples Table has a single-column primary key

Assume that r(a, b₁, ..., b_n) is a table with columns a, b₁, ..., b_n and such that [a] is the primary key of r. Then if a is not the only constituent of a foreign key of r or is the only constituent of a foreign key of r that references a candidate key, the default mapping includes the following rule for r and a to generate Literal Triples:

Triple(s, p, x) ← r(x, y₁, ..., y_n), generateRowIRI("r", ["a"], [x], s), generateColumnIRI("r", ["a"], p)

Moreover, for every b_j (1 ≤ j ≤ n) that is not the only constituent of a foreign key of r or is the only constituent of a foreign key of r that references a candidate key, the default mapping includes the following rule for r and b_j to generate Literal Triples:

Triple(s, p, y_j) ← r(x, y₁, ..., y_n), generateRowIRI("r", ["a"], [x], s), generateColumnIRI("r", ["b_j"], p)

Table has a multi-column primary key

Assume that r(a₁, ..., a_m, b₁, ..., b_n) is a table with columns a₁, ..., a_m, b₁, ..., b_n and such that [a₁, ..., a_m] is the primary key of r (m > 1). Then for every a_j (1 ≤ j ≤ m) that is not the only constituent of a foreign key of r or is the only constituent of a foreign key of r that references a candidate key, the default mapping includes the following rule for r and a_j to generate Literal Triples:

Triple(s, p, x_j) ← r(x₁, ..., x_m, y₁, ..., y_n), generateRowIRI("r", ["a₁", ..., "a_m"], [x₁, ..., x_m], s), generateColumnIRI("r", ["a_j"], p)

Triple(s, p, y_j) ← r(x₁, ..., x_m, y₁, ..., y_n), generateRowIRI("r", ["a₁", ..., "a_m"], [x₁, ..., x_m], s), generateColumnIRI("r", ["b_j"], p) Table does not have a primary key

Assume that r(b₁, ..., b_n) is a table with columns b₁, ..., b_n and such that r does not have a primary key. Then for every b_j (1 ≤ j ≤ n) that is not the only constituent of a foreign key of r or is the only constituent of a foreign key of r that references a candidate key, the default mapping includes the following rule for r and b_j to generate Literal Triples:

Triple(s, p, y_j) ← r(y₁, ..., y_n), generateRowBlankNode("r", [y₁, ..., y_n], s), generateColumnIRI("r", ["b_j"], p)

Generating Reference Triples

To-Do: Work in progress

Notation for this Document Notation for Types

A a type

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

Relational Model Definition (Normative)

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 { RelName → Relation } A relational database is a mapping of relation name to relation. case class Database( m:Map[RelName, Relation] ) Relation ( Header, [CandidateKey], PrimaryKey:CandidateKey, ForeignKeys, Body ) 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 Relation (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] → ( Relation, [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:RelName, 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 = Set[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 stem IRI defines a web space for the labels in this graph; all labels are generated by appending to the stem. 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:Relation):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:Relation):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]] NodeMap { CandidateKey → KeyMap } A NodeMap is a map from relation name to key map. type NodeMap = Map[RelName, KeyMap]

The function directDB(DB) computes a NodeMap for each relation with one or more candidate keys. The function directR(R) maps the Tuples in a Relation R to an RDF graph. The following definitions assume the existance of some StemIRI 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:StemIRI, db:Database) : RDFGraph = { val idxables = db.keySet filter { rn => !db(rn).candidates.isEmpty } val nodeMap = idxables map {rn => rn -> relation2KeyMap(u, db(rn))} db.keySet.flatMap(rn => directR(u, db(rn), nodeMap, 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:StemIRI, r:Relation, nodes:NodeMap, 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:StemIRI, t:Tuple, r:Relation, nodes:NodeMap, 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 nodemap(R, T[pk(R)]) !! 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 nodemap of that primary key's attribute values in that tuple. def subject (t:Tuple, r:Relation, nodes:NodeMap, 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:StemIRI, s:Node, t:Tuple, r:Relation, nodes:NodeMap, 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, predicatemap(R, [A]), literalmap(A)) The directL of a subject, relation and attribute is the RDF triple with that subject, the predicate returned from predicatemap, and the object returned from literalmap. def directL (u:StemIRI, rn:RelName, s:Node, a:AttrName, h:Header, t:Tuple) : Triple = { val p = predicatemap (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, predicatemap(R, As), nodemap(R, As)) The directN of a subject, relation and list of attributes is the RDF triple with that subject, a predicate returned from predicatemap, and the object returned by nodemap of the list of attributes. def directN (u:StemIRI, s:Node, as:List[AttrName], r:Relation, t:Tuple, nodes:NodeMap) : Triple = { val p = predicatemap (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) }

In the interest of keeping the generated RDF graph linked-data-friendly and in deference to the resolution of W3C Tag issue httpRange-14, the generated node and predicate labels can come in two flavors, hash or slash.

nodemap(R, As) IRI(stem + "/" + UE(R.name) + "/" + (join('_', UE(A.name) + "." + UE(A.value)) ∣ A ∈ As ) + "#_") A nodemap is a concatonation, with punctuation as separators, of a stem IRI, url-encoded relation name, and the attribute name/value pairs in the list of attributes. def nodemap (u:StemIRI, rn:RelName, 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("_") + "#_") } predicatemap(R, As) IRI(stem + "/" + (join('_', UE(A.name)) ∣ A ∈ As ) "#" As.name) A predicatemap is a concatonation, with punctuation as separators, of a stem IRI, url-encoded relation name, and the attribute names the list of attributes. def predicatemap (u:StemIRI, rn:RelName, 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:

SQL	XSD
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	http://www.w3.org/TR/xmlschema-2/#string
VARCHAR	http://www.w3.org/TR/xmlschema-2/#string
STRING	http://www.w3.org/TR/xmlschema-2/#string

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.need a better reference here 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 Translating SQL Applications to the Semantic Web. Syed H. Tirmizi, Juan F. Sequeda, and Daniel P. Miranker, 2008 Mapping SQL Datatypes to XML Schema datatype

SQL	XSD
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	http://www.w3.org/TR/xmlschema-2/#string
VARCHAR	http://www.w3.org/TR/xmlschema-2/#string
STRING	http://www.w3.org/TR/xmlschema-2/#string

CVS History

$Log: alt.xml,v $
Revision 1.9  2010/11/08 15:20:14  marenas
- with some corrections in Section 3
- with new built-in predicates generateRowIRI and generateRowBlankNode

Revision 1.8  2010/11/07 00:00:36  marenas
changing URL in "Latest version" and "Previous version"

Revision 1.7  2010/11/06 23:36:33  marenas
more rules in section 3

Revision 1.6  2010/11/06 22:13:32  marenas
simplifying section 2
adding section 3: mapping rules in Datalog

Revision 1.5  2010/11/05 00:36:26  marenas
eliminating redundancy from Section 2.3

Revision 1.4  2010/11/04 21:19:58  marenas
Eliminating redundancy from Section Transformation Description
Adding Tuple IRI
Changing to SQL notation (tuple -> row, attribute -> column)

Revision 1.3  2010/11/04 18:31:15  marenas
reorganizing Section Transformation Description

Revision 1.2  2010/10/30 03:39:01  marenas
New version of Section Transformation Description

Revision 1.1  2010/10/25 18:12:46  eric
copied from Overview.xml

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