R2RML: RDB to RDF Mapping Language

1 Introduction

This specification describes R2RML, a language for expressing customized mappings from relational databases to RDF datasets. Such mappings provide the ability to view existing relational data in the RDF data model, expressed in a structure and target vocabulary of the mapping author's choice.

This specification has a companion that defines a direct mapping from relational databases to RDF [DM]. In the direct mapping of a database, the structure of the resulting RDF graph directly reflects the structure of the database, the target RDF vocabulary directly reflects the names of database schema elements, and neither structure nor target vocabulary can be changed. With R2RML on the other hand, a mapping author can define highly customized views over the relational data.

Every R2RML mapping is tailored to a specific database schema and target vocabulary. The input to an R2RML mapping is a relational database that conforms to that schema. The output is an RDF dataset [SPARQL], as defined in SPARQL, that uses predicates and types from the target vocabulary. The mapping is conceptual; R2RML processors are free to materialize the output data, or to offer virtual access through an interface that queries the underlying database, or to offer any other means of providing access to the output RDF dataset.

R2RML mappings are themselves expressed as RDF graphs and written down in Turtle syntax [TURTLE].

The intended audience of this specification is implementors of software that generates or processes R2RML mapping documents, as well as mapping authors looking for a reference to the R2RML language constructs. The document uses concepts from RDF Concepts and Abstract Syntax [RDF] and from the SQL language specifications [SQL1][SQL2]. A reader's familiarity with the contents of these documents, as well as with the Turtle syntax, is assumed.

The R2RML language is designed to meet the use cases and requirements identified in Use Cases and Requirements for Mapping Relational Databases to RDF [UCNR].

1.1 Document Conventions

In this document, examples assume the following namespace prefix bindings unless otherwise stated:

Throughout the document, boxes containing Turtle markup and SQL data will appear. These boxes are color-coded. Gray boxes contain RDFS definitions of R2RML vocabulary terms:

# This box contains RDFS definitions of R2RML vocabulary terms

Yellow boxes contain example fragments of R2RML mappings in Turtle syntax:

# This box contains example R2RML mappings

Blue tables contain example input into an R2RML mapping:

Green boxes contain example output:

# This box contains example output RDF triples or fragments

2 R2RML Overview and Example (Informative)

This section gives a brief overview of the R2RML mapping language, followed by a simple example relational database with an R2RML mapping document and its output RDF. Further R2RML examples can be found in the R2RML and Direct Mapping Test Cases [TC].

An R2RML mapping refers to logical tables to retrieve data from the input database. A logical table can be one of the following:

1. A base table,
2. a view, or
3. a valid SQL query (called an “R2RML view” because it emulates a SQL view without modifying the database).

Each logical table is mapped to RDF using a triples map. The triples map is a rule that maps each row in the logical table to a number of RDF triples. The rule has two main parts:

1. A subject map that generates the subject of all RDF triples that will be generated from a logical table row.
2. Multiple predicate-object maps that in turn consist of predicate maps and object maps (or referencing object maps).

Triples are produced by combining the subject map with a predicate map and object map, and applying these three to each logical table row. For example, the complete rule for generating a set of triples might be:

• Subjects: A template http://data.example.com/employee/{empno} is used to generate subject IRIs from the empno column.
• Predicates: The constant vocabulary IRI ex:name is used.
• Objects: The value of the ename column is used to produce an RDF literal.

By default, all RDF triples are in the default graph of the output dataset. A triples map can contain graph maps that place some or all of the triples into named graphs instead.

Figure 1: An overview of R2RML

2.1 Example Input Database

The following example database consists of two tables, EMP and DEPT, with one row each:

2.2 Desired RDF Output

The desired RDF triples to be produced from this database are as follows:

<http://data.example.com/employee/7369> rdf:type ex:Employee.
<http://data.example.com/employee/7369> ex:name "SMITH".
<http://data.example.com/employee/7369> ex:department <http://data.example.com/department/10>.

<http://data.example.com/department/10> rdf:type ex:Department.
<http://data.example.com/department/10> ex:name "APPSERVER".
<http://data.example.com/department/10> ex:location "NEW YORK".
<http://data.example.com/department/10> ex:staff 1.

Note in particular:

• Construction of custom IRI identifiers for departments and employees;
• use of a custom target vocabulary (ex:Employee, ex:location etc.);
• the ex:staff property has the total number of staff of a department; this value is not stored directly in the database but has to be computed.
• the ex:department property relates an employee to their department, using the identifiers of both entities;

2.3 Example: Mapping a Simple Table

The following partial R2RML mapping document will produce the desired triples from the EMP table (except the ex:department triple, which will be added later):

@prefix rr: <http://www.w3.org/ns/r2rml#>.

<#TriplesMap1>
    rr:logicalTable [ rr:tableName "EMP" ];
    rr:subjectMap [
        rr:template "http://data.example.com/employee/{EMPNO}";
        rr:class ex:Employee;
    ];
    rr:predicateObjectMap [
        rr:predicate ex:name;
        rr:objectMap [ rr:column "ENAME" ];
    ].

<http://data.example.com/employee/7369> rdf:type ex:Employee.
<http://data.example.com/employee/7369> ex:name "SMITH".

2.4 Example: Computing a Property with an R2RML View

Next, the DEPT table needs to be mapped. Instead of using the table directly as the basis for that mapping, an “R2RML view” will be defined based on a SQL query. This allows computation of the staff number. (Alternatively, one could define this view directly in the database.)

<#DeptTableView> rr:sqlQuery """
SELECT DEPTNO,
       DNAME,
       LOC,
       (SELECT COUNT(*) FROM EMP WHERE EMP.DEPTNO=DEPT.DEPTNO) AS STAFF
