It’s all about the triples

Looking at this table closely, we see that each row is reduced to the most elementary statement you can make from the data. A row no longer tells you the measurements (observations) all attributes (variables) of a given species (key), instead, you get just one fact per row, Mazda RX4 gets a mpg measurement of 21.0. In RDF-world, we think of these three-part statements as something very special, which we call triples. RDF is all about these triples.

The first column came from the row names in this case, the Model of car. This acts serves as a key to index the data.frame, i.e. the subject being described. The next column is the variable (also called attribute or property) being measured, (that is, column names, other than the key column(s), from the tidy data), called the property or predicate in RDF-speak (slash grammar-school jargon). The third column is the actual value measured, more object of the predicate. Call it key-property-value or subject-predicate-object, these are our triples. We can represent just about any data in fully elementary manner.

Table 1 summarizes the many different names associated with triples. The first naming convention is the terminology typically associated with RDF. The second set are terms typically associated with JSON data, while the remaining are all examples in tabular or relational data structures.

Subject URIs

Using row names as our subject was intuitive but actually a bit sloppy. tidyverse lovers know that tidyverse doesn’t like rownames, they aren’t tidy and have a way of causing trouble. Of course, we made rownames into a proper column to use gather, but we could have taken this one step further. In true tidyverse fashion, this rownames-column is really just one more variable we can observe, one more attribute of the thing we were describing: say, thing A (Car A) is a car_model_name as Mazda RX4 and thing A also has mpg of 21. We can accomplish such a greater level of abstraction by keeping the Model as just another variable the row ids themselves as the key (i.e. the subject) of our triple:

car_triples <- 
mtcars %>% 
  rownames_to_column("Model") %>% 
  rowid_to_column("subject") %>% 
  gather(predicate, object, -subject)

This is identical to a gather of all columns, where we have just made the original row ids an explicit column for reference (diligent reader will recognize we would need this information to reverse the operation and spread the data back into it’s wide form; without it, our transformation is lossy and irreversible). Our subject column now consists only of simple numeric id’s, while we have gained an additional triple for every row in the original data which states Model of each id number (e.g. 1 is Model Mazda RX4). Okay, now you’re probably thinking: “wait a minute, 1 is not a very unique or specific key, surely that will cause trouble,” and you’d be right. For instance, if we performed the same transformation on the iris data, we get triples in the exact same format, ready to bind_rows:

iris_triples <- iris %>%
  rowid_to_column("subject") %>%
  gather(key = predicate, value = object, -subject)

but in the iris data, 1 corresponds to the first individual Iris flower in the measurement data, and not a Mazda RX4. If we don’t want to get confused, we’re going to need to make sure our identifiers are unique: not just kind of unique, but unique in the World wide. And what else is unique world-wide? Yup, you guessed it, we are going to use URLs for our subject identifiers, just like the world wide web. Think of this as a clever out-sourcing to the whole internet domain registry service. Here, we’ll imagine registering each of these example datasets with a separate base URL, so instead of a vague 1 to identify the first observation in the iris example data, we’ll use the URL http://example.com/iris#1, which we can now distinguish from http://example.com/mtcars#1 (and if you’re way ahead of me, yes, we’ll have more to say about URI vs URL and the use of blank nodes in just a minute). For example:

iris_triples <- iris %>%
  rowid_to_column("subject") %>%
  mutate(subject = paste0("http://example.com/", "iris#", subject)) %>%
  gather(key = predicate, value = object, -subject)

Predicate URIs

A slightly more subtle version of the same problem can arise with our predicates. Different tables may use the same attribute (i.e. originally, a column name of a variable) for different things – the attribute labeled cyl means “number of cylinders” in mtcars data.frame, but could mean something very different in different data. Luckily we’ve already seen how to make names unique in RDF turn them into URLs.

iris_triples <- iris %>%
  rowid_to_column("subject") %>%
  mutate(subject = paste0("http://example.com/", "iris#", subject)) %>%
  gather(key = predicate, value = object, -subject) %>%
  mutate(predicate = paste0("http://example.com/", "iris#", predicate))

At this point the motivation for the name “Linked Data” is probably becoming painfully obvious.

Datatype URIs

One more column to go! But wait a minute, the object column is different, isn’t it? These measurements don’t suffer from the same ambiguity – after all, there is no confusion if a car has 4 cylinders and an iris has 4 mm long sepals. However, a new issue has arisen in the data type (e.g. string, boolean, double, integer, dateTime, etc). A close look reveals our object column is encoded as a character and not numeric – how’d that happen? tidyr::gather has coerced the whole column into character strings because some of the values, that is, the Species names in iris and the Model names in mtcars, are text strings (and it couldn’t exactly coerce them into integers). Perhaps this isn’t a big deal – we can often guess the type of an object just by how it looks (so-called Duck typing, because if it quacks like duck…). Still, being explicit about data types is a Good Thing, so fortunately there’s an explicit way to address this too … oh no … not … yes … more URLs!

