RDF-izing Tabular Data¶

The Value Source¶

This is the source of the value in the associated position, it can be one of the following:

• Column: the value of the cell in the mentioned column
• Constant: a constant value
• Record ID: The record identifier from the OpenRefine project
• Row Index: The index of the row
• GREL: a GREL expression

The Value Type¶

The value type defines the type of RDF value that will be produced by the value mapping. The possible types are:

• Resource (abstract): An RDF resource. This is an abstract type that specifies the common features of IRIs and blank nodes. A resource value type may have type mappings and property mappings on its own.
• IRI: An RDF IRI. The transformed value is the IRI with illegal characters escaped automatically. This is a subtype of the abstract Resource value type.
• Blank node based on value: (value Bnode) An RDF blank node. The transformed value is used to calculate a reasonable blank node identifier such that identical transformed values produce the same blank node. This is a subtype of the abstract Resource value type.
• Unique blank node: (unique Bnode) An RDF blank node. The transformed value is ignored and a unique blank node is created every time. This is a subtype of the abstract Resource value type.
• Any literal (abstract): Any kind of RDF literal (plain, language, or datatype). This is an abstract type that unifies all literal value types.
• Literal: An RDF plain literal. The transformed value is the literal’s label.
• Literal with a language: An RDF literal with a language. The transformed value is the literal’s label. The language is a simple literal value mapping, i.e., identical to a value mapping with type literal.
• Literal with a datatype: An RDF literal with a datatype. The transformed value is the literal’s label. The datatype is a simple IRI value mapping.

This window shows how to produce a xsd:gYear typed literal from the values of the startYear column.

The Value Transformation¶

Each value mapping may have an optional transformation, applied to the data received from the value source, before the value is created.

Refine supports two types of transformations:

• GREL: A GREL expression defines the transformation
• Prefixing: a known prefix is applied to the value and the result is given the IRI data type

This window shows a GREL expression being used to construct a URL from the values of the tconst column.

Note the instant preview of the result of the GREL expression.

The Mapping Variables¶

Values from the input table are mapped to variables, named after the corresponding columns, prefixed with a c_.

These variables are not readily available and they must be mentioned in a BIND() statement in order to be activated.

The values are always initially typed as strings and we recommend using the same BIND() statement to handle any data type conversions. If the desired datatype is string, the variable still needs to be bound as a variable with a different name.

Here is an example with the following conversions:

• the contents of the startYear is converted to a literal with a xsd:gYear data type,
• the runtimeMinutes column is converted to an integer,
• the primaryTitle column is not converted and remains a string.

BIND(STRDT(?c_startYear,xsd:year) AS ?startYear )
BIND(STRDT(?c_runtimeMinutes,xsd:integer) AS ?runtimeMinutes )
BIND( ?c_primaryTitle AS ?primaryTitle )

The Row and Record index¶

Two more variables are reserved by the SPARQL mapping. They correspond to OpenRefine project metadata:

• ?row_index contains the index of the row being processed
• ?record_id contains the id of the record being processed (if in record mode)

The mapper:grel Magic Predicate¶

GREL expressions can be used directly in the SPARQL query, using the mapper:grel magic predicate.

The subject part of the triple contains an expression with two arguments, the ?rowIndex and a string corresponding to the GREL expression itself. The variable in the object position contains the result.

(?row_index "replace(cells['column_A'].value,'foo','bar'") mapper:grel ?result .

Generate a Query from the Visual RDF Mapper¶

If the user has defined a mapping by using the Visual RDF Mapper, the Generate Query ‣ From Mapping menu item will translate the mapping to a SPARQL CONSTRUCT query.

This SPARQL query:

CONSTRUCT {
  ?s1 a mdbo:Movie ;
      mdbo:title ?o_title ;
      mdbo:year ?o_year .
} WHERE {
  BIND(IRI(mapper:encode_iri(movie:, ?c_tconst)) as ?s1)
  BIND(STR(?c_primaryTitle) as ?o_title)
  BIND(STRDT(?c_startYear, xsd:gYear) as ?o_year)
}

Has been automatically generated from the following visual mapping:

Generate a Query from Template¶

If a user wants to start directly working with SPARQL, the Generate Query ‣ Standard Template option is the easiest way to start.

This feature will produce a SELECT query with all the BIND() statements, corresponding to the columns of the tabular data.

The recommended workflow in this scenario is the following:

• First the user chooses which columns he needs and removes the unneeded BIND() statements
• Second, he fixes any data type issues, directly in the BIND() statements using STRDT() .
• He finally crafts the URIs so they fit the URI format of his project.

This is an iterative process the user can execute the query many times in order to inspect the results.

Once satisfied, the user changes the SELECT to a CONSTRUCT query and defines the shape of the output RDF graph.

The result in Turtle format can then be downloaded using the Download ‣ Result menu item.

Alternatively if the project has too many columns, the individual BIND() statements can be generated one by one by clicking on the names of the columns in the top band.

Saving the Mapping Queries¶

All the mapping queries in the SPARQL Query Editor are saved as part of the Refine project. This is done after clicking on the Save button but is only effective for queries after they have been executed.

The queries can also be saved using the Download ‣ Query menu item.