Crosstab

sector	2016	2017	2018	2019
Commercial Electricity	325.48	278.88	252.67	226.23
Domestic Electricity	230.75	204.08	183.57	164.24
Industry Electricity	116.00	111.22	107.68	80.62
Public Sector Electricity	86.86	71.24	68.77	61.36

Tidy

sector	year	territorial_emissions
Commercial Electricity	2016	325.48
Domestic Electricity	2016	230.75
Industry Electricity	2016	116.00
Public Sector Electricity	2016	86.86
Commercial Electricity	2017	278.88
Domestic Electricity	2017	204.08
Industry Electricity	2017	111.22
Public Sector Electricity	2017	71.24
Commercial Electricity	2018	252.67
Domestic Electricity	2018	183.57
Industry Electricity	2018	107.68
Public Sector Electricity	2018	68.77
Commercial Electricity	2019	226.23
Domestic Electricity	2019	164.24
Industry Electricity	2019	80.62
Public Sector Electricity	2019	61.36

The useR! audience will be familiar with tidy data, the way we melt or unpivot cross-tabulations into long tables of observations to better work with the data.

Instead of communicating dimensions with the structure and layout of the table, we turn them into data - columns in a data frame that may be addressed and manipulated.

Years

year	start	end
2005	2005-01-01	2005-12-31
2006	2006-01-01	2006-12-31
2007	2007-01-01	2007-12-31

Units

label	comment
KT-CO2	Kilotonnes of Carbon Dioxide

Observations

year	area	sector	territorial_emissions	unit_of_measure
2005	Hartlepool	Commercial Electricity	77.19	KT-CO2
2005	Hartlepool	Commercial Gas	16.69	KT-CO2
2005	Hartlepool	Commercial ‘Other Fuels’	0.20	KT-CO2
2005	Hartlepool	Domestic Electricity	80.64	KT-CO2
2005	Hartlepool	Domestic Gas	131.38	KT-CO2
2005	Hartlepool	Domestic ‘Other Fuels’	4.07	KT-CO2

Areas

