]>
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.
Relational databases proliferate both because of their efficiency and their precise definitions, allowing for tools like SQL
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.
The direct mapping defines 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.
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:
HTML tables will be used in this document to convey SQL tables.
The primary key of these tables will be marked with the
Given a base IRI
In this expression, each row, e.g.
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:
Following is an instance of this schema:
Per the People tables's compound foreign key to Department:
In this example, the direct mapping generates the following triples:
The green triples above are generated by considering the new elements
in the augmented database. Note:
The Reference Triple
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
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:
The following is an instance of table Tweets:
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:
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:
The following is an instance of the preceding schema:
In this case, the direct mapping generates the following triples from the preceding tables:
The absence of a primary key forces the generation of blank nodes, but does not change the structure of the direct graph or names of the predicates in that graph.
The Direct Graph is 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 '#', '
There is either a blank node or IRI assigned to each each row in a table:
A table forms a table IRI:
A column in a table forms a literal property IRI:
A foreign key in a table forms a reference property IRI:
The values in a row are mapped to RDF literals:
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 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, The definitions follow a type-as-specification approach, thus the models are based on dependent types. For example, The denotational RDF semantics makes use of the set-builder notation for building the RDF sets.
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.
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. Most of the functions defining the Direct Mapping are higher-order functions parameterized by a function
The
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
In this section, we formally present the Direct Mapping as
rules in Datalog syntax, inspired by previous approach
The second group contains a predicate to deal with null values.
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.
Throughout the section, boxes containing Direct Mapping rules and examples will appear.
These boxes are color-coded. Gray boxes contain Direct Mapping rules:
Yellow boxes contain examples of applying the previous Direct Mapping rule:
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))
.
PK
→ Address(ID)
ID
fname
addr
7
Bob
18
8
Sue
NULL
PK
ID
city
state
18
Cambridge
MA
http://foo.example/DB/
, the direct
mapping of this database produces a direct graph:
(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
) 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.
PK
→ Addresses(ID)
→ Department(name, city)
ID
fname
addr
deptName
deptCity
7
Bob
18
accounting
Cambridge
8
Sue
NULL
NULL
NULL
PK
ID
city
state
18
Cambridge
MA
PK
Unique Key
→ People(ID)
ID
name
city
manager
23
accounting
Cambridge
8
deptName="accounting"
and deptCity="Cambridge"
references a row in Department with a primary key of ID=23
.
deptName
" and "deptCity
", reflecting the order of the column names in the foreign key.
Department
" and the primary key value "ID=23
".
<People/ID
is generated by considering a foreign key referencing a candidate key (different from the primary key).
<Department/name
.
The triples involving <Department/ID
would be substituted with the following triples:
→ People(ID)
tweeter
when
text
7
2010-08-30T01:33
I really like lolcats.
7
2010-08-30T09:01
I take it back.
Unique key
Unique key
→ People(ID)
→ Department(name, city)
lead
name
deptName
deptCity
8
pencil survey
accounting
Cambridge
8
eraser survey
accounting
Cambridge
PK
→ Projects(name, deptName, deptCity)
→ People(ID)
→ Departments(name, city)
worker
project
deptName
deptCity
7
pencil survey
accounting
Cambridge
CHAR
and VARCHAR
, a Plain literal with the lexical value of the SQL value.
BINARY
, BINARY VARYING
and BINARY LARGE OBJECT
, a xsd:base64Binary with the XML Schema base64 encoding of the SQL value.
BOOLEAN
, a xsd:boolean with a lexical value of 'true
' or 'false
'.
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
rdf:type
.
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
.{ 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.
=
operator) to the values of a <unique column list> in some row of the referenced table.=
operator).
→ { targetRow:
targetRow ∈
∀ (ckr, vkr) ∈ r, ∀ (cltarget, vltarget) ∈ targetRow,
i = j → cifk = ckr
→ cjck = cltarget
→ vkr = vltarget }
=
operator) to the values for the foreign key's <column name list> in the referring table.
a r
a r
φ
maps this row to a unique BlankNode.
+
+
+
⟦ ⟧φ
⋯⟦ ⟧φ
∀ c ∈ columnNames,
{
⋃ {
⋃ {
∪ {
∪ {
{ (s, rdf:type,
Otherwise: a predicate based on the column name and a typed type made of the value in the cell plus the corresponding RDF datatype.
rdf:type
.
{(s, p, (v, datatype_iri))}
Otherwise: a predicate based on the column name and a typed literal made of the value in the cell plus the corresponding RDF datatype.
(s, p, o)
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.
Assume that r is a table with columns a1, ..., am and such that [ap1, ..., apn] is the primary key of r, where 1 ≤ n ≤ m and 1 ≤ p1 < ... < pn ≤ m. Then the following is the direct mapping rule to generate row type triples from r:
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:
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:
Assume that r is a table with columns a1, ..., am 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:
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:
Assume that r is a table with columns a1, ..., am and such that [ap1, ..., apn] is the primary key of r, where 1 ≤ n ≤ m and 1 ≤ p1 < ... < pn ≤ m. Then for every aj (1 ≤ j ≤ m), the direct mapping includes the following rule for r and aj to generate literal triples:
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:
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:
Assume that r is a table with columns a1, ..., am and such that r does not have a primary key. Then for every aj (1 ≤ j ≤ m), the direct mapping includes the following rule for r and aj to generate literal triples:
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:
For each foreign key from a table r1 to a table r2, one of the following four cases is applied.
Assume that:
r1 is a table with columns a1, ..., ai and such that [ap1, ..., apj] is the primary key of r1, where 1 ≤ j ≤ i and 1 ≤ p1 < ... < pj ≤ i
r2 is a table with columns c1, ..., ck and such that [cq1, ..., cqm] is the primary key of r2, where 1 ≤ m ≤ k and 1 ≤ q1 < ... < qm ≤ k
the foreign key indicates that the columns as1, ..., asn of r1 reference the columns ct1, ..., ctn of r2, where (1) 1 ≤ s1, ..., sn ≤ i, (2) 1 ≤ t1, ..., tn ≤ k, and (3) n ≥ 1
Then the direct mapping includes the following rule for r1 and r2 to generate Reference Triples:
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:
Assume that:
r1 is a table with columns a1, ..., ai and such that [ap1, ..., apj] is the primary key of r1, where 1 ≤ j ≤ i and and 1 ≤ p1 < ... < pj ≤ i
r2 is a table with columns c1, ..., ck, and it does not have a primary key
the foreign key indicates that the columns as1, ..., asn of r1 reference the columns ct1, ..., ctn of r2, where (1) 1 ≤ s1, ..., sn ≤ i, (2) 1 ≤ t1, ..., tn ≤ k, and (3) n ≥ 1
Then the direct mapping includes the following rule for r1 and r2 to generate Reference Triples:
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:
Assume that:
r1 is a table with columns a1, ..., ai, and it does not have a primary key
r2 is a table with columns c1, ..., ck and such that [cq1, ..., cqm] is the primary key of r2, where 1 ≤ m ≤ k and 1 ≤ q1 < ... < qm ≤ k
the foreign key indicates that the columns as1, ..., asn of r1 reference the columns ct1, ..., ctn of r2, where (1) 1 ≤ s1, ..., sn ≤ i, (2) 1 ≤ t1, ..., tn ≤ k, and (3) n ≥ 1
Then the direct mapping includes the following rule for r1 and r2 to generate Reference Triples:
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:
Assume that:
r1 is a table with columns a1, ..., ai, and it does not have a primary key
r2 is a table with columns c1, ..., ck, and it does not have a primary key
the foreign key indicates that the columns as1, ..., asn of r1 reference the columns ct1, ..., ctn of r2, where (1) 1 ≤ s1, ..., sn ≤ i, (2) 1 ≤ t1, ..., tn ≤ k, and (3) n ≥ 1
Then the direct mapping includes the following rule for r1 and r2 to generate Reference Triples:
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:
$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