Copyright © 2011 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document 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. R2RML mappings are themselves RDF graphs and written down in Turtle syntax. R2RML enables different types of mapping implementations. Processors could, for example, offer a virtual SPARQL endpoint over the mapped relational data, or generate RDF dumps, or offer a Linked Data interface.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is a Public Working Draft of the "R2RML: RDB to RDF Mapping Language" for review by W3C members and other interested parties.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
The W3C RDB2RDF Working Group is responsible for this document. It includes the RDF Schema that can be used to specify a mapping of relational data to RDF. The structure of this document will change based upon future decisions taken by the W3C RDB2RDF Working Group. The Working Group is also working on a document that will define a default mapping from relational databases to RDF. The Working Group hopes to publish the default mapping document shortly.
Comments on this document should be sent to public-rdb2rdf-comments@w3.org, a mailing list with a public archive.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
1 Introduction
1.1 Terminology
1.2 RDF-based Turtle Syntax; Media Type
1.3 SQL Conformance
1.4 Mapping Overview
1.5 Document Conventions
2 Sample Relational Tables
2.1 DEPT Table
2.1.1
DEPT_L (logical) Table
2.1.2
A Simple Mapping for DEPT_L Table
2.1.3
RDF Triples generated from DEPT_L Table
2.2 EMP Table
2.2.1
EMP_L (logical) Table
2.3 LIKES Table
2.3.1
LIKES_L (logical) Table
3 RDF Vocabulary for R2RML
3.1 R2RML Overview
3.2 TriplesMapClass
3.2.1
Properties of TriplesMapClass
3.2.1.1
rr:tableOwner, rr:tableName, and rr:SQLQuery
3.2.1.2 rr:subjectMap
3.2.1.3
rr:predicateObjectMap
3.2.1.4
rr:refPredicateObjectMap
3.3 SubjectMapClass
3.3.1 Properties of SubjectMapClass
3.3.1.1 rr:subject
3.3.1.2 rr:column
3.3.1.3 rr:termtype
3.3.1.4 rr:class
3.3.1.5 rr:graph
3.3.1.6
rr:graphColumn
3.3.1.7
rr:inverseExpression
3.3.1.8 rr:template
3.3.1.9 rr:graphTemplate
3.4 PredicateObjectMapClass
3.4.1
Properties of PredicateObjectMapClass
3.4.1.1
rr:predicateMap
3.4.1.2 rr:ObjectMap
3.4.1.3
rr:graph
3.4.1.4
rr:graphColumn
3.4.1.5
rr:graphTemplate
3.5 PredicateMapClass
3.5.1
Properties of PredicateMapClass
3.5.1.1 rr:predicate
3.5.1.2
rr:column
3.5.1.3
rr:inverseExpression
3.5.1.4 rr:template
3.6 ObjectMapClass
3.6.1
Properties of ObjectMapClass
3.6.1.1 rr:object
3.6.1.2 rr:column
3.6.1.3 rr:termtype
3.6.1.4 rr:datatype
3.6.1.5 rr:language
3.6.1.6
rr:inverseExpression
3.6.1.7 rr:template
3.7 RefPredicateObjectMapClass
3.7.1
Properties of RefPredicateObjectMapClass
3.7.1.1
rr:refPredicateMap
3.7.1.2
rr:refObjectMap
3.7.1.3
rr:graph
3.7.1.4
rr:graphColumn
3.7.1.5
rr:graphTemplate
3.8 RefPredicateMapClass
3.8.1
Properties of RefPredicateMapClass
3.8.1.1
rr:predicate
3.9 RefObjectMapClass
3.9.1
Properties of RefObjectMapClass
3.9.1.1
rr:parentTriplesMap
3.9.1.2
rr:joinCondition
4 Scope of Blank Nodes
5 Summary of the Properties in R2RML
A.
Example of SQL based RDB2RDF Mapping using the Turtle Syntax (Informative)
A.1 Sample Relational Tables
A.2 Mapping Specification for the Tables
A.2.1
Mapping Specification for the DEPT Table
A.2.2
Mapping Specification for the EMP Table
A.2.2.1
Mapping using SQL-based logical table
A.2.2.2
Mapping using table name based logical table
A.2.2.3
Mapping showing reuse of ObjectMaps
A.2.3
Mapping Specification for the LIKES Table
B. References
B.1 Normative References
B.2 Other References
C. Acknowledgements (Informative)
D. CVS History (Informative)
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 type 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 are 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].
Unless otherwise noted in the section heading, all sections and appendices in this document are normative.
ISSUE-25: The use of a "convention over configuration" approach has been proposed, where a mapping is not expressed completely, but rather as a delta from the default mapping. In other words, only those parts that one wants to be different from the default mapping have to be written down in the mapping file.
ISSUE-36: As currently defined, the output of an R2RML mapping is an RDF dataset that contains triples reflecting the records in the database. The output is thus on the "instance level". A feature under discussion is the additional generation of an RDF Schema or OWL Ontology that reflects the constraints and valid inferences over the classes and properties in the generated dataset. This output would be on the "terminology level".
The following terms are defined in RDF Concepts and Abstract Syntax [RDF] and used in R2RML:
The following terms are defined in SPARQL Query Language for RDF [SPARQL] and used in R2RML:
An R2RML mapping defines a mapping from a relational database to an RDF dataset. This mapping itself 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 a mapping graph.
An R2RML mapping document is any document written in the Turtle [TURTLE] RDF syntax that encodes an R2RML mapping graph. All examples throughout this specification use the Turtle syntax.
For R2RML mapping files, the same media type as for Turtle should be used:
text/turtle
. The preferred file extension is .ttl
.
ISSUE-2: This draft demands Turtle as the serialization format. What about other RDF formats, such as RDF/XML or RDFa? And what about non-RDF syntaxes for expressing R2RML mappings? The Working Group's charter states: “The mapping language SHOULD have a human-readable syntax as well as XML and RDF representations of the syntax for purposes of discovery and machine generation.”
R2RML mappings contain various database objects, such as table names, column names, and SQL queries. These references form an important part of the mapping. These SQL concepts are defined in ISO/IEC 9075-1:2008 [SQL1]. The syntax and semantics of SQL queries are defined in ISO/IEC 9075-2:2008 [SQL2].
In places where SQL expressions are allowed, these MUST conform to Core SQL 2008.
ISSUE-22: Implementors MUST be free to offer support for additional SQL dialects. How to address this? Current thought is to allow a way for implementors to optionally specify compatibility information applicable for a TriplesMap. For example: <#TriplesMap1> rr:SQLCompatibility "MySQL" .
The R2RML language is defined with reference to an execution environment that provides a SQL connection to the input database. The SQL connection MUST be established with sufficient privileges for read access to all base tables and views that are referenced in the R2RML mapping. How the SQL connection is established, or how users are authenticated against the database, is outside of the scope of this document. R2RML processors MAY use other means than evaluating SQL queries against the input database, as long as the results are the same.
ISSUE-37: For convenience reasons, connection details could be provided in the mapping file as well, rather than assuming that the connection must be configured externally.
ISSUE-38: The execution environment should probably provide other (optional) information besides the database connection, such as a base URI and default graph name.
An R2RML mapping consists of one or more structures called TriplesMaps.
Each TriplesMap contains a reference to a logical table in the input database. A logical table can be one of the following:
Furthermore, a TriplesMap contains the rules for mapping a logical table row to a set of RDF triples. It consists of one SubjectMap structure and one or more PredicateObjectMap structure(s).
The RDF triples generated from one row all share the same subject. The SubjectMap structure in a TriplesMap contains the rules for generating the subject for a row.
Each PredicateObjectMap structure in a TriplesMap contains the rules for generating a (predicate, object) pair from the values in the table row. It consists of a PredicateMap structure and an ObjectMap structure. The PredicateMap structure contains the rules for generating the predicate and the ObjectMap structure contains the rules for generating the object.
A TriplesMap is used to generate RDF triples from a row in the logical table by combining the single subject for the row, generated using the SubjectMap, with the (predicate, object) pair(s) generated from the row using the PredicateObjectMap(s).
The output of an R2RML mapping is an RDF dataset. The RDF triples in the dataset are the result of applying the mapping rules of each TriplesMap to the rows of its logical table.
By default, all RDF triples are in the default graph of the RDF dataset. A TriplesMap can contain optional rules that place some or all of the triples into named graphs instead.
In this document, examples assume the following namespace prefix bindings unless otherwise stated:
Prefix | IRI |
---|---|
rr: |
http://www.w3.org/ns/r2rml# |
rdf: |
http://www.w3.org/1999/02/22-rdf-syntax-ns# |
rdfs: |
http://www.w3.org/2000/01/rdf-schema# |
xsd: |
http://www.w3.org/2001/XMLSchema# |
exa: |
http://example.com/ns# |
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 and green boxes contain example input and output data, respectively:
# This box contains example input tables
# This box contains example output RDF triples or fragments
This section shows a set of relational tables, and logical tables defined on them (via SQL queries), with sample data that will be used to illustrate the R2RML constructs introduced in the next section.
Column Name | Column Datatype | Column Key Constraints |
---|---|---|
deptno |
INTEGER |
UNIQUE |
dname |
VARCHAR(30) |
|
loc |
VARCHAR(100) |
deptno | dname | loc |
---|---|---|
10 |
APPSERVER |
NEW YORK |
The following SQL query defines a logical table. Although this table does not have a name, for ease of reference we will use the name DEPT_L to refer to this table.
Select ('Department' || deptno) AS deptId , deptno , dname , loc from dept;
Names and datatypes of column names for the DEPT_L table can be derived from the SQL query and the underlying DEPT table:
Column Name | Column Datatype |
---|---|
deptId |
VARCHAR |
deptno |
INTEGER |
dname |
VARCHAR |
loc |
VARCHAR |
Content of the logical table DEPT_L is shown below:
deptId | deptno | dname | loc |
---|---|---|---|
Department10 |
10 |
APPSERVER |
NEW YORK |
A simple mapping of each row in the DEPT_L table may be specified using a TriplesMap consisting of a logical table defined using a SQL query (not shown here), a (single) SubjectMap and three PredicateObjectMaps.
# TriplesMap for DEPT_L TriplesMap: # ------------------ # logical table definition: see the SQL query for DEPT_L # ------------------ # subject (of the triples generated from a row) => value of the "deptId" column SubjectMap: [ rr:column "deptId"; rr:termtype "BlankNode" ] # ------------------ # PredicateObjectMap #1 => generates the (dept:deptno, "deptno" column-value) pairs PredicateObjectMap: # property => dept:deptno (the specified constant) PredicateMap: [ rr:predicate dept:deptno ] # object => value of the "deptno" column ObjectMap: [ rr:column "deptno"; rr:datatype xsd:positiveInteger ] # ------------------ # PredicateObjectMap #2 => generates the (dept:name, "dname" column-value) pairs PredicateObjectMap: # property => dept:name (the specified constant) PredicateMap: [ rr:predicate dept:name ] # object => value of the "dname" column ObjectMap: [ rr:column "dname" ] # ------------------ # PredicateObjectMap #3 => generates the (dept:location, "loc" column-value) pairs PredicateObjectMap: # property => dept:location (the specified constant) PredicateMap: [ rr:predicate dept:location ] # object => value of the "loc" column ObjectMap: [ rr:column "loc" ]
Given the sample data for the logical table referenced in the mapping, generation of RDF triples from each row of the logical table DEPT_L is done as follows.
generated subject => _:Department10
generated (predicate, object) pair => (dept:deptno, "10"^^xsd:positiveInteger)
generated (predicate, object) pair => (dept:name, "APPSERVER")
generated (predicate, object) pair => (dept:location, "NEW YORK")
generated RDF triples: _:Department10 dept:deptno "10"^^xsd:positiveInteger . _:Department10 dept:name "APPSERVER" . _:Department10 dept:location "NEW YORK" .
Column Name | Column Datatype | Column Key Constraint |
---|---|---|
empno |
INTEGER |
PRIMARY KEY |
ename |
VARCHAR(100) |
|
job |
VARCHAR(30) |
|
deptno |
INTEGER |
REFERENCES DEPT(deptno) |
etype |
VARCHAR(30) |
empno | ename | job | deptno | etype |
---|---|---|---|---|
7369 |
SMITH |
CLERK |
10 |
PART_TIME |
The following SQL query defines a logical table. Although this table does not have a name, for ease of reference we will use the name EMP_L to refer to this table.
Select ('http://example.com/emp/' || empno') AS empURI , empno , ename , ('http://example.com/emp/job/'|| job') AS jobTypeURI , job , deptno , ('http://example.com/emp/etype/'|| etype') AS empTypeURI , etype , ('http://example.com/graph/'|| job || '/' || etype') AS graphURI from SCOTT.EMP;
Names and datatypes of column names for the EMP_L table can be derived from the SQL query and the underlying EMP table:
Column Name | Column Datatype |
---|---|
empURI |
VARCHAR |
empno |
INTEGER |
ename |
VARCHAR |
jobTypeURI |
VARCHAR |
job |
VARCHAR |
deptno |
INTEGER |
empTypeURI |
VARCHAR |
etype |
VARCHAR |
graphURI |
VARCHAR |
Content of the logical table EMP_L is shown below:
empURI | empno | ename | jobTypeURI | job | deptno | empTypeURI | etype | graphURI |
---|---|---|---|---|---|---|---|---|
http://example.com/emp/7369 |
7369 |
SMITH |
http://example.com/emp/job/CLERK |
CLERK |
10 |
http://example.com/emp/etype/PART_TIME |
PART_TIME |
http://example.com/graph/CLERK/PART_TIME |
Column Name | Column Datatype | Column Key Constraint |
---|---|---|
id |
INTEGER |
|
likeType |
VARCHAR(30) |
|
likedObj |
VARCHAR(100) |
id | likeType | likedObj |
---|---|---|
7369 |
Playing |
Soccer |
7369 |
Watching |
Basketball |
The following SQL query defines a logical table. Although this table does not have a name, for ease of reference we will use the name LIKES_L to refer to this table.
Select ('http://example.com/emp/' || id') AS empId , ('http://example.com/emp/likes/' || likeType') AS empLikes , likedObj from SCOTT.LIKES;
Names and datatypes of column names for the LIKES_L table can be derived from the SQL query and the underlying LIKES table:
Column Name | Column Datatype |
---|---|
empid |
VARCHAR |
empLikes |
VARCHAR |
likedObj |
VARCHAR |
Content of the LIKES_L logical table is shown below:
empId | empLikes | likedObj |
---|---|---|
http://example.com/emp/7369 |
http://example.com/emp/likes/Playing |
Soccer |
http://example.com/emp/7369 |
http://example.com/emp/likes/Watching |
Basketball |
This section describes an RDF vocabulary that can be used for specifying an R2RML mapping for creating an RDF dataset (consisting of RDF triples in the default and/or named graphs) from one or more logical tables in a relational database.
The RDF vocabulary for R2RML consists of the following classes:
An element of this class, called a TriplesMap, contains the rules for generating the RDF triples for a row in the logical table that is being mapped.
This section defines the RDF properties that have the TriplesMapClass as their domain.
rr:tableOwner rdfs:range xsd:String . rr:tableName rdfs:range xsd:String . rr:SQLQuery rdfs:range xsd:String .
These properties are used to specify the logical table. This may be done either using rr:tableOwner and rr:tableName to specify the owner and the name of a table or view, or using rr:SQLQuery to specify a valid SQL query. A TriplesMap can reference exactly one logical table.
If rr:SQLQuery is used, the SQL query should not have duplicate column names or unnamed columns in the SELECT list. Also, for any database object referenced in a SQL query without an owner name, the owner name will be derived from the database connection at the time of processing of the mapping specification.
When using rr:tableName, use of rr:tableOwner is optional. If rr:tableOwner is not specified in a mapping, the table owner information for the table will be derived based upon the database connection at the time of processing of the mapping specification.
The following example shows a logical table specified as a SQL query.
[] rr:SQLQuery """Select ('Department' || deptno) AS deptId , deptno , dname , loc from SCOTT.DEPT""" .
The following example shows a logical table specified using table owner and table name information.
[] rr:tableOwner "SCOTT"; rr:tableName "DEPT".
ISSUE-34: “Table owner” is a somewhat vendor-specific term. It has been suggested that this should be better replaced with standard SQL terminology, such as “catalog” and “schema”.
rr:subjectMap rdfs:range rr:SubjectMapClass .
This property specifies a SubjectMap that contains the rules for generating the subject for a logical table row that will be used in all the RDF triples generated from the row.
[] rr:subjectMap [ rr:column "empURI" ]
rr:predicateObjectMap rdfs:range rr:PredicateObjectMapClass .
This property specifies a PredicateObjectMap that contains the rules for generating a (predicate, object) pair from a logical table row that will be combined with the subject for the row to generate an RDF triple.
[] rr:predicateObjectMap <#PredicateObjectMap1> .
rr:refPredicateObjectMap rdfs:range rr:RefPredicateObjectMapClass .
This property specifies a RefPredicateObjectMap that contains the rules for generating a (predicate, object) pair from a logical table row and the logical table row in another TriplesMap based upon a foreign key constraint.
[] rr:refPredicateObjectMap <#RefPredicateObjectMap1>;
An element of this class, called a SubjectMap, contains the rules for generating the subject for a row in the logical table being mapped.
This section defines the RDF properties that have SubjectMapClass as their domain.
rr:subject rdfs:range <Set of valid IRIs and blank nodes> .
This property specifes an RDF IRI or blank node. The specified value will be used as the subject for all the RDF triples from a logical table row. The following example shows its use:
[] rr:subject exa:dummySubject .
rr:column rdfs:range xsd:string .
This property specifies the name of a column in the logical table. The value in this column of a logical table row is used as the subject for all the RDF triples generated from the row. In the following example, the empURI column of the EMP_L table is specified as the source for the subject component of the generated RDF triples.
[] rr:column "empURI" .
Using the sample EMP_L data, the following subject value obtained from the empURI column of the EMP_L table will be used as the subject component for all the RDF triples generated from the EMP_L table row:
<http://example.com/emp/7369>
rr:termtype rdfs:range {"IRI", "BlankNode"} .
This property specifies an RDF term type. It is relevant in a SubjectMap only if the SubjectMap has a rr:column property or a rr:template property. The generated subject component will be of the specified RDF term type. The maximum cardinality of this property is 1. If not specified, the generated subject component will be an IRI.
rr:class rdfs:range rdfs:Class .
This optional property specifies an RDFS class. The subject value generated for a logical table row will be asserted as an instance of this RDFS class. In the following example, the generated subject will be asserted as an instance of the exa:emp class.
[] rr:class exa:emp .
Using the sample EMP_L data, the following RDF triple will be generated:
<http://example.com/emp/7369> rdf:type exa:emp .
Note: This property is merely a shortcut for specifying an rr:predicateObjectMap with predicate rdf:type and the class IRI as the object. To achieve a mapping where the class IRI is not constant but needs to be computed based on the contents of the database, one can explicitly define an rr:predicateObjectMap with a non-constant object using rr:template.
rr:graph rdfs:range <Set of valid IRI references> .
This optional property specifies a graph IRI. All the RDF triples generated from a logical table row will be stored in the specified named graph. A special IRI, rr:defaultGraph, may be used to specify that the generated triples should be stored in the default graph. If the user specifies the default graph and also one or more named graphs, then the generated triples will be stored in the default graph as well as in each of the specified named graphs.
In the following example, all the RDF triples generated from a logical table row will be in the named graph exa:DeptGraph.
[] rr:graph exa:DeptGraph .
Using the sample DEPT_L data the RDF triples generated from the only row will be stored in the following RDF named graph:
exa:DeptGraph
rr:graphColumn rdfs:range xsd:string .
This optional property specifies the name of a column in the logical table. The value from this column of a logical table row is used as the graph name where all the triples generated from a logical table row will be stored. There is no restriction on maximum cardinality of this property. If for a row, value from the specified column is NULL, then the triples generated from that row will be stored in the default graph. In the following example, all the RDF triples generated from a row in the EMP_L table will be stored in the graph name identified by the IRI from the "graphURI" column of the logical table.
[] rr:graphColumn "graphURI" .
Using the sample EMP_L data, all the RDF triples generated from the row will be stored in the following RDF named graph
<http://example.com/graph/CLERK/PART_TIME>
rr:inverseExpression rdfs:range xsd:string .
This optional property specifies an expression that allows, at query processing time, use of indexes on any (underlying) relational table when accessing based on a value of a column (defined as an expression) in the logical table. The specified expression must be usable in the WHERE clause of a SQL query. Specifically, all the column names must be actual column names in the associated logical table. Case-sensitive column names must be enclosed within curly braces.
For example, for the deptId column in the DEPT_L table, an inverse expression could be defined as follows:
[] rr:inverseExpression "{deptno} = substr({deptId},length('Department')+1)"
This facilitates the use of an existing index on the deptno column of the DEPT table.
rr:template rdfs:range xsd:string .
This optional property, for use in place of rr:column, specifies a template (or format string) to construct a value for use as a subject, based on values from one or more columns from a logical table row. Column names are case-sensitive and must be enclosed within curly braces. Use of curly braces in the template, for any purpose other than enclosing column names, must be escaped by a backslash character.
rr:graphTemplate rdfs:range xsd:string .
This optional property, for use in place of rr:graphColumn, specifies a template (or format string) to construct a value, for use as a graph IRI, based on one or more columns from a logical table row. Column names are case-sensitive and must be enclosed within curly braces. Use of curly braces in the template, for any purpose other than enclosing column names, must be escaped by a backslash character.
An element of this class, called a PredicateObjectMap, contains the rules for generating a (predicate, object) pair for a row in the logical table being mapped.
This section defines the RDF properties that have PredicateObjectMapClass as their domain.
rr:predicateMap rdfs:range rr:PredicateMapClass .
This property specifies the PredicateMap component of a PredicateObjectMap.
rr:objectMap rdfs:range rr:ObjectMapClass .
This property specifies the ObjectMap component of a PredicateObjectMap.
rr:graph rdfs:range <Set of valid IRI references> .
This optional property specifies a graph IRI. The RDF triple generated from a logical table row, containing the (predicate, object) pair from this PredicateObjectMap, will be stored in the specified named graph. A special IRI, rr:defaultGraph, may be used to specify that the generated triples should be stored in the default graph. If the user specifies the default graph and also one or more named graphs, then the generated triple will be stored in the default graph as well as in each of the specified named graphs.
The following shows an example that uses this property:
[] rr:graph exa:DeptGraph .
rr:graphColumn rdfs:range xsd:string .
This optional property specifies the name of a column in the logical table. The value from this column of a logical table row is used as the graph name where the RDF triple generated from a logical table row, containing the (predicate, object) pair from this PredicateObjectMap, will be stored. There is no restriction on maximum cardinality of this property. If for a row, value from the specified column is NULL, then the generated triple will be stored in the default graph. In the following example, the RDF triple generated from a row in the EMP_L table, containing (predicate, object) pair from this PredicateObjectMap will be stored in the graph name identified by the IRI from the "graphURI" column.
[] rr:graphColumn "graphURI" .
Using the sample EMP_L data, the generated RDF triple, containing the (predicate, object) pair from this PredicateObjectMap, will be stored in the following RDF named graph
<http://example.com/graph/CLERK/PART_TIME>
rr:graphTemplate rdfs:range xsd:string .
This optional property, for use in place of rr:graphColumn, specifies a template (or format string) to construct a value, for use as a graph IRI, based on one or more columns from a logical table row.
An element of this class, called a PredicateMap, contains the rules for generating the predicate component of the (predicate, object) pair generated by a PredicateObjectMap.
This section defines the RDF properties that have PredicateMapClass as their domain.
rr:predicate rdfs:range rdf:Property .
This property specifes an RDF property. The specified property will be used as the predicate for the generated triple. The following example shows its use in the context of the DEPT_L table.
[] rr:predicate dept:name .
rr:column rdfs:range xsd:string .
When the property name is not a constant and instead comes from the values in a column, this optional property (used in place of rr:predicate) allows the user to specify the column name. Note that this property should always be a column name in the logical table. The following example shows its use in the context of the LIKES_L table.
[] rr:column "empLikes" .
Using the sample LIKES_L data, the predicate components for the generated (property, object) pairs will be:
<http://example.com/emp/likes/Playing> <http://example.com/emp/likes/Watching>
rr:inverseExpression rdfs:range xsd:string .
This property is same as the rr:inverseExpression property described in the SubjectMapClass, but applies to PredicateMap.
rr:template rdfs:range xsd:string .
This optional property, for use in place of rr:column, specifies a template (or format string) to construct a value, for use as a predicate IRI, based on one or more columns from a logical table row. See rr:template for more details.
An element of this class, called a ObjectMap, contains the rules for generating the object component of the (predicate, object) pair generated by a PredicateObjectMap.
This section defines the RDF properties that have ObjectMapClass as their domain.
rr:object rdfs:range rdfs:Resource .
This property specifies an RDF term. The specified RDF term is used as object component of the (predicate, object) pair generated by a PredicateObjectMap. The maximum cardinality of this property is one and an ObjectMap must either have this property or the rr:column property, but not both. The following shows an example:
[] rr:object "EXAMPLE Corporation" .
rr:column rdfs:range xsd:string .
This property specifies the name of a column in the logical table. The object component of the (predicate, object) pair generated from a logical table row will use the value from the specified column. The maximum cardinality of this property is one and an ObjectMap must either have this property or the rr:object property, but not both. The following shows an example in the context of the DEPT_L table.
[] rr:column "dname" .
rr:termtype rdfs:range {"IRI", "BlankNode", "Literal"} .
This property specifies an RDF term type. It is relevant in an ObjectMap only if the ObjectMap has a rr:column property or a rr:template property. The generated object component will be of the specified RDF term type. The maximum cardinality of this property is 1. If not specified, the generated object component will be an RDF literal.
rr:datatype rdfs:range rdfs:Datatype .
This optional property specifies the datatype for the object component of the (predicate, object) pair generated by a PredicateObjectMap. It is relevant only if an ObjectMap has a rr:column property or a rr:template property and term type is "Literal". If not specified, the datatype for the object component will be derived as follows: if rr:template is used for obtaining the object value, then the datatype is assumed to be RDF plain literal; for rr:column, the datatype is derived from the column definition of the logical table. Maximum cardinality of this property is 1. The following shows an example of its use:
[] rr:column "deptno"; rr:datatype xsd:positiveInteger .
rr:language rdfs:range xsd:string .
This optional property specifies the language for the object component of the (predicate, object) pair generated by a PredicateObjectMap. This property is applicable only if the datatype of the object value is RDF plain literal and is relevant only if an ObjectMap has a rr:column property or a rr:template property. In the following example, the language tag for the object value component is specified to be US English.
[] rr:language "en-us" .
rr:inverseExpression rdfs:range xsd:string .
This property is same as the rr:inverseExpression property described in SubjectMapClass, but applies to ObjectMap.
rr:template rdfs:range xsd:string .
This optional property, for use in place of rr:column, specifies a template (or format string) to construct a value, for use as an object, based on values from one or more columns from a logical table row. See rr:template for more details.
An element of this class, called a RefPredicateObjectMap, contains the rules for generating a (predicate, object) pair from a logical table row based on a foreign key relationship. It consists of a RefPredicateMap and a RefObjectMap.
Conceptually, a RefPredicateObjectMap is similar to a PredicateObjectMap, but involves a child (or referring) table and a parent (or referred) table. The RefPredicateMap specifies how to generate the predicate component based on the key of the foreign key constraint definition in the child table and the RefObjectMap specifies how to generate the object component from the two logical tables, the child and the parent.
This section defines the RDF properties that have RefPredicateObjectMapClass as their domain.
rr:refPredicateMap rdfs:range rr:refPredicateMapClass .
This property specifies the RefPredicateMap component of a RefPredicateObjectMap.
rr:refObjectMap rdfs:range rr:RefObjectMapClass .
This property specifies the RefObjectMap component of a RefPredicateObjectMap.
rr:graph rdfs:range <Set of valid IRI references> .
This property is similar to rr:graph property. The following shows an example that uses this property:
[] rr:graph exa:DeptGraph .
rr:graphColumn rdfs:range xsd:string .
This property is similar to rr:graphColumn property. The following shows an example that uses this property.
[] rr:graphColumn "graphURI" .
rr:graphTemplate rdfs:range xsd:string .
This optional property, for use in place of rr:graphColumn, specifies a template (or format string) to construct a value, for use as a graph IRI, based on one or more columns from a logical table row.
An element of this class, called a RefPredicateMap, contains the rules for generating the predicate component of the (predicate, object) pair generated by a RefPredicateObjectMap.
This section defines the RDF properties that have RefPredicateMapClass as their domain.
rr:predicate rdfs:range rdf:Property .
This property specifies an RDF property. The specified property will be used as the predicate for the (predicate, object) pair generated by the RefPredicateObjectMap. In the following example, emp:c_ref_deptno is specified as the predicate for the (predicate, object) pair generated from a logical table row using a foreign key constraint.
[] rr:predicate emp:c_ref_deptno .
An element of this class, called a RefObjectMap, contains the rules for generating the object component of the (predicate, object) pair generated by a RefPredicateObjectMap.
This section defines the RDF properties that have RefObjectMapClass as their domain.
rr:parentTriplesMap rdfs:range rr:TriplesMap .
This property specifies the TriplesMap corresponding to the parent (or referenced) table component of the foreign key constraint. The following example identifies the TriplesMap corresponding to the parent (or referenced) logical table.
[] rr:parentTriplesMap <#TriplesMap1> .
rr:joinCondition rdfs:range xsd:string .
This property specifies the join condition for joining the (child) logical table in the current TriplesMap with the (parent) logical table specified by rr:parentTriplesMap.
Column names are case-sensitive. Also, the column names specified must follow either "{childAlias.}" or "{parentAlias.}". Use of curly braces in the template, for any other purpose must be escaped by a backslash character.
The following example shows a join condition to be used to obtain the object values from the parent logical table using values from the child logical table.
[] rr:joinCondition "{childAlias.}deptno = {parentAlias.}deptno" .
Note that the join condition may be as complex as allowed by SQL.
ISSUE-32:
The snytax of rr:joinCondition
is still
under discussion. It has been suggested that it should not use curly braces
to delimit the logical tables. It has also been suggested that instead of
arbitrary SQL, only simple equality expressions should be allowed.
Each triple generated from an R2RML mapping is placed into one or more target graphs. Possible target graphs are the unnamed default graph, and the IRI-named named graphs.
R2RML-generated blank nodes are scoped to a single graph. If the same blank node identifier occurs in 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.
Conformant R2RML processors MAY rename blank nodes when providing access to R2RML-mapped graphs. 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.
Property Name | Domain | Range | Cardinality | Notes |
---|---|---|---|---|
rr:tableOwner |
rr:TriplesMapClass |
xsd:string |
1 or 0 if rr:SQLQuery is absent, 0 if rr:SQLQuery is present |
Name of table owner. |
rr:tableName |
rr:TriplesMapClass |
xsd:string |
1 (only if rr:SQLQuery is absent), else 0 |
Name of a table or view. |
rr:SQLQuery |
rr:TriplesMapClass |
xsd:string |
1 (only if rr:tableOwner and rr:tableName are absent), else 0 |
A valid SQL query. |
rr:subjectMap |
rr:TriplesMapClass |
rr:SubjectMapClass |
1 |
A SubjectMap to generate a subject from a logical table row. |
rr:predicateObjectMap |
rr:TriplesMapClass |
rr:PredicateObjectMapClass |
min=0, max=unlimited |
A PredicateObjectMap to generate (predicate, object) pair
from a logical table row. |
rr:refPredicateObjectMap |
rr:TriplesMapClass |
rr:RefPredicateObjectMapClass |
min=0, max=unlimited |
A RefPredicateObjectMap to generate (predicate, object) pair
from a logical table row using a foreign key constraint definition. |
rr:subject |
rr:SubjectMapClass |
Set of valid RDF blank nodes and IRI references. |
min=0, max=1 (only if rr:column is absent) |
An IRI reference or a blank node for use as subject for all
the RDF triples generated from a logical table row. |
rr:column |
Union of rr:SubjectMapClass, rr:PredicateMapClass, rr:ObjectMapClass |
xsd:string |
min=0, max=1 (only if rr:subject/rr:predicate/rr:object is absent) |
Name of a column in the logical table. When generating RDF triples from
a logical table row, value from the specified column is used as the subject,
predicate, or object (based upon the specific domain). |
rr:termtype |
Union of rr:SubjectMapClass, rr:ObjectMapClass |
{"IRI","BlankNode","Literal"}, but "Literal" is not valid for
a SubjectMap |
min=0, max=1 |
A string indicating whether subject or object generated using
the value from column name specified for rr:column should be
an IRI reference, blank node, or (if object) a literal. |
rr:class |
rr:SubjectMapClass |
rdfs:Class |
min=0, max=unlimited |
The subject value generated for a logical table row will be
asserted as an instance of this RDFS class. |
rr:graph |
Union of rr:SubjectMapClass, rr:PredicateObjectMapClass, rr:RefPredicateObjectMapClass |
Set of valid IRI references |
min=0, max=unlimited |
Specifies a graph IRI reference. When used with a SubjectMap,
all the RDF triples generated from a logical row will be stored in
the specified named graph. Otherwise, the RDF triple generated using
the (predicate, object) pair will be stored in the specified named
graph. |
rr:graphColumn |
Union of rr:SubjectMapClass, rr:PredicateObjectMapClass, rr:RefPredicateObjectMapClass |
Set of valid IRI references |
min=0, max=unlimited |
Specifies a column name in the logical table as the source for
graph IRI reference. When used with a SubjectMap,
all the RDF triples generated from a logical row will be stored in
the named graph whose IRI reference is generated from the specified
column value. Otherwise, the RDF triple generated using
the (predicate, object) pair will be stored in the named
graph. |
rr:inverseExpression |
Union of rr:SubjectMapClass, rr:PredicateMapClass, rr:ObjectMapClass |
xsd:string |
min=0, max=1 |
An expression that allows, at query processing time, use of
index-based access to the the (underlying) relational tables, instead
of simply retrieving the table rows first and then applying a
filter. This property is useful for retrieval based on conditions
involving subject, predicate, or object generated from
logical table column(s) and involves some transformation. |
rr:template |
Union of rr:SubjectMapClass, rr:PredicateMapClass, rr:ObjectMapClass |
xsd:string |
min=0, max=1 (only if rr:subject/rr:predicate/rr:object and rr:column are absent) |
A template (format string) to specify how to generate a value for a subject,
predicate, or object, using one or more columns from
a logical table row. |
rr:graphTemplate |
Union of rr:SubjectMapClass, rr:PredicateObjectMapClass, rr:RefPredicateObjectMapClass |
xsd:string |
min=0, max=unlimited |
A template (or format string) to specify how to generate a value for
use as a graph IRI using one or more columns from
a logical table row. |
rr:predicateMap |
rr:PredicateObjectMapClass |
rr:PredicateMapClass |
1 |
A PredicateMap to generate the predicate component of the (predicate, object) pair
from a logical table row. |
rr:objectMap |
rr:PredicateObjectMapClass |
rr:ObjectMapClass |
1 |
An ObjectMap to generate the object component of the (predicate, object) pair
from a logical table row. |
rr:predicate |
Union of rr:PredicateMapClass and rr:RefPredicateMapClass |
rdf:Property |
min=0, max=1 (only if rr:column is absent) |
Specifies the predicate for the generated triple from the logical
table row. |
rr:object |
rr:ObjectMapClass |
rdfs:Resource |
min=0, max=1 (only if rr:column is absent) |
Specifies the object for the generated triple from the logical table row. |
rr:datatype |
rr:ObjectMapClass |
rdfs:Datatype |
min=0, max=1 (only if rr:termtype is not an IRI or blank node) |
Specifies the datatype of the object component for the generated triple
from a logical table row. |
rr:language |
rr:ObjectMapClass |
xsd:string |
min=0, max=1 (only if rr:dataype is absent and rr:termtype is not an IRI or blank node) |
Specified the language for the object component for the generated triple
from a logical table row. |
rr:refPredicateMap |
rr:RefPredicateObjectMapClass |
rr:RefPredicateMapClass |
1 |
A RefPredicateMap to generate the predicate component of the (predicate, object)
pair from a logical table row using a foreign key constraint definition. |
rr:refObjectMap |
rr:RefPredicateObjectMapClass |
rr:RefObjectMapClass |
1 |
A RefObjectMap to generate the object component of the (predicate, object)
pair from a logical table row using a foreign key constraint definition. |
rr:parentTriplesMap |
rr:RefObjectMapClass |
rr:TriplesMapClass |
1 |
Specifies the TriplesMap corresponding to the parent logical table of the foreign
key constraint. |
rr:joinCondition |
rr:RefObjectMapClass |
xsd:string |
1 |
Specifies the join condition for joining the child logical table with the parent
logical table of the foreign key constraint. |
In this section we show an example relational schema and then map the example schema to RDF using the Turtle syntax.
We illustrate our example with the use of the following three relational tables, along with sample data.
Column Name | Column Datatype | Column Key Constraints |
---|---|---|
deptno |
INTEGER |
UNIQUE |
dname |
VARCHAR(30) |
|
loc |
VARCHAR(100) |
deptno | dname | loc |
---|---|---|
10 |
APPSERVER |
NEW YORK |
Column Name | Column Datatype | Column Key Constraint |
---|---|---|
empno |
INTEGER |
PRIMARY KEY |
ename |
VARCHAR(100) |
|
job |
VARCHAR(30) |
|
deptno |
INTEGER |
REFERENCES DEPT(deptno) |
etype |
VARCHAR(30) |
empno | ename | job | deptno | etype |
---|---|---|---|---|
7369 |
SMITH |
CLERK |
10 |
PART_TIME |
Column Name | Column Datatype | Column Key Constraint |
---|---|---|
id |
VARCHAR(4000) |
|
likeType |
VARCHAR(30) |
|
likedObj |
VARCHAR(100) |
id | likeType | likedObj |
---|---|---|
7369 |
Playing |
Soccer |
7369 |
Watching |
Basketball |
The tables specified in the above section are mapped to the RDF using the mapping specificied in this document. The table below the TriplesMap shows the insatnce-level RDF triples generated from the sample data in the tables. In addition to the prefix conventions specified in Document Conventions, we also use the following prefixes in our examples:
Prefix | IRI |
---|---|
emp: |
http://www.example.com/emp# |
dept: |
http://www.example.com/dept# |
likes: |
http://www.example.com/likes# |
<#TriplesMap1> a rr:TriplesMapClass; rr:SQLQuery """ Select ('Department' || "deptno") AS "deptId" , "deptno" , "dname" , "loc" from SCOTT.DEPT """; rr:subjectMap [ rr:column "deptId"; rr:termtype "BlankNode"; rr:class exa:dept; rr:graph exa:DeptGraph; rr:inverseExpression "{deptno} = substr({deptId},length('Department')+1)"]; rr:predicateObjectMap [ rr:predicateMap [ rr:predicate dept:deptno ]; rr:objectMap [ rr:column "deptno"; rr:datatype xsd:positiveInteger ] ]; rr:predicateObjectMap [ rr:predicateMap [ rr:predicate dept:name ]; rr:objectMap [ rr:column "dname" ] ]; rr:predicateObjectMap [ rr:predicateMap [ rr:predicate dept:location ]; rr:objectMap [ rr:column "loc" ] ]; rr:predicateObjectMap [ rr:predicateMap [ rr:predicate dept:COMPANY ]; rr:objectMap [ rr:object "EXAMPLE Corporation" ] ] .
Content of the logical table used in this mapping:
deptId | deptno | dname | loc |
---|---|---|---|
Department10 |
10 |
APPSERVER |
NEW YORK |
The set of RDF triples generated using the above mapping:
The graph name for the following triples is generated using the rr:graph property.
Graph | Subject | Predicate | Object |
---|---|---|---|
exa:DeptGraph |
_:Department10 |
rdf:type |
exa:dept |
exa:DeptGraph |
_:Department10 |
dept:deptno |
"10"^^xsd:positiveInteger |
exa:DeptGraph |
_:Department10 |
dept:name |
"APPSERVER" |
exa:DeptGraph |
_:Department10 |
dept:location |
"NEW YORK" |
exa:DeptGraph |
_:Department10 |
dept:COMPANY |
"EXAMPLE Corporation" |
Two equivalent mapping specifications are shown below. The main difference between the two specifications is that one uses rr:SQLQuery to define the logical table and the other uses rr:tableOwner and rr:tableName to define the logical table.
A mapping specification for EMP table that uses a SQL query for defining the logical table:
<#TriplesMap2> a rr:TriplesMapClass; rr:SQLQuery """ Select ('http://example.com/emp/' || "empno") AS "empURI" , "empno" , "ename" , ('http://example.com/emp/job/'|| "job") AS "jobTypeURI" , "job" , "deptno" , ('http://example.com/emp/etype/'|| "etype") AS "empTypeURI" , "etype" , ('http://example.com/graph/'|| "job" || '/' || "etype") AS "graphURI" from SCOTT.EMP """; rr:subjectMap [ rr:column "empURI"; rr:class exa:emp; rr:graphColumn "graphURI" ]; rr:predicateObjectMap [ rr:predicateMap [ rr:predicate emp:jobtype ]; rr:objectMap [ rr:column "jobTypeURI" ] ]; rr:predicateObjectMap [ rr:predicateMap [ rr:predicate rdf:type ]; rr:objectMap [ rr:column "jobTypeURI" ] ]; rr:predicateObjectMap [ rr:predicateMap [ rr:predicate emp:emptype ]; rr:objectMap [ rr:column "empTypeURI" ] ]; rr:predicateObjectMap [ rr:predicateMap [rdf:predicate rdf:type ]; rr:objectMap [ rr:column "empTypeURI" ] ]; rr:predicateObjectMap [ rr:predicateMap [ rr:predicate emp:empno ]; rr:objectMap [ rr:column "empno" ] ]; rr:predicateObjectMap [ rr:predicateMap [ rr:predicate emp:name ]; rr:objectMap [ rr:column "ename" ]; rr:graph emp:empNameGraph ]; rr:predicateObjectMap [ rr:predicateMap [ rr:predicate emp:job ]; rr:objectMap [ rr:column "job" ] ] rr:predicateObjectMap [ rr:predicateMap [ rr:predicate emp:deptNum ]; rr:objectMap [ rr:column "deptno" ] ]; rr:predicateObjectMap [ rr:predicateMap [ rr:predicate emp:etype ]; rr:objectMap [ rr:column "etype" ] ]; rr:refPredicateObjectMap [ rr:refPredicateMap [ rr:predicate emp:c_ref_deptno ]; rr:refObjectMap [ rr:parentTriplesMap <#TriplesMap1>; rr:joinCondition "{childAlias.}deptno = {parentAlias.}deptno" ] ] .
An alternative way of specifying the same mapping for EMP that uses table owner and table name for defining the logical table:
<#TriplesMap2> a rr:TriplesMapClass; rr:tableOwner "SCOTT"; rr:tableName "EMP"; rr:subjectMap [ rr:template "http://example.com/emp/{empno}"; rr:class exa:emp; rr:graphTemplate "http://example.com/graph/{job}/{etype}" ]; rr:predicateObjectMap [ rr:predicateMap [ rr:predicate emp:jobtype ]; rr:objectMap [ rr:template "http://example.com/emp/job/{job}" ] ]; rr:predicateObjectMap [ rr:predicateMap [ rr:predicate rdf:type ]; rr:objectMap [ rr:template "http://example.com/emp/job/{job}" ] ]; rr:predicateObjectMap [ rr:predicateMap [ rr:predicate emp:emptype ]; rr:objectMap [ rr:template "http://example.com/emp/etype/{etype}" ] ]; rr:predicateObjectMap [ rr:predicateMap [ rr:predicate rdf:type ]; rr:objectMap [ rr:template "http://example.com/emp/etype/{etype}" ] ]; rr:predicateObjectMap [ rr:predicateMap [ rr:predicate emp:empno ]; rr:objectMap [ rr:column "empno" ] ]; rr:predicateObjectMap [ rr:predicateMap [ rr:predicate emp:name ]; rr:objectMap [ rr:column "ename" ]; rr:graph emp:empNameGraph ]; rr:predicateObjectMap [ rr:predicateMap [ rr:predicate emp:job ]; rr:objectMap [ rr:column "job" ] ] rr:predicateObjectMap [ rr:predicateMap [ rr:predicate emp:deptNum ]; rr:objectMap [ rr:column "deptno" ] ]; rr:predicateObjectMap [ rr:predicateMap [ rr:predicate emp:etype ]; rr:objectMap [ rr:column "etype" ] ]; rr:refPredicateObjectMap [ rr:refPredicateMap [ rr:predicate emp:c_ref_deptno ]; rr:refObjectMap [ rr:parentTriplesMap <#TriplesMap1>; rr:joinCondition "{childAlias.}deptno = {parentAlias.}deptno" ] ] .
An alternative way of specifying the same mapping for EMP, showing reuse of ObjectMaps:
<#jobtypeObjectMap> a rr:ObjectMapClass; rr:template "http://example.com/emp/job/{job}" . <#emptypeObjectMap> a rr:ObjectMapClass; rr:template "http://example.com/emp/etype/{etype}" . <#TriplesMap2> a rr:TriplesMapClass; rr:tableOwner "SCOTT"; rr:tableName "EMP"; rr:subjectMap [ rr:template "http://example.com/emp/{empno}"; rr:class exa:emp; rr:graphTemplate "http://example.com/graph/{job}/{etype}" ]; rr:predicateObjectMap [ rr:predicateMap [ rr:predicate emp:jobtype ]; rr:objectMap <#jobtypeObjectMap> ]; rr:predicateObjectMap [ rr:predicateMap [ rr:predicate rdf:type ]; rr:objectMap <#jobtypeObjectMap> ]; rr:predicateObjectMap [ rr:predicateMap [ rr:predicate emp:emptype ]; rr:objectMap <#emptypeObjectMap> ]; rr:predicateObjectMap [ rr:predicateMap [ rr:predicate rdf:type ]; rr:objectMap <#emptypeObjectMap> ]; rr:predicateObjectMap [ rr:predicateMap [ rr:predicate emp:empno ]; rr:objectMap [ rr:column "empno" ] ]; rr:predicateObjectMap [ rr:predicateMap [ rr:predicate emp:name ]; rr:objectMap [ rr:column "ename" ]; rr:graph emp:empNameGraph ]; rr:predicateObjectMap [ rr:predicateMap [ rr:predicate emp:job ]; rr:objectMap [ rr:column "job" ] ] rr:predicateObjectMap [ rr:predicateMap [ rr:predicate emp:deptNum ]; rr:objectMap [ rr:column "deptno" ] ]; rr:predicateObjectMap [ rr:predicateMap [ rr:predicate emp:etype ]; rr:objectMap [ rr:column "etype" ] ]; rr:refPredicateObjectMap [ rr:refPredicateMap [ rr:predicate emp:c_ref_deptno ]; rr:refObjectMap [ rr:parentTriplesMap <#TriplesMap1>; rr:joinCondition "{childAlias.}deptno = {parentAlias.}deptno" ] ] .
Content of the logical table used in this mapping:
empURI | empno | ename | jobTypeURI | job | deptno | empTypeURI | etype | graphURI |
---|---|---|---|---|---|---|---|---|
http://example.com/emp/7369 |
7369 |
SMITH |
http://example.com/emp/job/CLERK |
CLERK |
10 |
http://example.com/emp/etype/PART_TIME |
PART_TIME |
http://example.com/graph/CLERK/PART_TIME |
The set of RDF triples generated using the above mapping (the two generated graphs are shown separately below):
The graph name for the following triples is generated using the rr:graphColumn property).
Graph | Subject | Predicate | Object |
---|---|---|---|
<http://example.com/graph/CLERK/PART_TIME> |
<http://example.com/emp/7369> |
rdf:type |
exa:emp |
<http://example.com/graph/CLERK/PART_TIME> |
<http://example.com/emp/7369> |
emp:jobtype |
<http://example.com/emp/job/CLERK> |
<http://example.com/graph/CLERK/PART_TIME> |
<http://example.com/emp/7369> |
rdf:type |
<http://example.com/emp/job/CLERK> |
<http://example.com/graph/CLERK/PART_TIME> |
<http://example.com/emp/7369> |
emp:emptype |
<http://example.com/emp/etype/PART_TIME> |
<http://example.com/graph/CLERK/PART_TIME> |
<http://example.com/emp/7369> |
rdf:type |
<http://example.com/emp/etype/PART_TIME> |
<http://example.com/graph/CLERK/PART_TIME> |
<http://example.com/emp/7369> |
emp:empno |
"7369"^^xsd:integer |
<http://example.com/graph/CLERK/PART_TIME> |
<http://example.com/emp/7369> |
emp:name |
"SMITH" |
<http://example.com/graph/CLERK/PART_TIME> |
<http://example.com/emp/7369> |
emp:job |
"CLERK" |
<http://example.com/graph/CLERK/PART_TIME> |
<http://example.com/emp/7369> |
emp:deptNum |
"10"^^xsd:integer |
<http://example.com/graph/CLERK/PART_TIME> |
<http://example.com/emp/7369> |
emp:etype |
"PART_TIME" |
<http://example.com/graph/CLERK/PART_TIME> |
<http://example.com/emp/7369> |
emp:c_ref_deptno |
_:Department10 |
The graph name for the following triple is generated using the rr:graph property.
Graph | Subject | Predicate | Object |
---|---|---|---|
emp:empNameGraph |
<http://example.com/emp/7369> |
emp:name |
"SMITH" |
<#TriplesMap3> a rr:TriplesMapClass; rr:SQLQuery " Select ('http://example.com/emp/' || "id") AS "empId" , ('http://example.com/emp/likes/' || "likeType") AS "empLikes" , "likedObj" from SCOTT.LIKES "; rr:subjectMap [ rr:column "empId"; rr:graph exa:LikesGraph ]; rr:predicateObjectMap [ rr:predicateMap [ rr:column "empLikes" ]; rr:objectMap [ rr:column "likedObj" ] ] .
Content of the logical table used in this mapping:
empId | empLikes | likedObj |
---|---|---|
http://example.com/emp/7369 |
http://example.com/emp/likes/Playing |
Soccer |
http://example.com/emp/7369 |
http://example.com/emp/likes/Watching |
Basketball |
The set of RDF triples generated using the above mapping:
The graph name for the following triples is generated using the rr:graph property.
Graph | Subject | Predicate | Object |
---|---|---|---|
exa:LikesGraph |
<http://example.com/emp/7369> |
<http://example.com/emp/likes/Playing> |
"Soccer" |
exa:LikesGraph |
<http://example.com/emp/7369> |
<http://example.com/emp/likes/Watching> |
"Basketball" |
The editors gratefully acknowledge contributions from the members of the W3C RDB2RDF Working Group: Marcelo Arenas, Sören Auer, Samir Batla, Richard Cyganiak, Souripriya Das, Alexander de Leon, Orri Erling, Lee Feigenbaum, Enrico Franconi, Howard Greenblatt, Wolfgang Halb, Harry Halpin, Michael Hausenblas, Patrick Hayes, Ivan Herman, Nophadol Jekjantuk, Nuno Lopes, Li Ma, Nan Ma, Ashok Malhotra, David McNeil, Ivan Mikhailov, Eric Prud'hommeaux, Percy Enrique Rivera Salas, Juan Sequeda, Seema Sundara, Ben Szekely, Ted Thibodeau, Edward Thomas, and Boris Villazón-Terrazas.
$Log: Overview.html,v $ Revision 1.5 2018/10/09 13:24:15 denis fix validation of xhtml documents Revision 1.4 2017/10/02 10:43:55 denis add fixup.js to old specs Revision 1.3 2011/03/23 08:04:45 ivan Updated some URI-s that referred to /TR/2010 instead of /TR/2011 Revision 1.2 2011/03/23 07:57:56 ivan Initial version of the WD copy 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