label	notation	boundary
Glasgow City	S12000049	MULTIPOLYGON (((-…
Aberdeen City	S12000033	POLYGON ((-2.0613…
City of London	E09000001	MULTIPOLYGON (((-…
Barking and Dagenham	E09000002	MULTIPOLYGON (((0…
Barnet	E09000003	POLYGON ((-0.1819…
Bexley	E09000004	POLYGON ((0.2031 …

Sectors

label	sort_priority	parent
Commercial Electricity	1	Commercial
Commercial Gas	2	Commercial
Commercial ‘Other Fuels’	3	Commercial
Domestic Electricity	4	Domestic
Domestic Gas	5	Domestic
Domestic ‘Other Fuels’	6	Domestic

I work with data cubes expressed as tidy data. We have a central fact table where each row is an observation and each column a dimension or measurement. The values referenced in the dimensions are in turn described with dimension tables.

This data is normalised, which means that it’s structured to minimise redundancy by removing functional dependencies between rows and columns making the independent pieces distinct and their relations clear.

In this case each dimension value occurs may occur many times in the long fact table. This type of normalised form is also known as a star schema because the large central table is surrounded by smaller ones like the diffraction spikes shining around a star.

As analysts, we want access to all of this information; not just the central fact table. There is useful reference data stored in the dimension tables - like labels for codes, or relations to parent resources that describe hierarchy or, for richer resource types like geographies, we might have boundary polygons.

So how do we work with data like this in data frames?

Denormalised Star

year	year_start	year_end	area	area_notation	area_boundary	sector	sector_notation	sector_sort_priority	territorial_emissions	unit_of_measure
2005	2005-01-01	2005-12-31	Hartlepool	E06000001	POLYGON ((-1.24098 54….	Commercial Electricity	commercial-electricity	1	77.19	KT-CO2
2005	2005-01-01	2005-12-31	Hartlepool	E06000001	POLYGON ((-1.24098 54….	Commercial Gas	commercial-gas	2	16.69	KT-CO2
2005	2005-01-01	2005-12-31	Hartlepool	E06000001	POLYGON ((-1.24098 54….	Commercial ‘Other Fuels’	commercial-other-fuels	3	0.20	KT-CO2
2005	2005-01-01	2005-12-31	Hartlepool	E06000001	POLYGON ((-1.24098 54….	Domestic Electricity	domestic-electricity	4	80.64	KT-CO2
2005	2005-01-01	2005-12-31	Hartlepool	E06000001	POLYGON ((-1.24098 54….	Domestic Gas	domestic-gas	5	131.38	KT-CO2
2005	2005-01-01	2005-12-31	Hartlepool	E06000001	POLYGON ((-1.24098 54….	Domestic ‘Other Fuels’	domestic-other-fuels	6	4.07	KT-CO2
2005	2005-01-01	2005-12-31	Hartlepool	E06000001	POLYGON ((-1.24098 54….	Industry Electricity	industry-electricity	7	101.15	KT-CO2
2005	2005-01-01	2005-12-31	Hartlepool	E06000001	POLYGON ((-1.24098 54….	Industry Gas	industry-gas	8	33.21	KT-CO2
2005	2005-01-01	2005-12-31	Hartlepool	E06000001	POLYGON ((-1.24098 54….	Large Industrial Installations	large-industrial-installations	9	181.10	KT-CO2
2005	2005-01-01	2005-12-31	Hartlepool	E06000001	POLYGON ((-1.24098 54….	Industry ‘Other Fuels’	industry-other-fuels	10	20.44	KT-CO2
2005	2005-01-01	2005-12-31	Hartlepool	E06000001	POLYGON ((-1.24098 54….	Agriculture	agriculture	11	2.09	KT-CO2
2005	2005-01-01	2005-12-31	Hartlepool	E06000001	POLYGON ((-1.24098 54….	LULUCF Net Emissions: Forest land	lulucf-net-emissions-forest-land	12	-1.65	KT-CO2
2005	2005-01-01	2005-12-31	Hartlepool	E06000001	POLYGON ((-1.24098 54….	LULUCF Net Emissions: Cropland	lulucf-net-emissions-cropland	13	2.40	KT-CO2
2005	2005-01-01	2005-12-31	Hartlepool	E06000001	POLYGON ((-1.24098 54….	LULUCF Net Emissions: Grassland	lulucf-net-emissions-grassland	14	-2.94	KT-CO2
2005	2005-01-01	2005-12-31	Hartlepool	E06000001	POLYGON ((-1.24098 54….	LULUCF Net Emissions: Wetlands	lulucf-net-emissions-wetlands	15	0.00	KT-CO2

It is possible to work with all these tables separately, joining them on the fly for each analytical pipeline.

This can be quite repetitive so people tend to denormalise the data - realising the result of all the joins in a giant single data frame.

This is no longer normalised since there are dependencies between your columns. That means you need to coordinate changes. We tend to avoid this in the source database because it requires more application code to maintain data integrity. It’s more acceptable for analysis where the data doesn’t change but it does make tables harder to understand. People have to resort to data exploration to uncover the relationships between columns.

Arguably the denormalised data is still tidy particularly if the fact table has a one-to-many join with the dimension tables because the joins add columns but not rows.

It’s nevertheless unwieldly and doesn’t scale well. It quickly get very wide making it harder to inspect the data which discourages people from adding too many columns. We also loose information about which columns belong together. Here Pandas in Python scores a point as you can relate variables by using tuples for column headers.

Perhaps the worst problem though is that we introduce a lot of duplication making our data frames much bigger than they need to be. If you repeat a geographic boundary a hundred times you’ll soon notice the memory requirements shoot up and processing speed slows down.

Linked Data Frames

Robin Gower

I’d like to propose an alternative solution which I’ve implemented with the help of the {vctrs} library. We can use this to store the reference table as an attribute of a dimension vector using the values to look-up resource descriptions.

I’ve released this as the linked data frames package.

What is {vctrs}?

{vctrs} is a developer-focussed package. You don’t need to know about it to use the linked-data-frames package but I’d like to take a moment to draw your attention to it as {vctrs} is what does all the hard work here.

Among other things, you can use {vctrs} to create new vector types in R much more easily than using S3 directly.

We don’t have time to get into the details of how this works but the {vctrs} vignette on S3-Vectors is truely first rate documentation.

I will however explain a few gotchas toward the end of the talk that show cases where the abstraction leaks and some care is needed to avoid subtle bugs.

What is linked-data?

Before we get stuck into the code I’d like to take a step back to provide some more context.

I work with linked-data. This uses the Resource Description Framework (or RDF) which expresses information about resources using a knowledge graph.

Resources in the knowledge graph are described with triples relating a subject (node) with a predicate (edge) to an object (node). Here in the centre we see “BOB” (the subject) “is interested in” (the predicate) “The Mona Lisa” (the object).

In linked-data, all the nodes and edges are Uniform Resource Identifiers (or URIs). That means you can look them up on the web and get back a definition. The object nodes can also be literal datatypes like strings and numbers.

Encoding graphs as triples

BASE   <http://example.org/>
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
PREFIX schema: <http://schema.org/>
PREFIX dcterms: <http://purl.org/dc/terms/>
PREFIX wd: <http://www.wikidata.org/entity/>

<bob#me>
    a foaf:Person ;
    foaf:knows <alice#me> ;
    schema:birthDate "1990-07-04"^^xsd:date ;
    foaf:topic_interest wd:Q12418 .

wd:Q12418
    dcterms:title "Mona Lisa" ;
    dcterms:creator <http://dbpedia.org/resource/Leonardo_da_Vinci> .

<http://data.europeana.eu/item/04802/243FA8618938F4117025F17A8B813C5F9AA4D619>
    dcterms:subject wd:Q12418 .

We can serialise these triples into a format like turtle. This groups blocks of statements about the same subject, with each predicate-object pair in the description separated by semi-colons and terminated with a period. Namespace prefixes help to make the URIs legible. Here we building on five other web ontologies which define URIs for us to use.

Melting tidy data to triples

BASE   <http://example.org/>
PREFIX dimension: <http://example.org/dimension/>
PREFIX measure: <http://example.org/measure/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX geosparql: <http://www.opengis.net/ont/geosparql#>

<obs#1>
  dimension:year <year#2005> ;
  dimension:area <area#hartlepool> ;
  dimension:sector <sector#commercial-electricity> ;
  measure:emissions 77.19 .

<year#2005>
  rdfs:label "2005" .
  
<area#hartlepool>
  rdfs:label "Hartlepool" ;
  geosparql:hasGeometry <geometry#hartlepool> .

<geometry#hartlepool>
  geosparql:asWKT "POLYGON ((-1.24098 54.72318, -1.24401 54.72157 ... ))" .

<sector#commercial-electricity>
  rdfs:label "Commercial Electricity" ;
  ui:sortPriority 1 .

You can think of this as a further form of normalisation. We melt tidy data down into statements relating the observation-row with a column-variable to the cell-value.

We can do the same thing with the reference tables.

The linked open-data cloud

In my work with a company called Swirrl, we publish billions of these triples describing hundreds of data cubes and millions of reference resources. This contributes to the linked-open-data cloud which connects datasets across many disciplines.

In particular, our work on the Integrated Data Programme which is an initiative from the UK’s Office for National Statistics and other Government departments has focussed on disseminating tidy data cubes.

It’s this work that motivated the creation of the linked-data-frames package - to help R users download tables of resources from the knowledge graph and assemble it into idiomatic data frames in R.

Working with LDF Resources

Let’s explore that idiomatic representation from the ground-up. We’ll start at the beginning and see how we can use the linked-data-frames package to create vectors of richly-described resources.

Creating resources

uris <- c("http://example.net/id/apple",
          "http://example.net/id/banana",
          "http://example.net/id/carrot")
labels <- c("Apple", "Banana", "Carrot")
descriptions <- data.frame(uri=uris, label=labels)

(food <- resource(uris, descriptions))

<ldf_resource[3]>
[1] Apple  Banana Carrot
Description: uri, label

We start with a vector of URIs that identify each resource.

We record the descriptions in a data frame that must at least include a variable called uri that will be used to find the corresponding description for each resource.

We create LDF resources with the vector of identifiers and the data frame of descriptions.

If you include a variable called label in the description, this will be used by the format() generic when printing to the console. We also print out a list of the variables present in the description.

Repeating resources

(kitchen <- tibble(
  dish=c("Fruit Salad", "Fruit Salad",
         "Carrot Salad", "Carrot Salad"),
  food=resource(c("http://example.net/id/apple",
                  "http://example.net/id/banana",
                  "http://example.net/id/apple",
                  "http://example.net/id/carrot"),
                descriptions),
  quantity=c(2,2,1,3)))

# A tibble: 4 × 3
  dish         food       quantity
  <chr>        <ldf_rsrc>    <dbl>
1 Fruit Salad  Apple             2
2 Fruit Salad  Banana            2
3 Carrot Salad Apple             1
4 Carrot Salad Carrot            3

Because we’re identifying resources with URIs and not by a ordinal index, you can include repetitions in the URI vector without needing to duplicate descriptions.

We can treat the rich multi-dimensional description as a scalar value. We can use a URI to stand-in for the object while it’s description is stored elsewhere, orthogonally.

Accessing descriptions

uri(food)

[1] "http://example.net/id/apple"  "http://example.net/id/banana"
[3] "http://example.net/id/carrot"

description(food)

                           uri  label
1  http://example.net/id/apple  Apple
2 http://example.net/id/banana Banana
3 http://example.net/id/carrot Carrot

property(food, "label")

[1] "Apple"  "Banana" "Carrot"

food[label(food) == "Apple"]

<ldf_resource[1]>
[1] Apple
Description: uri, label

LDF provides accessors for the identifiers and descriptions. You can also select individual properties. Since labels are so ubiquitous, we have a dedicated accessor for them.

Loading data

Now we can look at how to load in some existing data from the linked-open-data cloud.

We’ll start by learning about SPARQL a query language for linked-data. Then we’ll see how to use LDF to write SPARQL queries for us. Finally we’ll look at how this approach generalises to work with relational data too.

Tabulating linked-data with SPARQL

music_genres_query <- "
PREFIX : <http://dbpedia.org/ontology/>

SELECT * WHERE {
  ?uri a :MusicGenre;
    rdfs:label ?label;
    rdfs:comment ?comment
    .
} LIMIT 100
"
(music_genre_results <- query(music_genres_query, endpoint="http://dbpedia.org/sparql/"))

# A tibble: 100 × 3
   uri                                            label              comment    
   <chr>                                          <chr>              <chr>      
 1 http://dbpedia.org/resource/Art_rock           Art rock           "Art rock …
 2 http://dbpedia.org/resource/Bebop              Bebop              "Bebop or …
 3 http://dbpedia.org/resource/Britpop            Britpop            "Britpop w…
 4 http://dbpedia.org/resource/Bubblegum_pop      Bubblegum pop      "Bubblegum…
 5 http://dbpedia.org/resource/Fighting_game      Fighting game      "A fightin…
 6 http://dbpedia.org/resource/Free_improvisation Free improvisation "Free impr…
 7 http://dbpedia.org/resource/Greek_hip_hop      Greek hip hop      "Greek hip…
 8 http://dbpedia.org/resource/Grunge             Grunge             "Grunge (s…
 9 http://dbpedia.org/resource/Historical_fiction Historical fiction "Historica…
10 http://dbpedia.org/resource/Morality_play      Morality play      "The moral…
# … with 90 more rows

The triples we saw earlier can be kept in databases called triplestores. We can query triplestores with the SPARQL query language which matches triple patterns.

Here we find the first 100 music genres in dbpedia and extract a label and comment in English. We describe a pattern for a resource of type Music Genre that has a label and a comment. The variables, with names starting with a question mark, are bound to the matching values in the result table.

music_genres <- resource(music_genre_results$uri, description=music_genre_results)

# find music genres where the comment mentions "dance"
music_genres[grep("dance", property(music_genres, "comment"))]

<ldf_resource[12]>
 [1] Polka                          Trance music                  
 [3] Vaudeville                     Zarzuela                      
 [5] Afro/Cosmic music              Benga music                   
 [7] Bubblegum dance                Waltz (International Standard)
 [9] Logobi                         Sega (genre)                  
[11] K-pop                          Western swing                 
Description: uri, label, comment

We can use this table to create LDF resources and then reach into the description while grepping the genres to match against the comment - helping us find dance music genres.

You’ll need a fair bit of domain knowledge to write SPARQL queries - both in terms of SPARQL itself as well as the vocabularies used in the data. The LDF package seeks to take care of this problem by writing queries for you.

ldf::get_cube

get_cube("http://gss-data.org.uk/data/gss_data/climate-change/beis-2005-to-2019-local-authority-carbon-dioxide-co2-emissions#dataset",
         endpoint="https://beta.gss-data.org.uk/sparql")

# A tibble: 129,388 × 5
   year       area       sector                         territorial_emissions
   <ldf_ntrv> <ldf_rsrc> <ldf_rsrc>                                     <dbl>
 1 2005       Hartlepool Commercial Electricity                         77.2 
 2 2005       Hartlepool Commercial Gas                                 16.7 
 3 2005       Hartlepool Commercial 'Other Fuels'                        0.2 
 4 2005       Hartlepool Domestic Electricity                           80.6 
 5 2005       Hartlepool Domestic Gas                                  131.  
 6 2005       Hartlepool Domestic 'Other Fuels'                          4.07
 7 2005       Hartlepool Industry Electricity                          101.  
 8 2005       Hartlepool Industry Gas                                   33.2 
 9 2005       Hartlepool Large Industrial Installations                181.  
10 2005       Hartlepool Industry 'Other Fuels'                         20.4 
# … with 129,378 more rows, and 1 more variable: unit_of_measure <ldf_rsrc>

LDF provides a set of functions for assembling linked-data frames from datasets published according to the RDF Data Cube standard. This is mostly captured under the top-level porcelain get_cube which builds on top of plumbing to orchestrate a set of SPARQL queries.

These queries first download a tidy table of URIs for the observations and then, for each column, descriptions are downloaded for all the reference data. The results are assembled into a linked data frame.

Hidden behind each of these ldf_resource column types is one of the related tables from the star schema we saw at the beginning.

# English Local Authority areas with the highest emissions from transport
(transport_emissions <- emissions %>% 
    filter(sector %>% property("parent") %>% label() == "Transport") %>%
    group_by(area) %>% 
    summarise(total_emissions=sum(territorial_emissions)) %>% 
    arrange(-total_emissions))

# A tibble: 379 × 2
   area                      total_emissions
   <ldf_rsrc>                          <dbl>
 1 Leeds                              25831.
 2 Birmingham                         22273.
 3 Buckinghamshire                    21006.
 4 Wiltshire                          19024.
 5 Cheshire East                      17929.
 6 Cornwall                           15703.
 7 Cheshire West and Chester          14393.
 8 County Durham                      14210.
 9 South Gloucestershire              14013.
10 Doncaster                          13778.
# … with 369 more rows

Now we can apply the full power of R to our linked-data frame.

Here we’re using {dplyr} to filter, group and aggregate the data.

The filter reaches into the sector column to find the parent sector, this in turn is also a resource with a label which we can match against a string.

Notice the group by also returns the original resource areas, carrying the descriptions through for further analysis.

transport_emissions_map <- 
  description(transport_emissions$area) %>%
  filter(!is.na(boundary)) %>% 
  st_as_sf(wkt="boundary", crs="WGS84") %>%
  left_join(mutate(transport_emissions,
                   geo=uri(area)),
            by=c("uri"="geo"))

ggplot(transport_emissions_map) + 
  geom_sf(aes(fill=log(total_emissions)),
          colour="white", size=0.2) + 
  scale_fill_viridis_c("KT-CO2") + 
  labs(title="Transport Emissions",
       subtitle="Total 2005-2019")

As we saw earlier those descriptions include Well-Known-Text (or WKT) boundaries provided by ONS Geography linked-data endpoint. We can use these to draw a map.

This example does require us to denormalise our nested tabular structure though. The simple features ({sf}) package expects the geometries and values be in the one data frame, so we need to take the area description and then attach the measure to that before charting.

This is a nice demonstration of how the knowledge graph approach allows publishers to attach arbitrary information to describe resources in their datasets. Data consumers can then enjoy richly described data which reduces the amount of preparation and enrichment we have to do ourselves. Indeed from here we could also use the URIs to link this data to other datasets, letting links in the knowledge graph tell us how the data fits together.

Although the SPARQL example and the get_cube wrapper are extracting linked-data from a graph, we’re still working with tabular data to create the resource descriptions. Indeed we can also use this approach to create resources with relational data.

Linking relational data

library(nycflights13)

flights_ldf <- flights %>% mutate(
  carrier=resource(carrier, rename(airlines, uri=carrier)),
  origin=resource(origin, rename(airports, uri=faa), fill_missing=T),
  dest=resource(dest, rename(airports, uri=faa), fill_missing=T),
  tailnum=resource(tailnum, rename(planes, uri=tailnum), fill_missing=T))

flights_ldf %>% 
  mutate(distance=spatialrisk::haversine(
    property(origin, "lat"), property(origin, "lon"),
    property(dest, "lat"), property(dest, "lon"))) %>%
  (function(d) qplot(d$distance/1000, xlab="Kilometers travelled to/ from NYC"))

We can demonstrate how this works on a relational database using the NYC flights dataset.

We take the central flights table then replace the foreign keys with the related objects themselves. That is to say, LDF resources described using the related tables.

Note that we’ve had to invoke the fill_missing flag as the descriptions in the package are incomplete.

We now have a single data frame containing all the reference data wired-up correctly. This makes it easy to work with relational data using dplyr and ggplot too.

Gotchas

Lessons for working with {vctrs}

The vctrs package is an ambitious attempt to overhaul some of the inner workings of R. This can lead to a few unexpected results as some base R functions aren’t forward compatible.

Dispatching on base type

table(kitchen$food)

 http://example.net/id/apple http://example.net/id/banana 
                           2                            1 
http://example.net/id/carrot 
                           1 

table(label(kitchen$food))

 Apple Banana Carrot 
     2      1      1 

kitchen_labels <- as_dataframe_of_labels(kitchen)

str(kitchen_labels)

'data.frame':   4 obs. of  3 variables:
 $ dish    : chr  "Fruit Salad" "Fruit Salad" "Carrot Salad" "Carrot Salad"
 $ food    : chr  "Apple" "Banana" "Apple" "Carrot"
 $ quantity: num  2 2 1 3

Because the underlying type of resources is character, R will tend dispatch on this basis for base functions or any other packages that aren’t expecting these novel S3 vectors.

This can be unexpected. The table() function, for example, returns counts by URI not label as we might expect. We deliberately have as.character() return the URI and not the label as it’s the URI that’s designed to represent the resource. You can of course tabulate the labels explicitly instead.

More generally LDF offers an escape hatch to convert a linked data frame back into a “normal” data frame (i.e. one not containing vectors of RDF resources) using the as_dataframe_of_labels() function. This converts all the RDF resources into their labels.

Use {vctrs} to retain descriptions

(d1 <- data.frame(
  r=resource(c("a","b"),
             data.frame(uri=c("a","b"),
                        label=c("A","B"))),
  v=1:2))

  r v
1 A 1
2 B 2

(d2 <- data.frame(
  r=resource(c("b","c"),
             data.frame(uri=c("b","c"),
                        label=c("B","C"))),
  v=3:4))

  r v
1 B 3
2 C 4

# only takes first descriptions
# so the label "C" is missing
rbind(d1, d2) 

   r v
1 A  1
2 B  2
3 B  3
4 NA 4

# merges descriptions
# all the labels are retained
vctrs::vec_rbind(d1, d2) 

  r v
1 A 1
2 B 2
3 B 3
4 C 4

You can also become unstuck in less obvious ways. The humble rbind function doesn’t attempt to merge attributes so the combined result only has descriptions from the first input and is thus missing a label for the “C” resource which is only described in the second input. You need to use the more robust vec_rbind function provided by the vctrs package to ensure the descriptions are combined.

Tidyverse is {vctrs}-aware

merge(d1, d2, by="r", all=T) # C label missing

   r v.x v.y
1 A    1  NA
2 B    2   3
3 NA  NA   4

dplyr::full_join(d1, d2, by="r") # merges descriptions

  r v.x v.y
1 A   1  NA
2 B   2   3
3 C  NA   4

Likewise, the base::merge() function will only retain the descriptions of the left-hand data frame.

This is fine for left-joins or inner-joins (with merge(all=F)) but for right- or full-joins you’ll need to use dplyr instead as this uses vctrs underneath.

We expose a merge_description() function to help outside of the tidyverse.

Try it for yourself

install.packages("devtools")
devtools::install_github("Swirrl/linked-data-frames")
library(ldf)

If this talk has aroused your interest you can check out the package on github.

Learn more

Documentation for the {vctrs} package

vctrs.r-lib.org

Documentation for the {ldf} package

swirrl.github.io/linked-data-frames

Data Cubes from by the Integrated Data Programme

beta.gss-data.org.uk

Linked-data schema used by PublishMyData

ontologies.publishmydata.com

Occasional tweets from me

@robsteranium

Finally here are some links if you’d like to know more.