FROM DEPT;
""".

The definition of a triples map that generates the desired DEPT triples based on this R2RML view follows.

<#TriplesMap2>
    rr:logicalTable <#DeptTableView>;
    rr:subjectMap [
        rr:template "http://data.example.com/department/{DEPTNO}";
        rr:class ex:Department;
    ];
    rr:predicateObjectMap [
        rr:predicate ex:name;
        rr:objectMap [ rr:column "DNAME" ];
    ];
    rr:predicateObjectMap [
        rr:predicate ex:location;
        rr:objectMap [ rr:column "LOC" ];
    ];
    rr:predicateObjectMap [
        rr:predicate ex:staff;
        rr:objectMap [ rr:column "STAFF" ];
    ].

<http://data.example.com/department/10> rdf:type ex:Department.
<http://data.example.com/department/10> ex:name "APPSERVER".
<http://data.example.com/department/10> ex:location "NEW YORK".
<http://data.example.com/department/10> ex:staff 1.

2.5 Example: Linking Two Tables

To complete the mapping document, the ex:department triples need to be generated. Their subjects come from the first triples map (<#TriplesMap1>), the objects come from the second triples map (<#TriplesMap2>).

This can be achieved by adding another rr:predicateObjectMap to <#TriplesMap1>. This one uses the other triples map, <#TriplesMap2>, as a parent triples map:

<#TriplesMap1>
    rr:predicateObjectMap [
        rr:predicate ex:department;
        rr:objectMap [
            rr:parentTriplesMap <#TriplesMap2>;
            rr:joinCondition [
                rr:child "DEPTNO";
                rr:parent "DEPTNO";
            ];
        ];
    ].

This performs a join between the EMP table and the R2RML view, on the DEPTNO columns. The objects will be generated from the subject map of the parent triples map, yielding the desired triple:

<http://data.example.com/employee/7369> ex:department <http://data.example.com/department/10>.

This completes the R2RML mapping document. An R2RML processor will generate the triples listed above from this mapping document.

2.6 Example: Many-to-Many Tables

A final example will assume that a many-to-many relationship exists between the extended versions of EMP table and the DEPT table shown below. This many-to-many relationship is captured by the content of the EMP2DEPT table. The database consisting of the EMP, DEPT, and EMP2DEPT tables are shown below:

<http://data.example.com/employee=7369/department=10> 
    ex:employee   <http://data.example.com/employee/7369> ;
    ex:department <http://data.example.com/department/10> .

<http://data.example.com/employee=7369/department=20> 
    ex:employee <http://data.example.com/employee/7369> ;
    ex:department <http://data.example.com/department/20> .

<http://data.example.com/employee=7400/department=10> 
    ex:employee <http://data.example.com/employee/7400> ;
    ex:department <http://data.example.com/department/10> .
    

The following R2RML mapping will produce the desired triples listed above:

<#TriplesMap3>
    rr:tableName "EMP2DEPT";
    rr:subjectMap [ rr:template "http://data.example.com/employee={EMPNO}/department={DEPTNO}" ];
    rr:predicateObjectMap [
        rr:predicate ex:employee;
        rr:objectMap [ rr:template "http://data.example.com/employee/{EMPNO}" ; rr:termType rr:IRI ]];
    ];
    rr:predicateObjectMap [
        rr:predicate ex:department;
        rr:objectMap [ rr:template "http://data.example.com/department/{DEPTNO}" ; rr:termType rr:IRI ]];
    ].
    

However, if one does not require that the subjects in the desired output uniquely identify the rows in the EMP2DEPT table, the desired output may look as follows:

<http://data.example.com/employee/7369> 
    ex:department <http://data.example.com/department/10> ;
    ex:department <http://data.example.com/department/20> .

<http://data.example.com/employee/7400> 
    ex:department <http://data.example.com/department/10>.
    

The following R2RML mapping will produce the desired triples:

<#TriplesMap3>
    rr:tableName "EMP2DEPT";
    rr:subjectMap [
        rr:template "http://data.example.com/employee/{EMPNO}";
    ];
    rr:predicateObjectMap [
      rr:predicate ex:department;
      rr:objectMap [ rr:template "http://data.example.com/department/{DEPTNO}"; rr:termType rr:IRI ]"http://data.example.com/department/{DEPTNO}" ];
    ].

3 Conformance

As well as sections marked as non-normative in the section heading, all diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words must, must not, required, should, should not, recommended, may, and optional in this specification are to be interpreted as described in RFC 2119 [RFC2119].

This specification describes conformance criteria for:

• R2RML mapping documents
• R2RML mapping graphs
• R2RML processors
• R2RML data validators

A collection of test cases for R2RML processors and R2RML data validators is available in the R2RML and Direct Mapping Test Cases [TC].

This specification defines R2RML for databases that conform to Core SQL 2008, as defined in ISO/IEC 9075-1:2008 [SQL1] and ISO/IEC 9075-2:2008 [SQL2]. Processors and mappings may have to deviate from the R2RML specification in order to support databases that do not conform to this version of SQL.

Where SQL queries are embedded into R2RML mappings, SQL version identifiers can be used to indicate the specific version of SQL that is being used.

4 R2RML Processors and Mapping Documents

An R2RML mapping defines a mapping from a relational database to RDF. It is a structure that consists of one or more triples maps.

The input to an R2RML mapping is called the input database.

An R2RML processor is a system that, given an R2RML mapping and an input database, provides access to the output dataset.

There are no constraints on the method of access to the output dataset provided by a conforming R2RML processor. An R2RML processor MAY materialize the output dataset into a file, or offer virtual access through an interface that queries the input database, or offer any other means of providing access to the output dataset.

An R2RML processor also has access to an execution environment consisting of:

• A SQL connection to the input database,
• a base IRI used in resolving relative IRIs produced by the R2RML mapping.

The SQL connection is used by the R2RML processor to evaluate SQL queries against the input database. It MUST be established with sufficient privileges for read access to all base tables and views that are referenced in the R2RML mapping. It MUST be configured with a default catalog and default schema that will be used when tables and views are accessed without an explicit catalog or schema reference.

How the SQL connection is established, or how users are authenticated against the database, is outside of the scope of this document.

The base IRI MUST be a valid IRI. It SHOULD NOT contain question mark (“?”) or hash (“#”) characters and SHOULD end in a slash (“/”) character.

An R2RML data validator is a system that takes as its input an R2RML mapping, a base IRI, and a SQL connection to an input database, and checks for the presence of data errors. When checking the input database, a data validator MUST report any data errors that are raised in the process of generating the output dataset.

An R2RML processor MAY include an R2RML data validator, but this is not required.

4.1 Mapping Graphs and the R2RML Vocabulary

An R2RML mapping is represented as an RDF graph. In other words, RDF is used not just as the target data model of the mapping, but also as a formalism for representing the R2RML mapping itself.

An RDF graph that represents an R2RML mapping is called an R2RML mapping graph.

The R2RML vocabulary is the set of IRIs defined in this specification that start with the rr: namespace IRI:

http://www.w3.org/ns/r2rml#

An R2RML mapping graph:

• SHOULD NOT include any IRIs that start with the rr: namespace IRI, but are not defined in the R2RML vocabulary.
• SHOULD NOT include IRIs from the R2RML vocabulary where such use is not explicitly allowed or required by a clause in this specification.
• SHOULD NOT contain any only mapping components (logical tables, term maps, predicate-object maps) that are not referenced by asome triples map (in other words, are “unused”).all mapping components should actually be “used” in the mapping).
• MAY contain arbitrary additional triples whose terms are not from the R2RML vocabulary. In particular, a valid mapping graph MAY contain documentation in the form of rdfs:label, rdfs:comment and similar properties.
• MAY assign IRIs or blank node identifiers to any mapping component in order to enable re-use of mapping components within the mapping graph. For example, an IRI that represents a subject map may be used as the subject map of multiple triples maps; and may even be used as an object map of another triples map if it has the right properties.

The R2RML vocabulary also includes the following R2RML classes, which represent various :

• rr:TriplesMap is the class of triples maps.
• rr:LogicalTable is the class of logical tables. It has two subclasses:
  • rr:R2RMLView is the class of R2RML views.
  • rr:BaseTableOrView is the class of SQL base tables or views.
• rr:SubjectMap is the class of subject maps.
• rr:PredicateMap is the class of predicate maps.
• rr:ObjectMap is the class of object maps.
• rr:GraphMap is the class of graph maps.
• rr:PredicateObjectMap is the class of predicate-object maps.
• rr:RefObjectMap is the class of referencing object maps.
• rr:Join is the class of join conditions.

The members of these classes are collectively called mapping constructs. Usingcomponents.

Many of these classes differ only in capitalization from properties in the R2RML vocabulary.

Explicit typing of the resources in a mapping graph with R2RML classes is OPTIONAL. Their presence in a graph has no effect on the behaviour of an R2RML processor. The mapping graph. The applicable class ofcomponent represented by any given resource in a resource can always be inferred from its properties. rr:TriplesMapmapping graph is the class of triples maps. rr:LogicalTable is the class of logical tables. rr:SubjectMap is the class of subject maps. rr:PredicateMap is the class of predicate maps. rr:ObjectMap is the class of object maps. rr:GraphMap is the class of graph maps. rr:PredicateObjectMap is the class of predicate-object maps. rr:RefObjectMap is the class of referencing object maps. rr:Join is the class of join conditions. Many of these classes differ only in capitalization from properties in the R2RML vocabulary.defined by the presence or absence of certain properties, as defined throughout this specification.

4.2 RDF-based Turtle Syntax; Media Type

An R2RML mapping document is any document written in the Turtle [TURTLE] RDF syntax that encodes an R2RML mapping graph.

The media type for R2RML mapping documents is the same as for Turtle documents in general: text/turtle. The content encoding of Turtle content is always UTF-8 and the charset parameter on the media type SHOULD always be used: text/turtle;charset=utf-8. The preferred file extension is .ttl. SHOULD be used.

A conforming R2RML processor MUST accept R2RML mapping documents in Turtle syntax. It MAY accept R2RML mapping graphs encoded in other RDF syntaxes.

4.3 Data Errors

A data error is a condition of the data in the input database that would lead to the generation of an invalid RDF term, such as. The following conditions give rise to data errors:

1. A term map with term type rr:IRI results in the generation of an invalid IRI or.
2. A term map that has a validatable RDF datatype as its specified datatype produces an ill-typed literal. literal.

When providing access to the output dataset, an R2RML processor MUST abort any operation that requires inspecting or returning an RDF term whose generation would give rise to a data error, and report an error to the agent invoking the operation. A conforming R2RML processor MAY, however, allow other operations that do not require inspecting or returning these RDF terms, and thus MAY provide partial access to an output dataset that contains data errors. Nevertheless, an R2RML processor SHOULD report data errors as early as possible.

The presence of data errors does not make an R2RML mapping non-conforming.

5 Defining Logical Tables

Figure 2: The properties of logical tables

A logical table is a possibly virtual database tabletabular SQL query result that is to be mapped to RDF triples. A logical table is either

• a SQL base table or view, or
• aan R2RML view.

Every logical table has an effective SQL query that, if executed over the SQL connection, produces as its result the contents of the logical table.

A logical table row is a row in a logical table.

A column name is the name of a column of a logical table. A column name MUST be a valid SQL identifier. Column names do not include any qualifying table, view or schema names.

A SQL identifier is the name of a SQL object, such as a column, table, view, schema, or catalog. A SQL identifier MUST match the <identifier> production in [SQL2]. When comparing identifiers for equality, the comparison rules of [SQL2] MUST be used.

[] rr:column "deptno".
[] rr:column "DEPTNO".
[] rr:parent "DEPT_NO".
[] rr:child "dept_no".
[] rr:template "http://data.example.com/department/{Department Number}".
    

    Note that Turtle string syntax requires escaping of double quotes with
    a backslash, so the identifier "Identifier ""with quotes""" can be
    used as (part of) value for the various relevant R2RML properties as follows:
    rr:column "\"dept_no\"".
[] rr:column "Identifier \"\"with quotes\"\""."\"Department Number\"".
[] rr:template "http://data.example.com/department/{Identifierrr:column "\"Identifier \"\"with quotes\"\"}".
quotes\"\"\"".

5.1 Base Tables and SQL Views (rr:tableName)

A SQL base table or view is a logical table containing SQL data from a base table or view in the input database. A SQL base tablestable or viewsview is represented by a resource that has exactly one rr:tableName property.

The value of rr:tableName specifies the table or view name of the base table or view. Its value MUST be a valid schema-qualified name that names an existing base table or view in the input database.

A schema-qualified name is a sequence of one, two or three valid SQL identifiers, separated by the dot character (“.”). The three identifiers name, respectively, a catalog, a schema, and a table or view. If no catalog or schema areis specified, then the default catalog and default schema of the SQL connection are assumed.

The effective SQL query of a SQL base table or view is:

SELECT * FROM {table}

with {table} replaced with the table or view name.

The following example shows a logical table specified using a schema-qualified table name.

[] rr:tableName "SCOTT.DEPT".

The following example shows a logical table specified using an unqualified table name. The SQL connection's default schema will be used.

[] rr:tableName "DEPT".

5.2 R2RML Views (rr:sqlQuery, rr:sqlVersion)

An R2RML view is a logical table whose contents are the result of executing a SQL query against the input database. It is represented by a resource that has exactly one rr:sqlQuery property, whose value MUST beis a literal with a lexical form that is a valid SQL query.

R2RML mappings sometimes require data transformation, computation, or filtering before generating triples from the database. This can be achieved by defining a SQL view in the input database and referring to it with rr:tableName. However, this approach may not be practical for lack of database privileges or other reasons. R2RML views achieve the same effect without requiring changes to the input database.

Note that unlike “real” SQL views, an R2RML view can not be used as an input table in further SQL queries.

A SQL query is a SELECT query in the SQL language that can be executed over the input database. The value of rr:sqlQuerystring MUST conform to the production <direct select statement: multiple rows> in [SQL2] with an OPTIONAL trailing semicolon character and OPTIONAL surrounding white space (excluding comments) as defined in [TURTLE]. It MUST be a valid SQL query if executedto execute over the SQL connection. It The result of the query execution MUST NOT have duplicate column names . Any columns in the SELECT list derived by projecting an expression MUST be named.

Database objects referenced in the SQL query MAY be qualified with a catalog or unnamed derived columns in the SELECT list.schema name. For any database objects referenced without an explicit catalog name or schema name, the default catalog and default schema of the SQL connection are used.assumed.

For example, the following SELECT query is not a valid R2RML SQL query because it contains an unnamed column derived from a COUNT expression:

SELECT DEPTNO, COUNT(EMPNO) FROM EMP GROUP BY DEPTNO;

As a further example, the following SELECT query is not a valid R2RML SQL query because the result contains a duplicate column name DEPTNO:

SELECT EMP.DEPTNO, 1 AS DEPTNO FROM EMP;

An R2RML view MAY have one or more SQL version identifiers. They MUST be valid IRIs and are represented as values of the rr:sqlVersion property. The following SQL version identifier indicates that the SQL query conforms to Core SQL 2008:

http://www.w3.org/ns/r2rml#SQL2008

The absence of a SQL version identifier indicates that no claim to Core SQL 2008 conformance is made.

No further identifiers besides rr:SQL2008 are defined in this specification. The RDB2RDF Working Group intends to maintain a non-normative list of identifiers for other SQL versions [SQLIRIS].

The effective SQL query of an R2RML view is the value of its rr:sqlQuery property.

The following example shows a logical table specified as an R2RML view conforming to Core SQL 2008.

[] rr:sqlQuery """
        Select ('Department' || DEPTNO) AS DEPTID
             , DEPTNO
             , DNAME
             , LOC
          from SCOTT.DEPT
    """;
    rr:sqlVersion rr:SQL2008.

6 Mapping Logical Tables to RDF with Triples Maps

Figure 3: The properties of triples maps

A triples map specifies a rule for translating each row of a logical table to zero or more RDF triples.

The RDF triples generated from one row in the logical table all share the same subject.

A triples map is represented by a resource that references the following other resources:

• It MUST have exactly one logical table, which specifies a SQL query result to be mapped to triples. The logical table may be specified in one of two ways:
  1. The triples map MAY have a rr:logicalTable property, whose value MUST be the logical table.
  2. The resource representing the triples map MAY itself also represent the logical table (that is, have the required properties such as rr:tableName or rr:sqlQuery).