Luckily we don’t have to make up example.com URLs this time because there’s already a well-established list of data types widely used across the internet that were originally developed for use in XML (I warned you) Schemas, listed in see the W3C RDF DataTypes. As the standard shows, familiar types string, double, boolean, integer, etc are made explicit using the XML Schema URL: http://www.w3.org/2001/XMLSchema#, followed by the type; so an integer would be `http://www.w3.org/2001/XMLSchema#integer, a character string http://www.w3.org/2001/XMLSchema#string etc.

Because this case is a little different, the URL is attached directly after the object value, which is set off by quotes, using the symbol ^^ (I dunno, but I think two duck feet), such that 5.1 becomes "5.1"^^http://www.w3.org/2001/XMLSchema#double. Wow². Most of the time we won’t have to worry about the type, because, if it quacks…

Triples in rdflib

So far, we have explored the concept of triples using familiar data.frame structures, but haven’t yet introduced any rdflib functions. Though we’ve been thinking of RDF data in this explicitly tabular three-column structure, that is really just one potentially convenient representation. Just as the same tabular data can be represented in a data.frame, written to disk as a .csv file, or stored in a database (like MySQL or PostgreSQL), so it is for RDF to even greater degree. We have separate abstractions for the information itself compared to how it is represented.

To take advantage of this abstraction, rdflib introduces an rdf class object. Depending on how this is initialized, this could utilize storage in memory (the default), on disk, or potentially in an array of different databases, (including relational databases like PostgreSQL and rdf-specific ones like Virtuoso, depending on how the underlying redland library is compiled – a topic beyond our scope here). Here, we simply initialize an rdf object using the default in-memory storage:

rdf <- rdf()

To add triples to this rdf object (often called an RDF Model or RDF Graph), we use the function rdf_add, which takes a subject, predicate, and object as arguments, as we have just discussed. A datatype URI can be inferred from the R type used for the object (e.g. numeric, integer, logical, character, etc.)

base <- paste0("http://example.com/", "iris#")

rdf %>% 
  rdf_add(subject = paste0(base, "obs1"), 
          predicate = paste0(base, "Sepal.Length"), 
          object = 5.1)

rdf

The result is displayed as a triple discussed above. This is technically an example of the nquad notation we will see later. Note the inferred datatype URI.

rdf <- rdf()
rdf %>% rdf_add("",   
                "iris:Sepal.Length", 
                object = 5.1)
rdf

rdf_serialize(rdf, "rdf.nq", format = "nquads")

doc <- system.file("extdata/example.rdf", package="redland")
rdf <- rdf_parse(doc, format = "rdfxml") 
rdf

options(rdf_print_format = "rdfxml")
rdf

options(rdf_print_format = "turtle")
rdf

options(rdf_print_format = "jsonld")
rdf

rdf_serialize(rdf, "example.json", "jsonld") %>% 
  jsonld_compact(context = '{"@vocab": "http://purl.org/dc/elements/1.1/"}')

ex <- system.file("extdata/person.json", package="rdflib")
cat(readLines(ex), sep = "\n")
#jsonld_compact(ex, "{}")

options(rdf_print_format = "nquads")
rdf <- rdf_parse(ex, "jsonld")
rdf

jsonld_flatten(ex, context = "https://schema.org/")

jsonld_flatten(ex) %>%
  jsonld_frame('{"@type": "https://schema.org//Person"}') %>%
  jsonld_compact(context = "https://schema.org/")

as_rdf.list <- function(x, context = "https://schema.org/"){
  if(length(x) == 1) x <- x[[1]]
  x[["@context"]] <- context
  json <- jsonlite::toJSON(x, pretty = TRUE, auto_unbox = TRUE, force = TRUE)
  rdflib::rdf_parse(json, "jsonld")
}

context <- list("https://schema.org/", 
                list(schema = "https://schema.org//",
                     given = "givenName",
                     family = "familyName",
                     title = "name",
                     year = "datePublished",
                     note = "softwareVersion",
                     comment = "identifier",
                     role = "https://www.loc.gov/marc/relators/relaterm.html"))

options(rdf_print_format = "nquads") # go back to the default


R <- citation("rdflib")
rdf <- as_rdf.list(R, context)
rdf  

#source(system.file("examples/as_rdf.R", package="rdflib"))
source(system.file("examples/tidy_schema.R", package="rdflib"))

## Testing: Digest some data.frames into RDF and extract back
 cars <- mtcars %>% rownames_to_column("Model")
 x1 <- as_rdf(iris, NULL, "iris:")
 x2 <- as_rdf(cars, NULL, "mtcars:")
 rdf <- c(x1,x2)

sparql <-
  'SELECT  ?Species ?Sepal_Length ?Sepal_Width ?Petal_Length  ?Petal_Width
WHERE {
 ?s <iris:Species>  ?Species .
 ?s <iris:Sepal.Width>  ?Sepal_Width .
 ?s <iris:Sepal.Length>  ?Sepal_Length . 
 ?s <iris:Petal.Length>  ?Petal_Length .
 ?s <iris:Petal.Width>  ?Petal_Width 
}'

iris2 <- rdf_query(rdf, sparql)

sparql <- tidy_schema("Species",  "Sepal.Length", "Sepal.Width", prefix = "iris")

rdf_query(rdf, sparql)