• It MUST have exactly one subject map that specifies how to generate the subjectsa subject for each row of the logical table. It may be specified in two ways:
  1. using the rr:subjectMap property, whose value MUST be the subject map, or
  2. using the constant shortcut property rr:subject.
• It MAY have zero or more rr:predicateObjectMap properties, whose values MUST be predicate-object maps. Each specifies a predicate-object pair that, together with the subjectssubject generated by the subject map, may form one RDF triple for each row.

The referenced columns of all term maps of a triples map (subject map, predicate maps, object maps, graph maps) MUST be column names that exist in the term map's logical table. Furthermore, the columns carrying these names in the logical table MUST be of a supported SQL datatype for which conversion to string is defined. Conversion to string is undefined in SQL 2008 for row types, array types, user-defined datatypes that do not have a user-defined string CAST, and a few other exotic types..

The following example shows a triples map including its logical table, subject map, and two predicate-object maps.

[]
    rr:logicalTable [ rr:tableName "DEPT" ];
    rr:subjectMap [ rr:template "http://data.example.com/department/{DEPTNO}" ];
    rr:predicateObjectMap [
        rr:predicate ex:name;
        rr:objectMap [ rr:column "DNAME" ];
    ].
    rr:predicateObjectMap [
        rr:predicate ex:location;
        rr:objectMap [ rr:column "LOC" ];
    ].

The logical table may also be specified directly on the same resource, without introducing an intermediate resource:

[]
    rr:tableName "DEPT";
    rr:subjectMap [ rr:template "http://data.example.com/department/{DEPTNO}" ];
    # …
    .

6.1 Creating Resources with Subject Maps

A subject map is a term map. It specifies a rule for generating the subjects of the RDF triples generated by a triples map.

6.2 Typing Resources (rr:class)

A subject map MAY have one or more class IRIs. They are represented by the rr:class property. The values of the rr:class property MUST be IRIs. For each RDF term generated by the subject map, RDF triples with predicate rdf:type and the class IRI as object will be generated.

This propertyMappings where the class IRI is merelynot constant, but needs to be computed based on the contents of the database, can be achieved by defining a shortcut for specifying an rr:predicateObjectMap predicate-object map with predicate rdf:type and the rr:class IRI as a constant object. Mappings where the class IRI is not constant, but needs to be computed based on the contents of the database, can be achieved by defining such a rr:predicateObjectMap with a non-constant object. object map.

In the following example, the generated subject will be asserted as an instance of the ex:Employee class.

[] rr:template "http://data.example.com/employee/{EMPNO}"; 
   rr:class ex:Employee.

Using the example EMP table, the following RDF triple will be generated:

<http://data.example.com/emp/7369> rdf:type ex:Employee.

6.3 Creating Properties and Values with Predicate-Object Maps

A predicate-object map is a function that creates a predicate-object pairs from pair for each logical table rowsrow of a logical table. It is used in conjunction with a subject map to generate RDF triples in a triples map.

A predicate-object map is represented by a resource that references the following other resources:

• Exactly one predicate map. It may be specified in two ways:
  1. using the rr:predicateMap property, whose value MUST be a predicate map, or
  2. using the constant shortcut property rr:predicate.
• Exactly one object map. It may be specified in one of two ways:
  1. using the rr:objectMap property, whose value MUST be either an object map, or a referencing object map.
  2. using the constant shortcut property rr:object.

A predicate map is a term map.

An object map is a term map.

7 Creating RDF Terms with Term Maps

Figure 4: The properties of term maps

An RDF term is either an IRI, or a blank node, or a literal.

A term map is a function that generates an RDF term from a logical table row. The result of that function is known as the term map's generated RDF term.

Term maps are used to generate the subjects, predicates and objects of the RDF triples that are generated by a triples map. Consequently, there are several kinds of term maps, depending on where in the mapping they occur: subject maps, predicate maps, object maps and graph maps.

A term map MUST be exactly one of the following:

• a constant-valued term map,
• a column-valued term map,
• a template-valued term map.

The referenced columns of a term map are the set of column names referenced in the term map and depend on the type of term map.

7.1 Constant RDF Terms (rr:constant)

A constant-valued term map is a term map that ignores the logical table row and always generates the same RDF term. A constant-valued term map is represented by a resource that has exactly one rr:constant property.

The constant value of a constant-valued term map is the RDF term that is the value of its rr:constant property.

If the constant-valued term map is a subject map, predicate map or graph map, then its constant value MUST be an IRI.

If the constant-valued term map is an object map, then its constant value MUST be an IRI or literal.

The referenced columns of a constant-valued term map is the empty set.

Constant-valued term maps can be expressed more concisely using the constant shortcut properties rr:subject, rr:predicate, rr:object and rr:graph. OccurrancesOccurrences of these properties MUST be treated exactly as if the following triples were present in the mapping graph instead:

The following example shows a predicate-object map that uses a constant-valued term map both for its predicate and for its object.

[] rr:predicateMap [ rr:constant rdf:type ];
   rr:objectMap [ rr:constant ex:Employee ].

If added to a triples map, this predicate-object map would add the following triple to all resources ?x generated by the triples map:

?x rdf:type ex:Employee.

The following example uses constant shortcut properties and is equivalent to the example above:

[] rr:predicate rdf:type;
   rr:object ex:Employee.

7.2 From a Column (rr:column)

A column-valued term map is a term map that is represented by a resource that has exactly one rr:column property.

The value of the rr:column property MUST be a valid column name. The column value of the term map is the data value of that column in a given logical table row.

The referenced columns of a column-valued term map is the singleton set containing the value of the term map's rr:column. property.

The following example defines an object map that generates literals from the DNAME column of some logical table.

[] rr:objectMap [ rr:column "DNAME" ].

Using the sample row from the DEPT table as a logical table row, the column value of the object map would be “APPSERVER”.

7.3 From a Template (rr:template)

A template-valued term map is a term map that is represented by a resource that has exactly one rr:template property. The value of the rr:template property MUST be a valid string template.

A string template is a format string that can be used to build strings from multiple components. It can reference column names by enclosing them in curly braces. braces (“{” and “}”). The following syntax rules apply to valid string templates:

• Pairs of unescaped curly braces MUST enclose valid column names.
• Curly braces that do not enclose column names MUST be escaped by a backslash character. character (“\”). This includesalso applies to curly braces within column names.
• Backslash characters (“\”) MUST be escaped by doublingpreceding them with another backslash character. character, yielding “\\”. This includes also applies to backslashes within column names.
• If a template contains multiple pairs of unescaped curly braces, then adjacent pairsany pair SHOULD be separated from the next one by a character or string that does not occur anywhere in the data values of either column.

The template value of the term map for a given logical table row is determined as follows:

1. Let result be the template string
2. For each pair of unescaped curly braces in result:
   1. Let value be the data value of the column whose name is enclosed in the curly braces
   2. If value is NULL, then return NULL
   3. Apply conversion to string toLet value be the natural RDF lexical form corresponding to value
   4. If the term type is rr:IRI, then replace the pair of curly braces with an IRI-safe version of value; otherwise, replace the pair of curly braces with value
3. Return result

The IRI-safe version of a string is obtained by applying the following transformation to any character that is not in the iunreserved production in [RFC3987]:

1. Convert the character to a sequence of one or more octets using UTF-8 [RFC3629]
2. Percent-encode each octet [RFC3986]

R2RML always performs percent-encoding when IRIs are generated from string templates. If IRIs need to be generated without percent-encoding, then rr:column should be used instead of rr:template, with an R2RML view that performs the string concatenation.

The referenced columns of a template-valued term map is the set of column names enclosed in unescaped curly braces in the template string.

The following example defines a subject map that generates IRIs from the DEPTNO column of a logical table.

[] rr:subjectMap [ rr:template "http://data.example.com/department/{DEPTNO}" ].

Using the sample row from the DEPT table as a logical table row, the template value of the subject map would be:

http://data.example.com/department/10

The following example shows how an IRI-safe template value is created:

[] rr:subjectMap [ rr:template "http://data.example.com/site/{LOC}" ].

Using the sample row from the DEPT table as a logical table row, the template value of the subject map would be:

http://data.example.com/site/NEW%20YORK

The space character is not in the iunreserved set, and therefore percent-encoding is applied to the character, yielding “%20”.

The following example shows the use of backslash escapes in string templates. The template will generate a fancy title such as

{{{ \o/ Hello World! \o/ }}}

from a string “Hello World!” in the TITLE column. By default, rr:template generates IRIs. Since the intention here is to create a literal instead, the term type has to be set.

[] rr:objectMap [ 
    rr:template "\\{\\{\\{ \\\\o/ {TITLE} \\}\\}\\}" \\\\o/ \\}\\}\\}";
    rr:termType rr:Literal;
].

Note that because backslashes need to be escaped by a second backslash in the Turtle syntax [TURTLE], a double backslash is needed to escape each curly brace.brace, and to get one literal backslash in the output one needs to write four backslashes in the template.

7.4 IRIs, Literal, Blank Nodes (rr:termType)

The term type of a column-valued term map or template-valued term map determines the kind of generated RDF term (IRIs, blank nodes or literals).

If the term map has an optional rr:termType property, then its term type is the value of that property. The value MUST be an IRI and MUST be one of the following options:

• If the term map is a subject map: rr:IRI or rr:BlankNode
• If the term map is a predicate map: rr:IRI
• If the term map is an object map: rr:IRI, rr:BlankNode, or rr:Literal
• If the term map is a graph map: rr:IRI

If the term map does not have a rr:termType property, then its term type is:

• If the term maprr:Literal, if it is an object map and at least one of the following conditions is true:
  • It is a column-based term map: rr:Literal.
  • Otherwise: It has a rr:language property (and thus a specified language tag).
  • It has a rr:datatype property (and thus a specified datatype).
• rr:IRI, otherwise.

Term maps with term type rr:IRI cause data errors if the value is not a valid IRI (see generated RDF term for details). Data values from the input database may require percent-encoding before they can be used in IRIs. Template-valued term maps are a convenient way of percent-encoding data values.

7.5 Language Tags (rr:language)

A term map with a term type of rr:Literal MAY have a specified language tag. It is represented by the rr:language property on a term map. If present, its value MUST be a valid language tag.

A specified language tag causes generated literals to be language-tagged plain literals. In the following example, plain literals with language tag “en-us” (U.S. English) will be generated for the data values in the DNAME column.

[] rr:objectMap [ rr:column "DNAME"; rr:language "en-us" ].

7.6 Typed Literals (rr:datatype)

A typeabledatatypeable term map is a term map with a term type of rr:Literal that does not have a specified langaugelanguage tag.

Typeable term maps may generate typed literals. The datatype of these literals can be automatically determined based on the SQL datatype of the underlying logical table column (producing a natural RDF literal), or it can be explicitly specifiedoverridden using rr:datatype, or automatically determined based on the SQL datatype of the underlying logical table column. (producing a datatype-override RDF literal).

A typeabledatatypeable term map MAY have a rr:datatype property. Its value MUST be an IRI. This IRI is the specified datatype of the term map.

A term map MUST NOT have more than one rr:datatype value.

A term map that is not a typeabledatatypeable term map MUST NOT have an rr:datatype property.

A typeable term map has an The implicit SQL datatype and an implicit transform. They are determined as follows: If theof a datatypeable term map is CHARACTER VARYING if the term map is a column-valuedtemplate-valued term map, then the implicit; otherwise, it is the SQL datatype is the corresponding RDF datatype of the respective column in the the logical table row, and the implicit transform is the RDF transformation of the column. Otherwise, the term map must be a template-valued term map and its implicit datatype is empty, and its implicit transform is the identity transform. A datatype override is in effect on a typeable term map if it has a specified datatype, and the specified datatype is different from its implicit datatype.

See generated RDF term for further details.details on generating literals from term maps.

R2RML does not allow generatingOne cannot explicitly state that a plain literalsliteral without language tag should be generated. They are the default for string columns. To generate one from a non-string columns. One column, a template-valued term map with a template such as "{MY_COLUMN}" and a term type of rr:Literal can use a derived column that uses a SQL CAST expression instead.be used.

The following example shows an object map that overrides the default datatype of the logical table with an explicitly specified xsd:positiveInteger type. Whatever A datatype-override RDF literal of that datatype will be generated from whatever is in the EMPNO column will be subjected to conversion to string, and turned into a literal of that type.column.

[] rr:objectMap [ rr:column "EMPNO"; rr:datatype xsd:positiveInteger ].

7.7 Inverse Expressions (rr:inverseExpression)

An inverse expression is a string template associated with a column-valued term map or template-value term map. It is represented by the value of the rr:inverseExpression property. This property is OPTIONAL and there MUST NOT be more than one for a term map.

Inverse expressions are useful for optimizing term maps that reference derived columns in R2RML views. An inverse expression specifies an expression that allows “reversing” of a generated RDF term and the construction of a SQL query that efficiently retrieves the logical table row from which the term was generated. In particular, it allows the use of indexes on the underlying relational tables.

Every pair of unescaped curly braces in the inverse expression is a column reference in an inverse expression. The string between the braces MUST be a valid column name.

An inverse expression MUST satisfy the following condition:

• Let t be the logical table associated with this term map
• Every column reference in the inverse expression MUST be an existing column in t
• Given a logical table row r in t, let instantiation(r) be the result of replacing each column reference c in the inverse expression with:
  • the quoted and escaped data value of column c in r, if c is a referenced column in the term map
  • the column name of column c, otherwise
• Given a logical table row r in t, let same-term(r) be the set of logical table rows in t that are the result of executing the following SQL query over the SQL connection:

  SELECT * FROM ({query}) AS tmp WHERE {expr}

  where {query} is the effective SQL query of t, and {expr} is instantiation(r)
• For every logical table row r in t whose generated RDF term g is not NULL, same-term(r) MUST be exactly the set of logical table rows in t whose generated RDF term is also g.

For example, for the DEPTID column in the logical table used for mapping the DEPT table in this example mapping, an inverse expression could be defined as follows:

[] rr:column "DEPTID";
   rr:inverseExpression "{DEPTNO} = substr({DEPTID},length('Department')+1)";

This facilitates the use of an existing index on the DEPTNO column of the DEPT table.

A quoted and escaped data value is any SQL string that matches the <literal> or <null specification> productions of [SQL2]. This string can be used in a SQL literal that can be used inquery to specify a SQL query, such as:data value. Examples:

• 27
• 'foo'
• 'foo''bar'
• TRUE
• DATE 2011-11-11
• NULL

8 Foreign Key Relationships among Logical Tables (rr:parentTriplesMap, rr:joinCondition, rr:child and rr:parent)

Figure 5: The properties of referencing object maps

A referencing object map allows using the subjects of another triples map as the objects generated by a predicate-object map. Since both triples maps may be based on different logical tables, this may require a join between the logical tables. This is not restricted to 1:1 joins.

A referencing object map is represented by a resource that:

• has exactly one rr:parentTriplesMap property, whose value MUST be a triples map, known as the referencing object map's parent triples map.
• MAY have one or more rr:joinCondition properties, whose values MUST be join conditions.

A join condition is represented by a resource that has exactly two properties:

• rr:child, whose value is known as the join condition's child column and MUST be a column name that exists in the logical table of the triples map that contains the referencing object map
• rr:parent, whose value is known as the join condition's parent column and MUST be a column name that exists in the logical table of the referencing object map's parent triples map.

The child query of a referencing object map is the effective SQL query of the logical table containing the referencing object map.

The parent query of a referencing object map is the effective SQL query of the logical table of its parent triples map.

If the child query and parent query of a referencing object map are not identical, then the referencing object map MUST have at least one join condition.

The joint SQL query of a referencing object map is:

• If the referencing object map has no join condition:

  SELECT * FROM ({child-query}) AS tmp

• If the referencing object map has at least one join condition:

  SELECT * FROM ({child-query}) AS child,
                ({parent-query}) AS parent
          WHERE child.{child-column1}=parent.{parent-column1}
            AND child.{child-column2}=parent.{parent-column2}
            AND ...

  where {child-query} is the referencing object map's child query, {parent-query} is its parent query, {child-column1} and {parent-column1} are the child column and parent column of its first join condition, and so on. The order of the join conditions is chosen arbitrarily.

The joint SQL query is used when generating RDF triples from referencing object maps.

The following example shows a referencing object map as part of a predicate-object map:

[] rr:predicateObjectMap [
    rr:predicate ex:department;
    rr:refObjectMaprr:objectMap [
        rr:parentTriplesMap <#TriplesMap2>;
        rr:joinCondition [
            rr:child "DEPTNO";
            rr:parent "DEPTNO";
        ];
    ];
].

If the logical table of the surrounding triples map is EMP, and the logical table of <#TriplesMap2> is DEPT, this would result in a join between these two tables with the condition

EMP.DEPTNO = DEPT.DEPTNO

and the objects of the triples would be generated using the subject map of <#TriplesMap2>.

Given the two example tables, and subject maps as defined in the example mapping, this would result in a triple:

<http://data.example.com/employee/7369> ex:department <http://data.example.com/department/10>.

The following example shows a referencing object map that does not have a join condition. It creates two kinds of resources from the DEPT table: departments and sites.

<#DeptTriplesMap>
    rr:tableName "DEPT";
    rr:subjectMap [
        rr:template "department/{DEPTNO}";
        rr:class ex:Department;
    ];
    rr:predicateObjectMap [
        rr:predicate ex:location;
        rr:objectMap [ rr:parentTriplesMap <#SiteTriplesMap> ];
    ].

<#SiteTriplesMap>
    rr:tableName "DEPT";
    rr:subjectMap [
        rr:template "site/{LOC}";
        rr:class ex:Site;
    ];
    rr:predicateObjectMap [
        rr:predicate ex:siteName;
        rr:objectMap [ ex:column "LOC" ];
    ].

An ex:Site resource is created for each distinct value in the LOC column, using the <#SiteTriplesMap>. Departments and sites are linked by ex:location triples, and the objects of these triples are specified using a referencing object map that references the sites triples map. No join condition is needed as both triples maps use the same logical table (the base table DEPT). Given the example table, this mapping would result in four triples (assuming an appropriate base IRI):

<http://data.example.com/department/10> rdf:type ex:Department.
<http://data.example.com/department/10> ex:location <http://data.example.com/site/NEW%20YORK>.
<http://data.example.com/site/NEW%20YORK> rdf:type ex:Site.
<http://data.example.com/site/NEW%20YORK> ex:siteName "NEW YORK".

9 Assigning Triples to Named Graphs

Figure 6: The properties of graph maps

Each triple generated from an R2RML mapping is placed into one or more graphs of the output dataset. Possible target graphs are the unnamed default graph, and the IRI-named named graphs.

Any subject map or predicate-object map MAY have one or more associated graph maps. They are specified in one of two ways:

1. using the rr:graphMap property, whose value MUST be a graph map,
2. using the constant shortcut property rr:graph.

Graph maps are themselves term maps. When RDF triples are generated, the set of target graphs is determined by taking into account any graph maps associated with the subject map or predicate-object map.

If a graph map generates the special IRI rr:defaultGraph, then the target graph is the default graph of the output dataset.

In the following subject map example, all generated RDF triples will be stored in the named graph ex:DepartmentGraph.

[] rr:subjectMap [
    rr:template "http://data.example.com/department/{DEPTNO}";
    rr:graphMap [ rr:graphrr:constant ex:DepartmentGraph ];
].

This is equivalent to the following example, which uses a constant shortcut property:

[] rr:subjectMap [
    rr:template "http://data.example.com/department/{DEPTNO}";
    rr:graph ex:DepartmentGraph;
].

In the following example, RDF triples are placed into named graphs according to the job title of employees:

[] rr:subjectMap [
    rr:template "http://data.example.com/employee/{EMPNO}";
    rr:graphMap [ rr:template "http://data.example.com/jobgraph/{JOB}" ];
].

The triples generated from the EMP table would be placed in the named graph with the following IRI:

<http://data.example.com/jobgraph/CLERK>

9.1 Scope of Blank Nodes

Blank nodes in the output dataset are scoped to a single RDF graph. If the same blank node identifier occurs in multiple RDF triples that are in the same graph, then the triples will share the same single blank node. If, however, the same blank node identifier occurs in multiple graphs, then a distinct blank node is created for each graph. An R2RML-generated blank node can never be shared by two triples in two different graphs.

This implies that triples generated from a single logical table row will have different subjects if the subjects are blank nodes and the triples are placed into different graphs.

10 Datatype Conversions

This section defines the following mappings from SQL data values to RDF literals:

10.1 Introduction (Informative)

This section defines various conversion rules applicable The following mappings from SQL data values are defined:

1. The natural RDF literal is a mapping to data values. typed literals. It is used in R2RML and in the Direct Mapping of Relational Data to RDF [DM] as the default mapping when literals are created. It maps SQL datatypes to corresponding XML Schema datatypes [XMLSCHEMA2] and loosely follows ISO/IEC 9075-14:2008 [SQL14].
2. The rulesnatural RDF lexical form is similar, but produces only the lexical form of the typed literal and recommends that implementations perform XSD canonicalization. It is used in R2RML when non-string columns are invokedused in various places throughout this specification,a string context, for example when a TIMESTAMP is used in particular around an IRI template.
3. The canonical RDF lexical form is again similar, but requires XSD canonicalization. It is used in the Direct Mapping when IRIs are generated.
4. The datatype-override RDF literal is a mapping that constructs typed literals by using the natural RDF lexical form and applying a specified datatype IRI. The mapping author is responsible for ensuring that the generated lexical form is valid for the datatype. It is used in R2RML when the target datatype of a literal-generating term map is overridden using rr:datatype and.

The mappings cover all predefined SQL 2008 datatypes except INTERVAL. For unsupported vendor-specific types, they fall back on a simple cast to string. However, the natural mappings may be extended with custom handling for such types.

The mappings are referenced in hte the R2RML term generation rules.

A An informative summary of XSD lexical forms is provided to aid implementers.

10.2 Natural Mapping of SQL Values

The natural RDF literal corresponding to a SQL data value is the result of applying the following steps:

1. Let dt be the SQL datatype of the SQL data value.
2. If dt is a character string type, then the result is a plain literal without language tag whose lexical form is the SQL data value.
3. Otherwise, if dt is listed in the table below: The result is a typed literal of a supported whose datatype IRI is the IRI indicated in the RDF datatype is ill-typed if its column in the same row as dt. The lexical form may be any lexical form that represents the same value as the SQL data value, according to the definition of the RDF datatype. If there are multiple lexical forms available that represent the same value (e.g., 1, +1, 1.0 and 1.0E0), then the choice is implementation-dependent. However, the choice MUST be made so that given a target RDF datatype and value, the same lexical form is chosen consistently (e.g., INTEGER 5 and BIGINT 5 must be mapped to the same lexical form, as both are mapped to the RDF datatype xsd:integer and are equal values; mapping one to 5 and the other to +5 would be in error). The canonical lexical representation [XMLSCHEMA2] MAY be chosen. (See also: Summary of XSD Lexical Forms)
4. Otherwise, the result is a plain literal without language tag whose lexical form is the SQL data value cast to string.

R2RML processor implementations that handle vendor-specific types or user-defined types beyond the standard SQL 2008 datatypes are expected to do so by behaving as if the table above contained additional rows that associate the SQL datatypes with appropriate RDF-compatible datatypes (e.g., the XML Schema built-in types [XMLSCHEMA2]), and appropriate lexical transformations where required.

The translation of INTERVAL is left undefined due to the complexity of the translation. [SQL14] describes a translation of INTERVAL to xdt:yearMonthDuration and xdt:dayTimeDuration.

In [SQL2], the precision of many SQL datatypes is not fixed, but left implementation-defined. Therefore, the mapping to XML Schema datatypes must rely on arbitrary-precision types such as xsd:decimal, xsd:integer and xsd:dateTime. Implementers of the mapping may wish to set upper limits for the supported precision of these XSD types. The XML Schema specification allows such partial implementations of infinite datatypes [XMLSCHEMA2], and defines specific minimum requirements.

The natural RDF datatype corresponding to a SQL datatype is the value of the RDF datatype column in the lexical space of the RDF row corresponding to the SQL datatype identified by its datatype IRI in the table above.

For example, "X"^^xsd:booleanThe natural RDF lexical form corresponding to a SQL data value is ill-typed because “X” is not in the the lexical space of xsd:booleanform of its corresponding natural RDF literal, with the additional constraint that the canonical lexical representation [XMLSCHEMA2].] SHOULD be chosen.

The canonical RDF lexical form corresponding to a SQL data value is the lexical form of its corresponding natural RDF literal, with the additional constraint that the canonical lexical representation [XMLSCHEMA2] MUST be chosen.

Cast to string is an implementation-dependent function that maps SQL data values to equivalent Unicode strings. It is undefined for the following kinds of SQL datatypes: collection types, row types, user-defined types without a user-defined string CAST, reference types whose referenced type does not have a user-defined string CAST, binary types, and OPTIONAL further implementation-defined types.

Cast to string is a fallback that handles vendor-specific and user-defined datatypes not supported by the R2RML processor. It can be implemented in a number of ways, including explicit SQL casts (“CAST(value AS VARCHAR(n))”, where n is an arbitrary large integer), implicit SQL casts (concatenation with the empty string), or by employing a database access API that presents return values as strings.

10.3 Datatype-override Mapping of SQL Values

The datatype-override RDF literal corresponding to a SQL data value v and a datatype IRI dt, is a typed literal whose lexical form is the natural RDF lexical form corresponding to v, and whose datatype IRI is dt. If the typed literal is ill-typed, then a data error is raised.

A typed literal is ill-typed ofin R2RML if its datatype IRI denotes a SQL validatable RDF datatype and its lexical form is givennot in the table below, or empty if the SQL lexical space of the RDF datatype does not occur in the table. identified by its datatype IRI. (See also: Summary of XSD Lexical Forms)

The RDF transformation of a SQL datatype is a transformation rule given in the table below, or conversion to string if the SQL datatype does not occur in the table. The supportedset of validatable RDF datatypes are theincludes all datatypes for which an implementation can detect ill-typed literals. This set MUSTin the RDF datatype include all datatypes mentioned in the column of the table below in the column “Corresponding RDF datatype”, according to their definitionsof natural datatype mappings, as defined in [XMLSCHEMA2]. This set MAY include arbitrary further implementation-defined additional RDF datatypes.

For example, "X"^^xsd:boolean is ill-typed because xsd:boolean is a validatable RDF datatype in R2RML, and “X” is not in the lexical space of xsd:boolean [XMLSCHEMA2].

10.4 Non-String Columns in String Contexts

The same non-character-string SQL datatype Correspondingdata value can typically be represented in multiple different string forms. For example, the DOUBLE value 1 can be represented as 1, +1, 1.0 and 1.0E0. This can cause interoperability issues when such values are used in string contexts, for example when using them to generate IRIs. Two IRIs that are character-for-character equivalent, except one contains 1 where the other contains 1.0, will not “link up” in an RDF datatype Transformation BINARY, BINARY VARYING, BINARY LARGE OBJECT xsd:base64Binary base64 encoding NUMERIC, DECIMAL xsd:decimal conversion to string SMALLINT, INTEGER, BIGINT xsd:integer conversion to string FLOAT, REAL, DOUBLE PRECISION xsd:double conversion to string BOOLEAN xsd:boolean conversion to boolean DATE xsd:date conversion to datetime TIME xsd:time conversion to datetime TIMESTAMP xsd:dateTime conversion to datetime INTERVAL undefined undefined Any types not appearing in the table, including all character string types and vendor-specific types, will default to producing RDF plain literals by using conversion to string.graph – they are two different nodes.

To reduce portability issues arising from such conversions, this specification recommends that implementations convert non-string data values to a canonical form (see natural RDF lexical form). However, this is not a strict requirement. Therefore, when portability between R2RML processor implementations is a concern, mapping authors SHOULD NOT use non-character-string columns in contexts where strings are expected to augment the table with additional rows for mapping vendor-specific datatypes to appropriate XSD types. The translation of INTERVAL is left undefined due to the complexity of the translation. [SQL14] describes a translation of INTERVAL to xdt:yearMonthDuration and xdt:dayTimeDuration.produced:

• with rr:column when IRIs or blank nodes are produced,
• with rr:column when rr:language or an rr:datatype other than the natural RDF datatype is used, and
• with rr:template.

In these contexts, if portability is to be maximized, then mapping authors SHOULD use an R2RML view instead and explicitly convert the non-string column to a string column using an SQL data values after conversion to string, and a typed literal of the corresponding RDF datatype, derived by applying the SQL datatype's RDF transformation:expression.

Note that this is not a problem when natural RDF literals are generated from such columns, because the resulting literal has a corresponding non-string XSD datatype, and equivalences between different lexical forms within these datatype Conversion to string example Typed literal example DECIMAL 2000000000005.9 "2000000000005.9"^^xsd:decimal DECIMAL 2000000000000 "2000000000000"^^xsd:decimal INTEGER -1 "-1"^^xsd:integer REAL 5.0E-1 "5.0E-1"^^xsd:double REAL 0E0 "0E0"^^xsd:double DATE DATE 2011-08-23 "2011-08-23"^^xsd:date TIME TIME 22:17:00 "22:17:00"^^xsd:time TIME TIME 22:17:00.0000 "22:17:00.0000"^^xsd:time TIME TIME 22:17:00+01:00 "22:17:00+01:00"^^xsd:time TIMESTAMP TIMESTAMP 2011-08-23 22:17:00 "2011-08-23T22:17:00"^^xsd:dateTime are well-defined.

10.5 Summary of XSD Lexical Forms (Informative)

ConversionThe natural mappings make reference to string various XSD datatypes and require that SQL data values be converted to strings that are appropriate as lexical forms for these datatypes. This subsection gives examples of these lexical forms in order to aid implementers of the mappings. This subsection is the process of transforming a SQL data value to a Unicode string. Its result MUSTnon-normative; the normative definitions of the lexical spaces as well as the canonical lexical mappings are found in W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes be the same as evaluating the following SQL expression, as defined in [SQL2XMLSCHEMA2]:].

where valueA general approach that may be used for implementing the natural mappings is the quoted and escaped form of the SQL data value, and max is the implementation-dependent maximum length of a variable-length character string. An informative summary of the rules for casting standard SQL 2008 datatypes to string follows. The right column of the table contains a regular expression that is matched by the string-converted form of all SQL data values of the types in the left column: TypePattern DECIMAL, NUMERIC-?(\.\d+|\d+(\.\d+)?) SMALLINT, INTEGER, BIGINT-?\d+ FLOAT, REAL, DOUBLE PRECISION0E0|-?[1-9]\.\d+ DATE\d\d\d\d-\d\d-\d\d TIME\d\d:\d\d:\d\d(.\d+)?([+-]\d\d:\d\d)? TIMESTAMP\d\d\d\d-\d\d-\d\d \d\d:\d\d:\d\d(.\d+)?([+-]\d\d:\d\d)? BOOLEANTRUE|FALSE The result of conversion to string is always the shortest possible string that, if interpreted as a SQL literal of the original SQL datatype, has the same value as the original SQL data value. For example, converting the DECIMAL value 1 to string yields 1, not the longer equal-valued strings 01 or 1.0. 10.3 Conversion to xsd:boolean Conversion to boolean is the process of transforming a SQL data value of datatype BOOLEAN to a string that is compatible with the xsd:boolean datatype. It consists of the following steps:follows:

1. Identify the SQL datatype of the input SQL data value.
2. Look up its corresponding natural RDF datatype.
3. Apply conversioncast to string to the SQL data value,value.
4. convertEnsure that the resulting string is in the lexical space of the target RDF datatype; that is, it must be in a form such as those listed in either column of the table below. This may require some transformations of the string, in particular for xsd:base64Binary, xsd:dateTime and xsd:boolean.
5. If the goal is to lowercase.obtain a canonical lexical representation, then further string transformations may be required to obtain a form such as those listed in the Canonical lexical forms column of the table below.

Base64 encoding is the process of transforming a binary SQL data value to a string that is compatible with the xsd:base64Binary datatype, by applying base64 encoding as restricted for xsd:base64Binary [XMLSCHEMA2] on the binary value.

11 The Output Dataset

The output dataset of an R2RML mapping is an RDF dataset that contains the generated RDF triples for each of the triples maps of the R2RML mapping. The output dataset MUST NOT contain any other RDF triples or named graphs besides these. However, R2RML processors MAY provide access to datasets that contain additional triples or graphs beyond those in the output dataset, such as inferred triples or provenance information.

If a table or column is not explicitly referenced in a triples map, then no RDF triples will be generated for that table or column.

Conforming R2RML processors MAY rename blank nodes when providing access to the output dataset. This means that client applications may see actual blank node identifiers that differ from those produced by the R2RML mapping. Client applications SHOULD NOT rely on the specific text of the blank node identifier for any purpose.

RDF datasets may contain empty named graphs. R2RML cannot generate such output datasets.

11.1 The Generated RDF Triples of a Triples Map

This subsection describes the process of generating RDF triples from a triples map. This process adds RDF triples to the output dataset. Each generated triple is placed into one or more particular graphs of the output dataset.

The generated RDF triples are determined by the following algorithm. R2RML processors MAY use other means than implementing this algorithm to compute the generated RDF triples, as long as the result is the same.

1. Let sm be the subject map of the triples map
2. Let rows be the result of evaluating the effective SQL query of the triples map's logical table using the SQL connection
3. Let classes be the class IRIs of sm
4. Let sgm be the set of graph maps of sm
5. For each logical table row row in rows, apply the following steps:
   1. Let subject be the generated RDF term that results from applying sm to row
   2. Let subject_graphs be the union of the generated RDF terms that result from applying any term maps in sgm to row
   3. If classes is not empty, then for each IRI in classes, add the following triples to the output dataset:dataset as follows:

      Subject: subject
      Predicate: rdf:type
      Object: classes
      Target graphs: If sgm is empty: rr:defaultgraph; otherwise: subject_graphs

   4. For each predicate-object map of the triples map, apply the following steps:
      1. If the predicate-object map has no object map (but it does have a referencing object map), then skip these substeps for this predicate-object map
      2. Let predicate be the generated RDF term that results from applying the predicate-object map's predicate map to row
      3. Let object be the generated RDF term that results from applying the predicate-object map's object map to row
      4. Let pogm be the set of graph maps of the predicate-object map
      5. Let predicate-object_graphs be the union of the generated RDF terms that result from applying any graph maps in pogm to row
      6. Add the following triples to the output dataset to the output dataset:as follows:

         Subject: subject
         Predicate: predicate
         Object: object
         Target graphs: If sgm and pogm are empty: rr:defaultGraph; otherwise: union of subject_graphs and predicate-object_graphs

6. For each predicate-object map of the triples map, apply the following steps:
   1. If the predicate-object map has no referencing object map (but a normalit does have an object map), then skip these substeps for this predicate-object map
   2. Let psm be the subject map of the parent triples map of the referencing object map
   3. Let pogm be the set of graph maps of the predicate-object map
   4. Let n be the number of columns in the logical table of the triples map
   5. Let rows be the result of evaluating the joint SQL query of the referencing object map
   6. For each row in rows, apply the following steps:
      1. Let child_row be the subsetlogical table row derived by taking the first n columns of row whose columns are present in the referencing object map's child query
      2. Let parent_row be the subsetlogical table row derived by taking all but the first n columns of row whose columns are present in the referencing object map's parent query
      3. Let subject be the generated RDF term that results from applying sm to child_row
      4. Let predicate be the generated RDF term that results from applying the predicate-object map's predicate map to child_row
      5. Let object be the generated RDF term that results from applying psm to parent_row
      6. Let subject_graphs be the union of the generated RDF terms that result from applying any graph maps of sgm to child_row
      7. Let predicate-object_graphs be the union of the generated RDF terms that result from applying any graph maps in pogm to child_row
      8. Add the following triples to the output dataset to the output dataset:as follows:

         Subject: subject
         Predicate: predicate
         Object: object
         Target graphs: If neither sgm nor pogm has any graph maps: rr:defaultGraph; otherwise: union of subject_graphs and predicate-object_graphs

The process of adding“Add triples to the output dataset” is a process that takes as its input:the following inputs:

• Subjects, a set of zero or more IRIs or blank nodes
• Predicates, a set of zero or more IRIs
• Objects, a set of zero or more RDF terms
• Target graphs, a set of zero or more IRIs

For each possible combination <s, p, o>, where s is a member of Subjects, p a member of Predicates and o a member of Objects:

1. Generate an RDF triple <s, p, o>
2. If the set of target graphs includes rr:defaultGraph, add the triple to the default graph of the output dataset.
3. For each IRI in the set of target graphs that is not equal to rr:defaultGraph, add the triple to a named graph of that name in the output dataset. If the output dataset does not contain a named graph with that IRI, create it first.

RDF graphs cannot contain duplicate RDF triples. Placing multiple equal triples into the same graph has the same effect as placing it into the graph only once.

11.2 The Generated RDF Terms of a Term Map

A term map is a function that generates a set of RDF terms from a logical table row. The result of that function can be:

• The empty set – if the any of the referenced columns of the term map referenceshas a NULL value,
• A singleton set of one RDF term – the common case,
• A data error.

The generated RDF terms of a term map for a given logical table row are determined as follows:

• If the term map is a constant-valued term map, then the generated RDF terms are a singleton set containing the term map's constant value.
• If the term map is a column-valued term map, then the generated RDF terms are determined by applying the term generation rules to its column value.
• If the term map is a template-valued term map, then the generated RDF terms are determined by applying the term generation rules to its template value.

The term generation rules , applied to a value, are as follows:

1. If the value is NULL, then no RDF term is generated.
2. Otherwise, if the term map's term type is rr:IRI:
   1. Apply conversionLet value be the natural RDF lexical form corresponding to string to the value.value.
   2. If the value is a valid absolute IRI [RFC3987], then generatereturn an IRI generated from value.
   3. Otherwise, prepend the value with the base IRI. If the result is a valid absolute IRI [RFC3987], then generatereturn an IRI generated from the result.
   4. Otherwise, raise a data error.
3. Otherwise, if the term type is rr:BlankNode:
   1. Apply conversion to string to the value. Generate Return a blank node whose blank node identifier is the value. natural RDF lexical form corresponding to value.
4. Otherwise, if the term type is rr:Literal:
   1. If the term map has a specified language tag, then apply conversion to string to the value, and generatereturn a plain literal with that language tag.tag and with the natural RDF lexical form corresponding to value.
   2. Otherwise, if the term map has a datatype override is in effect on the term map: Apply conversion to string to the value. Generate a typed literal whose datatype IRI is the non-empty specified datatype that is different from the natural RDF datatype corresponding to the term map's implicit SQL datatype, then return the datatype-override RDF literal corresponding to value and the specified datatype.
   3. Otherwise, return the natural RDF literal corresponding to value.
   If the specified datatype is a supported RDF datatype and the generated typed literal is ill-typed, then raise a data error.

A. RDF Terminology (Informative)

This sectionappendix lists some terms normatively defined in other specifications.

The following terms are defined in RDF Concepts and Abstract Syntax [RDF] and used in R2RML:

• RDF graph
• RDF triple
• IRI (corresponds to the Concepts and Abstract Syntax term RDF URI reference)
• literal
• plain literal
• typed literal
• language tag
• lexical form
• datatype IRI (corresponds to the Concepts and Abstract Syntax term datatype URI)
• lexical space
• blank node
• blank node identifier

The following terms are defined in SPARQL Query Language for RDF [SPARQL] and used in R2RML:

• RDF dataset
• default graph
• named graph

B. Index of R2RML Vocabulary Terms (Informative)

This appendix lists all the classes, properties and other terms defined by this specification within the R2RML vocabulary.

An RDFS representation of the vocabulary is available from the namespace IRI.

B.1 Classes

The following table lists all R2RML classes.

B.2 Properties

The following table lists all properties in the R2RML vocabulary.

The cardinality column indicates how often this property occurs within its context. Note that additional constraints not stated in this table might apply, and making a property forbiddenthe actual cardinality may depend on the presence or required in certain situations.absence of other properties, and their values.

B.3 Other Terms

C. References

C.1 Normative References

[RDF]

Resource Description Framework (RDF): Concepts and Abstract Syntax, Graham Klyne, Jermey J. Carroll, Editors. World Wide Web Consortium, 10 February 2004. This version is http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/. The latest version is http://www.w3.org/TR/rdf-concepts/.

[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, March 1997. Internet RFC 2119, http://tools.ietf.org/html/rfc2119.

[RFC3629]

UTF-8, a transformation format of ISO 10646, F. Yergeau. November 2003. Internet RFC 3629, http://tools.ietf.org/html/rfc3629.

[RFC3986]

Uniform Resource Identifier (URI): Generic Syntax, T. Berners-Lee, R. Fielding, L. Masinter. January 2005. Internet RFC 3986, http://tools.ietf.org/html/rfc3986.

[RFC3987]

Internationalized Resource Identifiers (IRIs), M. Duerst, M. Suignard. January 2005. Internet RFC 3987, http://tools.ietf.org/html/rfc3987.

[SPARQL]

SPARQL Query Language for RDF, Eric Prud'hommeaux, Andy Seaborne, Editors. World Wide Web Consortium, 15 January 2008. This version is http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/. The latest version is http://www.w3.org/TR/rdf-sparql-query/.

[SQL1]

ISO/IEC 9075-1:2008 SQL - Part 1: Framework (SQL/Framework). International Organization for Standardization, 27 January 2009.

[SQL2]

ISO/IEC 9075-2:2008 SQL - Part 2: Foundation (SQL/Foundation). International Organization for Standardization, 27 January 2009.

[TURTLE]

Turtle - Terse RDF Triple Language, Dave Beckett, Tim Berners-Lee. World Wide Web Consortium, 14 January 2008. This version is http://www.w3.org/TeamSubmission/2008/SUBM-turtle-20080114/. The latest version is http://www.w3.org/TeamSubmission/turtle/.

[XMLSCHEMA2]

W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes Second Edition, Paul V. Biron,David Peterson, Shudi Gao, Ashok Malhotra.Malhotra, C. M. Sperberg-McQueen, Henry S. Thompson. World Wide Web Consortium, 28 October 2004.21 July 2011. This version is http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/.http://www.w3.org/TR/2011/CR-xmlschema11-2-20110721/. The latest version is http://www.w3.org/TR/xmlschema-2/.http://www.w3.org/TR/xmlschema11-2/. This document is work in progress.

C.2 Other References

[DM]

A Direct Mapping of Relational Data to RDF, Alexandre Bertails, Marcelo Arenas, Eric Prud'hommeaux, Juan Sequeda, Editors. World Wide Web Consortium, 20 September 2011. This version is http://www.w3.org/TR/2011/WD-rdb-direct-mapping-20110920/. The latest version is http://www.w3.org/TR/rdb-direct-mapping/. This document is work in progress.

[SQL14]

ISO/IEC 9075-14:2008 SQL - Part 14: XML-Related Specifications (SQL/XML). International Organization for Standardization, 27 January 2009.

[SQLIRIS]

SQL Version IRIs, Members of the W3C RDB2RDF Working Group. The latest version is http://www.w3.org/2001/sw/rdb2rdf/wiki/SQL_Version_IRIs. This is a public wiki page.

[TC]

R2RML and Direct Mapping Test Cases (Editor's Draft), Boris Villazón-Terrazas, Michael Hausenblas, Alexander de Leon, Editors. World Wide Web Consortium, 31 August 2011. The latest version is http://www.w3.org/2001/sw/rdb2rdf/test-cases/. This document is work in progress.

[UCNR]

Use Cases and Requirements for Mapping Relational Databases to RDF, Eric Prud'hommeaux, Michael Hausenblas, Editors. World Wide Web Consortium, 8 June 2010. This version is http://www.w3.org/TR/2010/WD-rdb2rdf-ucr-20100608/. The latest version is http://www.w3.org/TR/rdb2rdf-ucr/. This document is work in progress.

D. Acknowledgements (Informative)

The Editors would like to give special thanks to the following members: Nuno Lopes for help in designing the datatyping related text, David McNeil for raising many of the issues that needed addressing, Eric Prud'hommeaux for designing the SQL compatibility text, and Boris Villazón-Terrazas for drawing all the diagrams.

In addition, the Editors gratefully acknowledge contributions from: Marcelo Arenas, Sören Auer, Samir Batla, Alexander de Leon, Orri Erling, Lee Feigenbaum, Enrico Franconi, Howard Greenblatt, Wolfgang Halb, Harry Halpin, Michael Hausenblas, Patrick Hayes, Ivan Herman, Nophadol Jekjantuk, Li Ma, Nan Ma, Ashok Malhotra, Ivan Mikhailov, Percy Enrique Rivera Salas, Juan Sequeda, Ben Szekely, Ted Thibodeau, and Edward Thomas.

E. CVS History (Informative)

$Log: 1.160-1.179.html,v $
Revision 1.1  2011/12/13 18:11:05  rcygania2
add a diff of all post-LC changes to date

Revision 1.179  2011/12/06 15:36:12  rcygania2
implement ISSUE-77 resolution by noting XSD dependency in SOTD section

Revision 1.178  2011/12/06 14:56:58  rcygania2
implement ISSUE-76 resolution by changing rr:termType default rules

Revision 1.177  2011/11/25 15:29:44  rcygania2
Update all XSD references to XSD 1.1

Revision 1.176  2011/11/25 01:24:40  rcygania2
fix broken link

Revision 1.175  2011/11/25 01:20:29  rcygania2
Another major rewrite of the datatype mapping section to implement ISSUE-69 resolution

Revision 1.174  2011/11/23 16:08:46  rcygania2
Change typeable term map to datatypeable term map to reduce potential for confusion with termType

Revision 1.173  2011/11/23 16:06:58  rcygania2
fix a note that talks about generating plain literals; drop an unnecessary special case from datatype-override literals; add a box for ISSUE-76

Revision 1.172  2011/11/15 22:30:57  rcygania2
mini ed. tweak

Revision 1.171  2011/11/15 17:08:57  rcygania2
mini ed. tweak

Revision 1.170  2011/11/14 17:13:15  rcygania2
tweaked some wording in the generated RDF triples to deal with ISSUE-71

Revision 1.169  2011/11/14 01:15:22  rcygania2
further ISSUE-70 wording tweaks

Revision 1.168  2011/11/14 01:04:30  rcygania2
Slight clarifications related to duplicate column names and fully qualified column names in SQL queries (ISSUE-70)

Revision 1.167  2011/11/13 23:44:44  rcygania2
Major re-write of the datatype mapping section and related areas, to increase clarity. Also fixes some bugs in normative behaviour.

Revision 1.166  2011/11/07 19:10:43  rcygania2
Revert big Note in Section 5 to r1.149, as per Richard's and David's LC comments

Revision 1.165  2011/11/07 17:56:19  rcygania2
Address Ivan Herman's LC comments

Revision 1.164  2011/11/07 17:27:16  rcygania2
Fix two bugs noted in LC comment by Toby Inkster

Revision 1.163  2011/11/07 17:22:42  rcygania2
Remove redundant rr:termType from examples, as per my own LC comment

Revision 1.162  2011/11/07 17:04:01  rcygania2
Clarify Note on mappings with non-constant class IRIs in 6.2 (LC comment by Ahmed Bassiouni)

Revision 1.161  2011/11/07 16:54:21  rcygania2
Address most of Davic McNeil's LC comments

Revision 1.160  2011/09/22 00:12:52  sdas2
merged with Last Call Working Draft

Revision 1.159  2011/09/15 14:48:28  mhausenb
fixed ToC

Revision 1.158  2011/09/15 14:46:19  mhausenb
fixed ToC

Revision 1.157  2011/09/15 11:12:37  sdas2
fixed emp table link in sec 6.2

Revision 1.156  2011/09/14 23:04:36  sdas2
Changed [TC] reference date to reflect the latest (email from Boris)

Revision 1.155  2011/09/14 19:42:01  sdas2
adjusted the algo in Sec 11.1, added JOB col to EMP, fixed missing EMP table link, some editorial changes -- Fig 1 and Fig 6 needs changes to make GraphMap connecting with PredicateObjectMap instead of ObjectMap -- Souri/Seema

Revision 1.154  2011/09/14 15:23:13  sdas2
case-sensitivity of column names: uppercased the examples to make it easy, added note in Sec 5 about col names specified using RDF plain literal or within braces

Revision 1.153  2011/09/13 19:10:05  sdas2
fix a typo

Revision 1.152  2011/09/13 19:07:59  sdas2
removed the syntactic sugar for implicit predicate-object map and restricted a POmap to allow only a single Pmap

Revision 1.151  2011/09/13 18:37:42  sdas2
remove translation schemes related text

Revision 1.150  2011/09/13 16:03:19  sdas2
translation scheme revision and re-owrding of ISSUE-57 -- Seema/Souri

Revision 1.149  2011/09/08 09:57:52  rcygania2
conversion to string not necessary for base64Binary encoding

Revision 1.148  2011/08/31 12:50:42  sdas2
alternate translation scheme: fixed a minor typo in the second example

Revision 1.147  2011/08/30 19:35:36  sdas2
alternate translation scheme: further simplification (of rdf:term property value)

Revision 1.146  2011/08/30 18:25:00  sdas2
alternate translation scheme: shown via examples

Revision 1.145  2011/08/29 19:45:14  rcygania2
fix invalid HTML

Revision 1.144  2011/08/28 14:24:35  rcygania2
hyperlink a term

Revision 1.143  2011/08/27 15:31:51  rcygania2
add explicit @prefix declaration to first example

Revision 1.142  2011/08/27 15:17:01  rcygania2
drop issue box for ISSUE-58; not essential for LC

Revision 1.141  2011/08/27 15:16:02  rcygania2
drop issue box for ISSUE-55; I think we are fine without

Revision 1.140  2011/08/27 15:01:29  rcygania2
ISSUE-59: syntactic sugar for implicit predicate-object maps

Revision 1.139  2011/08/27 14:11:11  rcygania2
ISSUE-60: Syntactic sugar for the simple case of logical tables

Revision 1.138  2011/08/27 13:53:55  rcygania2
incorporated translationSchema comments from David http://lists.w3.org/Archives/Public/public-rdb2rdf-wg/2011Aug/0147.html

Revision 1.137  2011/08/26 18:47:00  rcygania2
implement ISSUE-56. This changes default term type for rr:template in object map to rr:IRI

Revision 1.136  2011/08/26 18:42:32  rcygania2
implement ISSUE-54. This changes rr:subject, rr:predicate, rr:object, rr:graph and adds rr:constant

Revision 1.135  2011/08/26 17:31:46  rcygania2
update Status of this Document section

Revision 1.134  2011/08/26 15:29:13  rcygania2
add a big issue box on ISSUE-57

Revision 1.133  2011/08/26 15:05:43  rcygania2
work on the Output Dataset section to deal with cardinality of Generated RDF Term

Revision 1.132  2011/08/26 12:33:27  rcygania2
change acknowledgements to style used by SPARQL WG; more to come

Revision 1.131  2011/08/26 12:19:19  rcygania2
remove two obsolete issue boxes

Revision 1.130  2011/08/26 00:13:04  rcygania2
bugfix

Revision 1.129  2011/08/25 23:51:52  rcygania2
ISSUE-29/ISSUE-48/ISSUE-51: translation of SQL datatypes to strings and to RDF datatypes

Revision 1.128  2011/08/25 18:28:30  rcygania2
Add new diagram for translation schemes - thanks Boris!

Revision 1.127  2011/08/23 19:37:44  rcygania2
moved [TC] link from Section 4 to Conformance section

Revision 1.126  2011/08/23 14:39:58  rcygania2
add rr:translationScheme to list of properties

Revision 1.125  2011/08/23 14:37:06  rcygania2
add new section on translation schemes (ISSUE-61); almost complete

Revision 1.124  2011/07/29 19:01:32  rcygania2
add many-to-many example to Section 2, and subdivide the section more

Revision 1.123  2011/07/29 18:40:30  rcygania2
slightly reworded a phrase on re-using mapping components in 4.1 based on feedback from Juan

Revision 1.122  2011/07/26 18:45:22  rcygania2
remove (broken) links to SQL spec. The ISO specs are not available online except behind ISO paywall

Revision 1.121  2011/07/25 17:40:48  rcygania2
Better structure for the example R2RML mapping, based on Sören's comment

Revision 1.120  2011/07/25 13:11:22  rcygania2
fix broken links

Revision 1.119  2011/07/25 12:52:49  rcygania2
Address Sören's comments from http://lists.w3.org/Archives/Public/public-rdb2rdf-wg/2011Jul/0138.html

Revision 1.118  2011/07/23 15:39:33  rcygania2
wordsmithing

Revision 1.117  2011/07/22 18:16:50  rcygania2
gave up on ISSUE-49; added minimal description for the term most in need of definition

Revision 1.116  2011/07/22 18:03:40  rcygania2
add some links to the test cases

Revision 1.115  2011/07/22 17:45:35  rcygania2
moving the big example from R2RML spec to test cases

Revision 1.114  2011/07/22 17:02:45  rcygania2
add a global to-do list

Revision 1.113  2011/07/22 16:55:21  rcygania2
New term reference in R2RML; prepared very rough namespace document for the rr: namespace

Revision 1.112  2011/07/22 09:55:34  rcygania2
remove boxes for postponed/dropped issues 37 and 50

Revision 1.111  2011/07/22 09:46:45  rcygania2
Implement ISSUE-47 resolution by introducing "data errors" and "R2RML data validators"

Revision 1.110  2011/07/22 08:48:15  rcygania2
Implement ISSUE-45 resolution: replace rr:termType values with IRI constants

Revision 1.109  2011/07/22 08:31:38  rcygania2
Implement ISSUE-34 resolution: remove rr:tableOwner, allow catalog and schema in rr:tableName

Revision 1.108  2011/07/22 08:12:13  rcygania2
add issue boxes for ISSUE-54, 55, 56 (and fix broken links)

Revision 1.107  2011/07/22 08:03:09  rcygania2
minor editorial clarifications

Revision 1.106  2011/07/13 13:12:55  rcygania2
add issue boxes for ISSUE-43 and ISSUE-47

Revision 1.105  2011/07/13 11:32:44  rcygania2
typo fix, and crossref to clarify requirement of SQL 2008 conformance

Revision 1.104  2011/07/13 11:23:22  rcygania2
implement ISSUE-35 resolution on case sensitivity and quoting of SQL identifiers; add long note on syntax rules for SQL identifiers

Revision 1.103  2011/07/13 10:44:06  rcygania2
add issue boxes for ISSUE-29

Revision 1.102  2011/07/13 10:32:54  rcygania2
clarify that SQL connection has default catalog and default schema

Revision 1.101  2011/07/08 19:07:03  rcygania2
all images are now updated

Revision 1.100  2011/07/08 14:00:09  rcygania2
update placement and numbering of images

Revision 1.99  2011/07/08 13:20:21  rcygania2
add more boxes for open issues

Revision 1.98  2011/07/08 12:35:52  rcygania2
mention the classes defined in rr: namespace; add boxes for open issues

Revision 1.97  2011/07/08 00:24:48  rcygania2
re-done RefObjectMap

Revision 1.96  2011/07/07 16:12:03  rcygania2
replaced rr:graph properties with rr:graphMap

Revision 1.95  2011/07/07 13:44:25  rcygania2
bugfix in example mapping; clarify that no extra triples are allowed

Revision 1.94  2011/07/07 12:51:32  rcygania2
allow multiple predicateMaps in a predicate-object map

Revision 1.93  2011/07/07 12:35:17  rcygania2
capitalization of rr:sqlQuery and rr:termType; forbid blank nodes in rr:subject and rr:object

Revision 1.92  2011/07/06 12:23:01  rcygania2
preciser definitions of conforming mapping graphs and more info on RDF use

Revision 1.91  2011/07/05 21:32:51  rcygania2
change prefix to ex: instead of exa:

Revision 1.90  2011/07/05 21:16:40  rcygania2
add conformance section; move terminology to appendix; update property reference; markup fixes

Revision 1.89  2011/07/05 20:42:40  rcygania2
clarifications: trailing semicolon is optional for SQL queries; special chars within column names in rr:template need escaping

Revision 1.88  2011/07/05 19:56:37  rcygania2
completed the algorithm for placing triples into the output dataset

Revision 1.87  2011/07/05 19:24:36  rcygania2
Address ISSUE-22, non-standard SQL

Revision 1.86  2011/07/05 17:44:05  rcygania2
make Section 3 informative; add definition for character string type

Revision 1.85  2011/07/05 17:12:35  rcygania2
better markup for Notes; define referenced columns

Revision 1.84  2011/07/05 14:53:17  rcygania2
Add details on column names

Revision 1.83  2011/07/05 12:17:55  rcygania2
attempting to formalize rr:inverseExpression

Revision 1.82  2011/07/04 23:47:22  rcygania2
must escape backslash characters in rr:template by doubling them

Revision 1.81  2011/07/04 23:45:31  rcygania2
add Notes on some limitations; add 'SHOULD avoid ambiguous templates'

Revision 1.80  2011/07/04 22:45:08  rcygania2
Acknowledgements: The editors shouldn't thank themselves

Revision 1.79  2011/07/04 21:48:39  rcygania2
Address handling of relative IRIs and invalid IRIs (ISSUE-47)

Revision 1.78  2011/07/04 18:56:25  rcygania2
Add TODO on ISSUE-41 resolution

Revision 1.77  2011/07/04 17:14:36  rcygania2
completing large overhaul, with major restructuring of R2RML document

Revision 1.3  2011/07/01 22:24:41  rcygania2
more overhauling

Revision 1.2  2011/07/01 17:25:17  rcygania2
more work on the overhaul. term maps now complete

Revision 1.1  2011/07/01 11:19:01  rcygania2
starting a big editorial overhaul

Revision 1.76  2011/06/30 13:53:18  rcygania2
wordsmithing

Revision 1.75  2011/06/29 12:47:54  rcygania2
add explicit definitions for R2RML processor, input database, output dataset; make use of terminology more consistent throughout

Revision 1.74  2011/06/29 08:14:14  rcygania2
more definition markup

Revision 1.73  2011/06/29 08:01:05  rcygania2
ACTION-123: Implement ISSUE-25 resolution by stating that no triples are generated for tables or columns that are not referenced

Revision 1.72  2011/06/29 07:46:43  rcygania2
marked up a bunch of definitions and links to definitions

Revision 1.71  2011/06/29 07:31:52  rcygania2
wordsmithing the media type paragraph; adding information on charset parameter

Revision 1.70  2011/06/29 07:21:31  rcygania2
clarifications around syntax requirements and ISSUE-2 resolution

Revision 1.69  2011/06/20 11:50:42  rcygania2
Added warnings to diagrams, they might be out of date

Revision 1.68  2011/06/15 23:22:49  sdas2
inserted the missing semi-colons in Sections A.2.2.* (pointed out by Ivan Mikhailov)

Revision 1.67  2011/06/15 14:37:28  sdas2
updated Figure numbers

Revision 1.66  2011/06/15 14:30:02  sdas2
couple of typos

Revision 1.65  2011/06/15 03:52:56  sdas2
minor markup validation error fixes

Revision 1.64  2011/06/15 03:47:49  sdas2
ISSUE-18 / Action-126: introduced rr:LogicalTable class and rr:useLogicalTable property

Revision 1.63  2011/06/14 15:44:44  sdas2
minor changes

Revision 1.62  2011/05/31 18:57:27  sdas2
part of ACTION-126 -- making class and property names meaningful: class names changed: *MapClass --> *Map AND property names changed: *Map --> use*Map BUT diagrams not updated yet

Revision 1.61  2011/05/31 18:20:54  rcygania2
Clarified that multiple equal triples in the same graph have no additional effect

Revision 1.60  2011/05/30 22:48:15  rcygania2
Small text clarifications; better layout for vocab/example boxes; more compact display of example tables

Revision 1.59  2011/05/24 19:22:21  rcygania2
Fixing section nesting

Revision 1.58  2011/05/24 19:13:02  rcygania2
Modified design for rr:joinCondition as per ACTION-130

Revision 1.57  2011/03/23 08:05:19  ivan
*** empty log message ***

Revision 1.56  2011/03/23 07:41:45  ivan
Took care of an XML validation error before pubrules check

Revision 1.55  2011/03/22 21:13:07  rcygania2
ACTION-113 and ACTION-114: update intro re DM, clarify blank node scope once more, update all ISSUE boxes

Revision 1.54  2011/03/22 18:27:59  sdas2
Modified text in sections 3.3.1.3, 3.6.13, 3.6.1.4, and 3.6.1.5 for ACTION-112 -- Souri/Seema

Revision 1.53  2011/03/22 15:41:08  sdas2
added that rr:column is a shortcut for rr:template and fixed special characters in names in Acknowldegement section -- Souri/Seema

Revision 1.52  2011/03/22 14:30:33  sdas2
Made sure Acknowledgement section has names of all the current members

Revision 1.51  2011/03/21 11:03:41  rcygania2
more tweaks to text on blank node scope

Revision 1.50  2011/03/21 10:45:54  rcygania2
clarify text on blank node scope

Revision 1.49  2011/03/20 01:44:19  sdas2
changed caption of UML diagram based on suggestion from Boris

Revision 1.48  2011/03/19 23:15:50  sdas2
ACTION 111 - allowing storage of triples into default and/or named graph(s) + UML diag from Alex De Leon

Revision 1.47  2011/03/15 20:56:54  rcygania2
ACTION-109: Swapped Sections 4 and 5; renamed "Usage Notes" to "Scope of Blank Nodes"; added text re ISSUE-30, client apps can see different actual bNode identifiers

Revision 1.46  2011/03/15 20:28:40  rcygania2
ACTION-108: add note re ISSUE-32 to 3.9.1.2 rr:joinCondition

Revision 1.45  2011/03/15 17:02:22  sdas2
more replacements with childAlias and parentAlias

Revision 1.44  2011/03/15 16:53:22  sdas2
removed rr: from child and parent alias strings in join condition based on comment from Ivan durin telecon

Revision 1.43  2011/03/15 15:25:44  sdas2
addressed Issue-32: removed curly brace enclosure requirement for column names in join condition -- Souri/Seema

Revision 1.42  2011/03/14 16:16:00  sdas2
fixed html validation error

Revision 1.41  2011/03/14 16:10:30  sdas2
addressed open issues 22, 24, 26, and 31 -- Souri/Seema

Revision 1.40  2011/03/08 16:37:29  sdas2
backslash for escaping curly braces in values for rr:template property -- Souri/Seema.

Revision 1.39  2011/03/07 20:10:31  ssundara
make rr:tableOwner optional and misc cleanups -- Souri/Seema

Revision 1.38  2010/12/07 19:23:25  ssundara
add section on use of blank nodes - Souri/Seema

Revision 1.37  2010/11/23 16:59:48  ssundara
specified string syntax for inverseExpressions, template, graphTemplate and joinCondition - Souri/Seema

Revision 1.36  2010/11/18 05:16:42  sdas2
several typo fixes

Revision 1.35  2010/11/15 19:18:08  sdas2

added new figure files and removed ValueMapClass

Revision 1.34  2010/11/05 18:47:56  sdas2
added A.2.2.3 and fixed some typo

Revision 1.33  2010/11/05 03:01:44  sdas2
use example.com, exa:, and EXAMPLE Corporation instead of their xyz counterparts

Revision 1.32  2010/11/05 01:47:11  sdas2
figures need to change to adjust to the new classes etc. -- removing them for now

Revision 1.31  2010/11/05 01:41:30  sdas2
added rdf:type triples to the set of RDF triples generated from EMP table

Revision 1.30  2010/11/04 20:51:41  sdas2
now uses SubjectMap, PredicateMap, ObjectMap, PredicateObjectMap, etc . (instead of TermMap, etc.)

Revision 1.29  2010/10/28 22:17:21  rcygania2
merged the FPWD preparation changes done by Michael and Harry

Revision 1.4  2010/10/28 15:30:16  hhalpin
updated

Revision 1.3  2010/10/28 14:39:13  hhalpin
add two sentences to deal with default mapping resulting from W3C telecon.

Revision 1.2  2010/10/27 14:41:44  hhalpin
Removed e-mails of editors for their own safety

Revision 1.1  2010/10/27 13:58:07  hhalpin
First FPWD

Revision 1.5  2010/10/27 13:20:08  mhausenb
fixed expected pub date

Revision 1.4  2010/10/27 12:54:17  mhausenb
fix some minor things such as typos, pubrules now just complains re missing resources (but that's fine)

Revision 1.3  2010/10/27 12:42:04  mhausenb
fixing pubrules issues in SOTD section

Revision 1.2  2010/10/27 12:29:44  mhausenb
fix minor bug with CSS

Revision 1.1  2010/10/27 12:26:42  mhausenb
init FPWD R2RML as per WG decision http://www.w3.org/2010/10/19-rdb2rdf-minutes.html#item02 and http://www.w3.org/2010/10/26-rdb2rdf-minutes.html#item02