This is a first step on a long road.

One of the features of the UK Government’s approach to freeing data is the emphasis on using linked data. What I don’t think has really been articulated is either what that means or why we should take this approach. From what I’ve seen, developers seem to think:

• linked data is a synonym for turning everything into RDF and putting it in one big triplestore, equivalent to making one big database of government data and therefore prone to exactly the same, well-known and understood problems that government has with creating huge databases
• linked data requires everyone to agree to the same model and vocabulary, which means huge efforts in standardisation and ends up with something that suits no one
• the UK government will be releasing all their data as linked data immediately, and in no other way
• the UK government has been seduced into using linked data by academics who don’t understand anything about how the web or the real world works
• the UK government has been seduced into using linked data by big businesses who stand to make a pretty penny providing services to departments that are forced to publish their data in this way

None of these are true. In fact, the UK government is committed to publishing data as linked data because they are convinced it is the best approach available for publishing data in a hugely diverse and distributed environment, in a gradual and sustainable way.

Why?

Because linked data is just a term for how to publish data on the web while working with the web. And the web is the best architecture we know for publishing information in a hugely diverse and distributed environment, in a gradual and sustainable way.

If you’re a web developer, you already know that the best APIs are RESTful APIs. That argument has been won. It means:

• using (HTTP) URIs to identify resources: naming things with URIs rather than actions on those things (which are carried out using the standard set of HTTP verbs)
• recognising the distinction between resources and representations of those resources: the same URI might return a different representation of the resource, such as HTML or XML or JSON
• returning self-descriptive messages: being able to process representations in a manner that is obvious from the mime type
• hypermedia as the engine of application state: being able to locate additional resources through the use of (typed) links

Linked data is about following these rules for publishing data. It is about using URIs to identify things, providing information at the end of those URIs that is self-descriptive, and linking those things to other things through typed links.

One of the features of this approach is that it doesn’t require any big bangs. No one planned the web: sat down and mapped out each page and its precise relations to every other page, in advance. It grew, and evolved, and continues to grow and evolve every day. It grows through individuals and institutions publishing information for their own reasons and linking to other people who have published information for their own reasons, and, because we have some fundamental standards that clients and servers understand, it All Just Works.

Standards

Did you notice how I slipped in the “because we have some fundamental standards that clients and servers understand”? One standard is obviously HTTP: that controls how clients and servers can talk to each other: it allows clients to request pages and servers to respond. Another standard is HTML: that enables browsers to display information in ways that people can understand it, and (crucially) has a known set of semantics that browsers can use to tell when something is a link, which people can navigate to find more information.

For linked data, there are two crucial standards: RDF and SPARQL. Yes, I know what you’re thinking, because believe me two years ago that would have been my reaction too, but let me explain why.

There’s one way in which publishing data isn’t like publishing documents: its model. Documents are made up of paragraphs and headings and lists and tables and so on. Data is made up of… what? Well, at its most basic, it’s things that have properties which have values. We might call the things objects or entities, and call some of the properties relations. We might even call them records with columns and values and foreign keys. But however you term them, for better or worse, we do tend to think about data in this way: thing, property, value.

So if we are going to publish data on the web, we need a standard way of expressing the data so that a client receiving the data can work out what’s a thing, what’s a property, what’s a value. And, because this is the web, what’s a link. This is the fundamental standard we need, and this is what RDF gives.

RDF is actually a model rather than a syntax. It’s a bit like the split between the DOM and HTML or XHTML. The DOM tells the browser how to render the page: the HTML or XHTML is just a syntax which the browser is able to convert into a DOM that it displays. We could imagine browsers converting wiki syntax into a DOM. Or creating a DOM based on XML and XSLT, which of course they all do.

So, RDF is like the DOM, with varying representations of RDF (XML-based, text-based, JSON-based, even HTML-based) that can be used to pass to the client the underlying model of things and properties and values (some of which are links). What the client does then is its business: clients that retrieve data aren’t browsers — they’re not all going to display the data, use the same parts of the data, or otherwise process it in the same way — but they can pull out the things, properties and values, and know which are links, and this data structure will often, with a good RDF library, map on to some natural structure within whatever programming language is being used, and make the programmer’s job easier.

Vocabularies

What we don’t want to have to define are standard ways of expressing particular data (such as data about a school) because different individuals and organisations will have completely different ways of thinking about a particular thing. A school itself will have information about uniform and open days; OFSTED about performance; Edubase about administration and pupil numbers; the PTA about after-school activities. Expecting everyone to adopt a particular standard vocabulary for describing a school is as futile as expecting everyone to adopt exactly the same page layout within their web pages, and exactly the same class names in their CSS.

But we don’t want to rule out opportunistic alignments where individuals or organisations, for whatever reason, do want to use the same vocabularies. Look at what’s happened with classes in HTML. There is absolutely no constraint on what classes people use in their HTML. But there are clusters of web pages that use some of the same classes. Websites that use microformats. Websites that adopt a particular CSS framework. Importantly, though, even where some classes are shared, it doesn’t mean that all classes are shared: adoption of a particular microformat or CSS framework doesn’t limit the rest of the page.

RDF has this balance between allowing individuals and organisations complete freedom in how they describe their information and the opportunity to share and reuse parts of vocabularies in a mix-and-match way. This is so important in a government context because (with all due respect to civil servants) we really want to avoid a situation where we have to get lots of civil servants from multiple agencies into the same room to come up with the single government-approved way of describing a school. We can all imagine how long that would take.

The other thing about RDF that really helps here is that it’s easy to align vocabularies if you want to, post-hoc. RDFS and OWL define properties that you can use to assert that this property is really the same as that property, or that anything with a value for this property has the same value for that other property. This lowers the risk for organisations who are starting to publish using RDF, because it means that if a new vocabulary comes along they can opportunistically match their existing vocabulary with the new one. It enables organisations to tweak existing vocabularies to suit their purposes, by creating specialised versions of established properties.

So the linked data web is designed to grow and evolve in exactly the same way as the human web has grown and evolve. It grows through people adding links to existing data. It grows through people creating their own vocabularies. And it evolves as links break and reform, and vocabularies combine and diverge. It is complex and messy and self-organising.

Layers

The cornerstone of the great, messy, web is the URI. URIs have two important roles:

• they identify things - If two sets of data use the same URI then it’s dead easy to work out when they are talking about the same thing, for example to bring together the information published by a school with its OFSTED report with its pupil census. Spread this around to five, ten, twenty datasets from different places all using the same identifier for the school, and you have huge pool of information. And the great thing about RDF (because they also use URIs to identify properties) is that those datasets can be combined automatically without worrying about clashes, rather than through painstaking developer effort.

• they provide somewhere to look for information - This is the point of using HTTP URIs, because that look-up is as simple as retrieving a document from the web. This enables programmatic, on-demand, access to the information. Developers don’t have to download huge database dumps when all they are interested in is a small fraction of that data.

But we know that of course sometimes developers do want to download huge database dumps. So we need URIs for those dumps, and ways to associate metadata with them, and ways to search them. Adopting linked data doesn’t preclude providing sets of data in larger lumps. In fact, what’s needed are ways of creating those larger datasets by bringing together the more granular linked data into lists and graphs; this is essentially what SPARQL does.

We also know that there’s a trade-off to be made between the power of URIs and the simplicity of using short, unqualified names, particularly when it comes to naming schema-level entities such as properties or classes. Most mashups that we see at the moment bring together just a few datasets, making it easy for developers to scan for naming clashes, or examine values to work out whether a particular property contains a link or not. This is the 80% of the use of data on the web that can be addressed by the 20% solution of the kind of JSON and plain old XML you see in most APIs.

But publishing with RDF can be the basis of these kinds of simple APIs, and still address the hard 20% that we will encounter quickly as we mash more data together. Any data munger knows that the main challenge of making data available in an easily accessible way is cleaning, tidying, modelling and restructuring. If that’s done into RDF then creating simple JSON, XML and even CSV is really easy. Creating middle-ware that will make the creation of these basic APIs really easy must be the top priority of this linked data effort.

Reality Check

So it’s all good, right?

No, of course it’s not all good. Just as in the early days of the human web, we face huge challenges simply getting tooling to a level where it’s easy (really easy) for government departments and local authorities to publish data as RDF and for the consumers of the data to use it. We have some patterns for publishing linked data, but, as in the early days of the human web, there’s still a lot we don’t know about the best way to make data usable by third parties.

It’s worth noting that the main challenges we face are ones that are common to all attempts to make data both open and reusable. How do we easily create structured and reusable data from presentation-oriented Excel or (worse) PDFs? How do we handle changes over time, and record the provenance of the information that we provide? How to we represent statistical hypercubes? Or location information? These are things that we will only learn by trying things out.

In the end, though, the best evidence we have for how the web of linked data will progress is the evidence of how things were for the human web. It is hard to be an early adopter, both for social reasons and technological reasons. Nothing will happen overnight, but gradually there will be network effects: more shared URIs, more shared vocabularies, making it both easier to adopt and more beneficial for everyone.

Is this a kind of faith? Maybe. I believe in the web.

Note that we don’t have to do any of these things; they’re not part of the core data. We shouldn’t beat ourselves up if we don’t have time to do it right now, because we can always add them later, and it might be that you just don’t agree that they should be done. But many of them don’t take a lot of time and can enhance the user’s experience of the data.

Labels

Every resource should have a label, even blank nodes. Adding labels makes it easier for people to generate HTML views from the data. Sometimes we have resources that have an obvious label (like the name of a local authority); at other times, the label needs to be constructed based on the other information that’s available about the resource.

I talked in the last instalment about skos:prefLabel (preferred label), skos:altLabel (alternative label) and rdfs:label. Technically, skos:prefLabel and skos:altLabel are sub properties of rdfs:label, which means that if a resource has a skos:prefLabel it also has a rdfs:label with that value. However, drawing that conclusion requires either built-in knowledge of SKOS or the ability to both automatically get hold of the SKOS ontology and reason with it, which is feasible (this is one of the advantages of RDF, after all), but adds an extra hurdle for people wanting to use your data.

So it’s best to give everything a rdfs:label, even if they already have a skos:prefLabel or skos:altLabel. It’s also good to try to imagine that label in the context of having no other information about the thing that it’s labelling, such as in the title of a page. For example, if you’re looking at the observation http://transport.data.gov.uk/id/traffic-count-point/13/direction/E/hour/2001-10-08T17:00:00/type/bicycle in the context of a traffic count, it may seem sensible to label it just “bicycle” (as I did in the first iteration of turning this traffic count data into RDF). But without that context, it makes no sense. Better to label it “Bicycles - 8 Oct 2001 17:00-18:00 - East - Salterton Road, EAST OF DINAN WAY, EXMOUTH” and provide an even more descriptive rdfs:comment like “Number of bicycles counted travelling East at Salterton Road, EAST OF DINAN WAY, EXMOUTH on 8 October 2001 between 17:00 and 18:00.”.

Datasets

There are two kinds of datasets that are applicable to this particular …err… set of data … and that we should describe within the RDF. They are:

• datasets that are sets of statistical data items (such as the observations in the traffic count data); these are best described using SCOVO
• datasets that are general descriptions of particular sets of linked data (such as roads or local authorities); these are best described using voiD

Both kinds of datasets can be identified for UK government data using URIs in the form:

http://{sector}.data.gov.uk/set/{dataset}/

SCOVO Datasets

Every scovo:Item should be part of a scovo:Dataset, associated through a scovo:dataset (and a reverse scovo:datasetOf). A scovo:Dataset is pretty simple: all you really need to do is give it an identifier and, of course, a label. In this case, something like:

http://transport.data.gov.uk/set/traffic-count/2001-2008/

This is an identifier that the various scovo:Items should use to indicate where the data comes from:

<http://transport.data.gov.uk/id/traffic-count-point/13/direction/E/hour/2001-10-08T17:00:00/type/bicycle>
  a scovo:Item ;
  scovo:dataset <http://transport.data.gov.uk/set/traffic-count/2001-2008/> ;
  traffic:count <http://transport.data.gov.uk/id/traffic-count-point/13/direction/E/hour/2001-10-08T17:00:00> ;
  traffic:vehicleType <http://transport.data.gov.uk/def/vehicle/bicycle> ;
  rdf:value 2 .

It’s also an identifier that we can attach some metadata to. Obviously it needs a label, but we can also attach other metadata, such as the provenance of the dataset.

<http://transport.data.gov.uk/set/traffic-count/2001-2008/>
  a scovo:Dataset ;
  a prv:DataItem ;
  rdfs:label "Traffic counts between 2001 and 2008"@en ;
  prv:createdBy [
    a prv:DataCreation ;
    prv:performedAt ... ;
    prv:performedBy ... ;
    prv:usedData ... ;
    prv:usedGuideline ... ;
  ] .

VoiD Datasets

VoiD is designed to be used to describe sets of linked data, their contents, their provenance and their relationships with each other. There are many ways of dividing up the data that we’ve been looking at into datasets. We can start with a simple example: the dataset containing linked data about countries:

<http://statistics.data.gov.uk/set/country/>
  a void:Dataset ;
  rdfs:label "Countries"@en ;
  foaf:homepage <http://statistics.data.gov.uk/set/country> ;
  dct:subject <http://dbpedia.org/resource/Country> ;
  cc:license [
    a cc:License ;
    rdfs:label "data.gov.uk Licence"@en ;
    foaf:homepage <http://data.hmg.gov.uk/terms-privacy> ;
    cc:permits cc:DerivativeWorks, cc:Distribution, cc:Reproduction ;
    cc:requires cc:Attribution ;
  ] ;
  void:exampleResource <http://statistics.data.gov.uk/id/country?name=England> ;
  void:sparqlEndpoint <http://services.data.gov.uk/statistics/sparql> ;
  void:uriRegexPattern "http://statistics.data.gov.uk/id/country?name=.+"^^xs:string ;
  void:vocabulary <http://statistics.data.gov.uk/def/administrative-geography/> ;
  void:vocabulary <http://www.w3.org/2000/01/rdf-schema#> .

This provides a link to a home page for the dataset, which should contain information about the dataset itself. (Accessing the URI for the dataset should also redirect users to this home page.) I’ve used the same URI as the dataset URI but without the slash at the end. (This is probably too subtle a difference between URIs; we don’t currently have official guidance for URIs for documents-about-datasets or documents-about-definitions.)

The void:exampleResource property can be used to point to resources that can act as starting points for exploring the data, and the void:sparqlEndpoint property points at a SPARQL endpoint that can be used for deeper querying. The void:uriRegexPattern property provides a regular expression for the URIs that are used to identify the resources that the dataset is about. void:vocabulary points to the vocabularies that the dataset uses.

Various Dublin Core properties can be used to provide metadata about the dataset, such as its subject matter. The Creative Commons schema provides a way of indicating the licence that the dataset is made available under, which is essential information to enable reuse. (I’ve derived some RDF about the licence here from the one described on the data.hmg.gov.uk pages; there should be an official version some time soon.)

The data that we can actually produce from this traffic count dataset is actually a subset of the dataset of all countries, and we can indicate this through a void:subset relationship:

<http://statistics.data.gov.uk/set/country/>
  ...
  void:subset [
    a void:Dataset ;
    a prv:DataItem ;
    rdfs:label "Country data from the DfT traffic count dataset 2001-2008"@en ;
    prv:createdBy [
      a prv:DataCreation ;
      prv:performedAt ... ;
      prv:performedBy ... ;
      prv:usedData ... ;
      prv:usedGuideline ... ;
    ] ;
  ] .

The other kind of subset that we should describe are link sets. Link sets are datasets that contain links between datasets. The country dataset doesn’t (currently) contain any links to other datasets, but the count dataset does:

<http://transport.data.gov.uk/set/traffic-count>
  a void:Dataset ;
  rdfs:label "Traffic Counts"@en ;
  foaf:homepage <http://transport.data.gov.uk/set/traffic-count> ;
  dct:subject <http://dbpedia.org/resource/Traffic> ;
  dct:subject <http://dbpedia.org/resource/Counting> ;
  cc:license [
    a cc:License ;
    rdfs:label "data.gov.uk Licence"@en ;
    foaf:homepage <http://data.hmg.gov.uk/terms-privacy> ;
    cc:permits cc:DerivativeWorks, cc:Distribution, cc:Reproduction ;
    cc:requires cc:Attribution ;
  ] ;
  void:exampleResource <http://transport.data.gov.uk/id/traffic-count-point/13/direction/E/hour/2001-10-08T17:00:00> ;
  void:uriRegexPattern <http://transport.data.gov.uk/id/traffic-count-point/[0-9]+/direction/[NSEW]/hour/[0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}:00:00> ;
  void:sparqlEndpoint <http://services.data.gov.uk/transport/sparql> ;
  void:vocabulary <http://transport.data.gov.uk/def/traffic/> ;
  void:subset [
    a void:Dataset ;
    rdfs:label "Traffic Counts from the DfT traffic count dataset 2001-2008"@en ;
    prv:createdBy ...
  ] ;
  void:subset [
    a void:Linkset ;
    rdfs:label "Traffic count / count point links"@en ;
    rdfs:comment "Links from a traffic count to the count point at which the count was taken."@en ;
    void:subjectsTarget <http://transport.data.gov.uk/set/traffic-count/> ;
    void:linkPredicate <http://transport.data.gov.uk/def/count> ;
    void:objectsTarget <http://transport.data.gov.uk/set/traffic-count-point/> ;
  ] ;
  void:subset [
    a void:Linkset ;
    rdfs:label "Traffic count / cardinal direction"@en ;
    rdfs:comment "Links from a traffic count to the direction in which the traffic was going."@en ;
    void:subjectsTarget <http://transport.data.gov.uk/set/traffic-count/> ;
    void:linkPredicate <http://transport.data.gov.uk/def/direction> ;
    void:objectsTarget <http://dbpedia.org/void/Dataset> ;
  ] ;
  void:subset [
    a void:Linkset ;
    rdfs:label "Traffic count / hour"@en ;
    rdfs:comment "Links from a traffic count to the hour when the traffic was being monitored."@en ;
    void:subjectsTarget <http://transport.data.gov.uk/set/traffic-count/> ;
    void:linkPredicate <http://transport.data.gov.uk/def/direction> ;
    void:objectsTarget [
      a void:Dataset ;
      rdfs:label "URIs for places and times" ;
      foaf:homepage "http://placetime.com/" ;
    ] ;
  ] .

scovo:Datasets are often subsets of void:Datasets. In the case of the traffic count data, the observations described by the scovo:Dataset above are a subset of the void:Dataset that is the set of all such observations (including ones from other years).

Derivable Data

The discussion about rdfs:label above touched on another set of information that should be included within the RDF data we produce: data that is automatically derivable from the data we provide. There are three main reasons for including derivable data within what we publish:

1. Given the current adoption of RDF-aware technologies, the consumers of our data are pretty unlikely to be able to (or to want to) use schemas, ontologies or rule sets to help them to reason over the data and draw conclusions. The consumers of this data might include semantic search engines and people scraping the data into their own triplestores, but they’re far more likely to be developers who really don’t care about RDF at all. It would be a shame to publish the data and then have no one use it.

2. Computing derivable data once saves overall effort. We calculate it once, centrally, and it means that the people using the data don’t have to spend processing time doing it themselves. (There’s a classic time/space trade-off here, of course; the down side of including data that isn’t strictly necessary is that the documents will end up larger.)

3. If we provide information that people are likely to need within the document that they get when they request a given resource, they’re less likely to need to resort to (harder to construct and more intensive to process) SPARQL queries to get what they need.

The overriding principle that we can use to help us decide what to include is to consider what we would like to see if we visited a page about the particular thing.

How we manage to provide the derived data depends on how we publish the data. I’m not talking here about how to do the publishing, but rather about what the consumers of the data should expect to see eventually. So, for example, if we publish the data as static files then we’re going to have to include all this data in those files. If we generate the RDF dynamically, we just have to make sure that the generated RDF includes the derived data; we might be able to set up rules in a triplestore, or a transformation of the data that it naturally produces, to include the derivable data.

Superclasses and Super-properties

One set of derived data is that inferred from the superclasses and super-properties that are defined with the RDF vocabularies we use in our data. Basically, if a resource has a type that is a subclass of another type, then the resource should have that superclass as a type as well. Similarly, if a triple includes a property that has a super-property, then there ought also to be a triple that links the subject and object of the original triple with the super-property as well.

To understand when it’s important to include this kind of derived data, we need to be aware of the kind of applications that will use the data. Some applications will be targeting just this dataset about traffic counts, and will be written to use whatever properties and classes that we’ve made available. Other applications will be targeted at specific vocabularies at a more general-purpose level. There might be applications that can be used to visualise SKOS hierarchies as a tree, for example, or applications that can plot any geo:lat/geo:long coordinates on a map, or any OWL-Time intervals and instants on a timeline. Still other applications, such as viewers like Tabulator, will be used with any old RDF. We need to provide enough information to make the data easily usable by these more generic applications.

As an example, in the last instalment we introduced classes for traffic:VehicleType and traffic:RoadCategory which were subclasses of skos:Concept. If we want generic SKOS visualisers to be able to display the vehicle type and road category concept schemes, we should try to make it easy for them to work out which things are concepts, by indicating that they are concepts as well. Bearing in mind what I’ve said above about labels, that means that the original RDF:

<motorway> a traffic:RoadCategory ;
  skos:prefLabel "Motorway"@en ;
  skos:broader <major> ;
  skos:scopeNote "Major roads often used for long distance travel. They are usually three or more lanes in each direction and generally have the maximum speed limit of 70mph."@en ;
  skos:inScheme <> .

should include a reference to skos:Concept and a rdfs:label:

<motorway> a traffic:RoadCategory ;
  a skos:Concept ;
  rdfs:label "Motorway"@en ;
  skos:prefLabel "Motorway"@en ;
  skos:broader <major> ;
  skos:scopeNote "Major roads often used for long distance travel. They are usually three or more lanes in each direction and generally have the maximum speed limit of 70mph."@en ;
  skos:inScheme <> .

Note that I haven’t included the results of all the reasoning that we could anticipate. The property skos:scopeNote is a sub-property of skos:note, for example, but I haven’t included a skos:note explicitly because any SKOS-aware processor should have that kind of knowledge built in. The rule of thumb is that if the result of the reasoning involves a resource from another vocabulary, then we should include it.

Derivable Values

There are other kinds of derivable data in this data set. In particular, there are eastings and northings, but not latitudes and longitudes. When there’s useful derivable data, especially when it’s not trivial to derive, it makes sense to make that available explicitly, otherwise everyone else will have to go through the effort of deriving it themselves.

We’ve already done this with the information about the hours of the traffic counts, by pulling out the year and hour of the count rather than having them tucked away within a xs:dateTime literal. The same should be true of the eastings and northings. For small numbers of values, you can use the Ordnance Survey’s online converter; for larger numbers of values you can download the (Windows only and very dated) software or try one of the various converters you can find with a Google search.

Latitudes and longitudes for points should, of course, be expressed using the geo:lat and geo:long properties from the http://www.w3.org/2003/01/geo/wgs84_pos# vocabulary.

Inverses

Statements in RDF link two things. For example, you can view the statement:

<http://transport.data.gov.uk/id/traffic-count-point/13>
  traffic:road <http://transport.data.gov.uk/id/road/B3178> .

as saying that traffic count point 13 is on the B3178 and that the B3178 has a count point on it that is traffic count point 13.

So it’s always possible, when creating a query about or a representation of the road to include the ‘backward links’ — the statements in which the road features as an object as well as those in which it features as a subject. This has caused some people to argue that relationships should only be defined in one direction.

Personally, I don’t agree, for two reasons.

1. Although it’s possible to create queries and representations that include backward links, it often doesn’t happen like that. It’s different with different triplestores, but result of a the DESCRIBE SPARQL query commonly only includes triples in which the thing being described in the subject, not the object. Also, when constructing queries, it seem more natural to always “travel forward” through the graph. For example:

   SELECT ?count
   WHERE {
     ?point
       area:localAuthority <http://statistics.data.gov.uk/id/local-authority/43UC> ;
       traffic:count ?count .
   }
   

   rather than:

   SELECT ?count
   WHERE {
     ?point
       area:localAuthority <http://statistics.data.gov.uk/id/local-authority/43UC> .
     ?count
       traffic:countPoint ?point .
   }
   

   So although it introduces redundancy, I think that including inverse relationships in RDF aids usability and navigability.

2. Sometimes both directions of a relationship contain meaningful information. For example, it’s not enough to include a gen:mother relationship from a person to their mother because the implied reverse relationship is simply that the person is a child of their mother — you need to include a gen:son or gen:daughter relationship as well to tell which type of child.

So in this dataset, I’m going to include inverse relationships where appropriate:

• from countries to regions
• from regions to local authority districts
• from roads to count points
• from count points to counts
• from counts to observations

Shortcuts

Another thing that can aid the navigability of a set of RDF data is to provide “shortcuts”. For example, at the moment we have links that say which country a region belongs to and which region a local authority district belongs to, but we don’t have a link that says which country a local authority district belongs to. These kind of links can make it easier to navigate through (and to query) a dataset, so they can be worth adding so long as they don’t clutter up the data too much.

Just think of what you’d like to know about a particular thing when you visit its page. If you’re looking at transport in a local authority district, it would be useful to know what region and country it belongs to and about what roads and traffic count points it contains. But it would be too much to have a list of all the counts and observations that have been taken on those count points.

For this dataset, I’m going to add shortcuts from:

• countries to local authority districts (and vice versa)
• count points to regions and countries
• roads to local authority districts (and vice versa)
• roads to regions and countries
• roads to road categories and road names
• roads to counts (and vice versa)
• observations to count points, roads, directions and count hours

These are all judgement calls — there are no hard and fast rules — and as you can see I’m not adding inverses everywhere here because to do so would lead to unnecessarily large sets of RDF in some cases.

That’s the end of this instalment. I had been intending to make this the final one, but there are a couple of things still left to talk about: the publication of RDF, and the supplementary documents that we need to provide (including RDF about those supplementary documents). I’ve also had a request to talk about OWL ontologies, so I’ll probably do that, and there are things to say about how to manage things changing over time. So this may end up being an eight-part series!

To keep us up to date, with all the extra derived information added, the RDF looks as follows:

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#"> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix time: <http://www.w3.org/2006/time> .
@prefix scovo: <http://purl.org/NET/scovo#> .
@prefix area: <http://statistics.data.gov.uk/def/administrative-geography/> .
@prefix admingeo: <http://data.ordnancesurvey.co.uk/ontology/admingeo/> .
@prefix space: <http://data.ordnancesurvey.co.uk/ontology/spatialrelations/> .
@prefix traffic: <http://transport.data.gov.uk/def/traffic/> .

<http://statistics.data.gov.uk/id/country?name=England>
  a area:Country ;
  rdfs:label "England"@en ;
  area:region <http://statistics.data.gov.uk/id/government-office-region/K> ;
  area:district <http://statistics.data.gov.uk/id/local-authority-district/18> .

<http://statistics.data.gov.uk/id/government-office-region/K>
  a admingeo:GovernmentOfficeRegion ;
  rdfs:label "South West"@en ;
  skos:notation "K"^^area:StandardCode ;
  area:country <http://statistics.data.gov.uk/id/country?name=England> ;
  area:district <http://statistics.data.gov.uk/id/local-authority-district/18> .

<http://statistics.data.gov.uk/id/local-authority-district/18>
  a area:LocalAuthorityDistrict ;
  rdfs:label "Devon"@en ;
  skos:notation "18"^^area:StandardCode ;
  skos:notation "1115"^^traffic:LAcode ;
  area:localAuthority <http://statistics.data.gov.uk/id/local-authority/18> ;
  area:country <http://statistics.data.gov.uk/id/country?name=England> ;
  area:region <http://statistics.data.gov.uk/id/government-office-region/K> ;
  traffic:countPoint <http://transport.data.gov.uk/id/traffic-count-point/13> ;
  traffic:road <http://transport.data.gov.uk/id/road/B3178> .

<http://transport.data.gov.uk/id/local-authority-district/1115>
  owl:sameAs <http://statistics.data.gov.uk/id/local-authority-district/18> .

<http://statistics.data.gov.uk/id/local-authority/18>
  a area:LocalAuthority ;
  rdfs:label "Devon County Council"@en ;
  skos:notation "18"^^area:StandardCode ;
  skos:notation "1115"^^traffic:LAcode ;
  area:coverage <http://statistics.data.gov.uk/id/local-authority-district/18> .

<http://transport.data.gov.uk/id/local-authority/1116>
  owl:sameAs <http://statistics.data.gov.uk/id/local-authority/18> .

<http://transport.data.gov.uk/id/road/B3178>
  a traffic:Road ;
  rdfs:label "B3178" ;
  rdfs:label "Salterton Road"@en ;
  skos:prefLabel "B3178" ;
  skos:altLabel "Salterton Road"@en ;
  skos:notation "B3178"^^traffic:RoadNumber ;
  area:country <http://statistics.data.gov.uk/id/country?name=England> ;
  area:region <http://statistics.data.gov.uk/id/government-office-region/K> ;
  area:localAuthority <http://statistics.data.gov.uk/id/local-authority/18> ;
  area:district <http://statistics.data.gov.uk/id/local-authority-district/18> ;
  traffic:roadCategory 
    <http://transport.data.gov.uk/def/road-category/b> ,
    <http://transport.data.gov.uk/def/road-category/urban> ;
  traffic:count <http://transport.data.gov.uk/id/traffic-count-point/13/direction/E/hour/2001-10-08T17:00:00> .

<http://transport.data.gov.uk/id/traffic-count-point/13>
  a traffic:CountPoint ;
  rdfs:label "Salterton Road, EAST OF DINAN WAY, EXMOUTH"@en ;
  rdfs:comment "Salterton Road, EAST OF DINAN WAY, EXMOUTH"@en ;
  skos:notation "13"^^traffic:CountPointNumber ;
  traffic:road <http://transport.data.gov.uk/id/road/B3178> ;
  traffic:roadName "Salterton Road"@en ;
  traffic:roadCategory 
    <http://transport.data.gov.uk/def/road-category/b> ,
    <http://transport.data.gov.uk/def/road-category/urban> ;
  space:easting 302600 ;
  space:northing 81984 ;
  geo:lat 50.6294 ;
  geo:long -3.3784 ;
  area:country <http://statistics.data.gov.uk/id/country?name=England> ;
  area:region <http://statistics.data.gov.uk/id/government-office-region/K> ;
  area:localAuthority <http://statistics.data.gov.uk/id/local-authority/18> ;
  area:district <http://statistics.data.gov.uk/id/local-authority-district/18> ;
  traffic:count <http://transport.data.gov.uk/id/traffic-count-point/13/direction/E/hour/2001-10-08T17:00:00> .

<http://transport.data.gov.uk/id/traffic-count-point/13/direction/E/hour/2001-10-08T17:00:00>
  a traffic:Count ;
  rdfs:label "8 Oct 2001 17:00-18:00 - East - Salterton Road, EAST OF DINAN WAY, EXMOUTH"@en ;
  traffic:countPoint <http://transport.data.gov.uk/id/traffic-count-point/13> ;
  traffic:road <http://transport.data.gov.uk/id/road/B3178> ;
  traffic:direction <http://dbpedia.org/resource/East> ;
  traffic:countHour <http://placetime.com/interval/gregorian/2001-10-08T17:00:00Z/PT1H> ;
  traffic:observation <http://transport.data.gov.uk/id/traffic-count-point/13/direction/E/hour/2001-10-08T17:00:00/type/bicycle> .

<http://dbpedia.org/resource/East>
  rdfs:label "East"@en .

<http://placetime.com/interval/gregorian/2001-10-08T17:00:00Z/PT1H>
  a traffic:CountHour ;
  rdfs:label "8 Oct 2001, 17:00-18:00"@en ;
  time:hasBeginning <http://placetime.com/instant/gregorian/2001-10-08T17:00:00Z> ;
  time:hasEnd <http://placetime.com/instant/gregorian/2001-10-08T18:00:00Z> ;
  time:hasDurationDescription _:OneHour ;
  time:intervalDuring <http://dbpedia.org/resource/2001> .

_:OneHour a time:DurationDescription ;
  rdfs:label "one hour"@en ;
  time:years 0 ;
  time:months 0 ;
  time:days 0 ;
  time:hours 1 ;
  time:minutes 0 ;
  time:seconds 0 .

<http://placetime.com/instant/gregorian/2001-10-08T17:00:00Z>
  a time:Instant ;
  rdfs:label "8 Oct 2001, 17:00"@en ;
  time:inXSDDateTime "2001-10-08T17:00:00Z"^^xsd:dateTime ;
  time:inDateTime [
    a time:DateTimeDescription ;
    time:unitType time:unitHour ;
    time:year "2001"^^xsd:gYear ;
    time:month "--10"^^xsd:gMonth ;
    time:day "---08"^^xsd:gDay ;
    time:hour 17 ;
  ] .

<http://placetime.com/instant/gregorian/2001-10-08T18:00:00Z>
  a time:Instant ;
  rdfs:label "8 Oct 2001, 18:00"@en ;
  time:inXSDDateTime "2001-10-08T18:00:00Z"^^xsd:dateTime ;
  time:inDateTime [
    a time:DateTimeDescription ;
    time:unitType time:unitHour ;
    time:year "2001"^^xsd:gYear ;
    time:month "--10"^^xsd:gMonth ;
    time:day "---08"^^xsd:gDay ;
    time:hour 18 ;
  ] .

<http://dbpedia.org/resource/2001>
  a time:Interval ;
  rdfs:label "2001" ;
  rdf:value "2001"^^xsd:gYear ;
  time:intervalEquals <http://placetime.com/interval/gregorian/2001-01-01T00:00:00Z/P1Y> .

<http://transport.data.gov.uk/id/traffic-count-point/13/direction/E/hour/2001-10-08T17:00:00/type/bicycle>
  a scovo:Item ;
  rdfs:label "8 Oct 2001 17:00-18:00 - East - Salterton Road, EAST OF DINAN WAY, EXMOUTH"@en ;
  traffic:count <http://transport.data.gov.uk/id/traffic-count-point/13/direction/E/hour/2001-10-08T17:00:00> ;
  traffic:countPoint <http://transport.data.gov.uk/id/traffic-count-point/13> ;
  traffic:direction <http://dbpedia.org/resource/East> ;
  traffic:countHour <http://placetime.com/interval/gregorian/2001-10-08T17:00:00Z/PT1H> ;
  traffic:vehicleType <http://transport.data.gov.uk/def/vehicle/bicycle> ;
  rdf:value 2 .

We’ll start by writing out some RDF for our record, using Turtle here for readability, and use unprefixed names to indicate classes, properties and datatypes, just so we can see what we need. Then we’ll see how those requirements match up to existing vocabularies and ontologies that we can reuse. Anything that’s left over we’re going to have to put in our own vocabulary. We’ll call this

http://transport.data.gov.uk/def/traffic/

All the classes, properties and datatypes that we define will eventually use that namespace.

Let’s focus on this record; I find it easiest to use an actual example rather than talk in abstract:

"England","South West","K",1115.00,"18","Devon County Council",
13,"B3178",,"B Urban","Salterton Road",
"Salterton Road, EAST OF DINAN WAY, EXMOUTH",302600,81984,
8/10/2001 00:00:00,"E",17,2,2,400,5,41,0,2,0,0,0,0,2,450

We’ll put this into RDF bit by bit.

Areas

First, let’s look at the areas and local authorities. The kind of RDF that we want to have looks like:

<http://statistics.data.gov.uk/id/country?name=England>
  a :Country ;
  :name "England"@en .

<http://statistics.data.gov.uk/id/government-office-region/K>
  a :GovernmentOfficeRegion ;
  :name "South West"@en ;
  :code "K"^^:ONScode ;
  :containedBy <http://statistics.data.gov.uk/id/country?name=England> .

<http://statistics.data.gov.uk/id/local-authority-district/18>
  a :LocalAuthorityDistrict ;
  :code "18"^^:ONScode ;
  :code "1115"^^:DfTLAcode ;
  :localAuthority <http://statistics.data.gov.uk/id/local-authority/18> ;
  :containedBy <http://statistics.data.gov.uk/id/country?name=England> ;
  :containedBy <http://statistics.data.gov.uk/id/government-office-region/K> .

<http://transport.data.gov.uk/id/local-authority-district/1115>
  :sameAs <http://statistics.data.gov.uk/id/local-authority-district/18> .

<http://statistics.data.gov.uk/id/local-authority/18>
  a :LocalAuthority ;
  :name "Devon County Council"@en ;
  :code "18"^^:ONSLAcode ;
  :code "1115"^^:DfTLAcode ;
  :localAuthorityDistrict <http://statistics.data.gov.uk/id/local-authority-district/18> .

<http://transport.data.gov.uk/id/local-authority/1116>
  :sameAs <http://statistics.data.gov.uk/id/local-authority/18> .

To work out what we need to put in our schema, we should first look at what existing vocabularies there are that could help. These areas are already defined elsewhere, so we can just use the same vocabulary for countries, regions, local authority districts and local authorities as is used there. The vocabularies that are useful here are:

• http://statistics.data.gov.uk/def/administrative-geography/ which defines classes and properties related to administrative areas and local authorities (as described by the Office of National Statistics)
• http://data.ordnancesurvey.co.uk/ontology/admingeo/ which also defines classes and properties related to administrative areas (as described by the Ordnance Survey)
• http://data.ordnancesurvey.co.uk/ontology/spatialrelations/, also developed by John Goodwin at the Ordnance Survey, which defines spatial relationships between areas

There are other commonly used vocabularies that it’s helpful to know about:

• RDFS is designed for representing RDF schemas, but it has a few general-purpose properties that are good to know, namely rdfs:label (the label for a thing) and rdfs:comment (a comment or description about the thing).
• SKOS is designed for representing concept schemes, but again it has a few properties that can be used with any set of linked data, in particular skos:prefLabel (the preferred label for a thing), skos:altLabel (an alternative label for a thing) and skos:notation (a code for the thing).
• OWL is designed for representing ontologies, but it has one very important property that you should know about — owl:sameAs — which is used to link two things that are the same thing.
• XML Schema datatypes can be used within RDF, which is useful for things like dates, times, integers and so on.
• For our purposes here, OWL-Time is going to prove useful, as it has a bunch of properties that are used to represent instants and durations.

If we look through the RDF above, the only thing that isn’t covered by these vocabularies is the DfTLAcode datatype. If we use the http://transport.data.gov.uk/def/traffic/ namespace, there’s not really any need to indicate that this is a transport-related code, so we can just call it LAcode. Let’s define that datatype:

<http://transport.data.gov.uk/def/traffic/LAcode>
  a rdfs:Datatype ;
  rdfs:label "Local Authority Code"@en .

That’s it. Now here’s the Turtle for the areas with the relevant namespaces added, and property names changed where appropriate:

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#"> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix area: <http://statistics.data.gov.uk/def/administrative-geography/> .
@prefix space: <http://data.ordnancesurvey.co.uk/ontology/spatialrelations/> .
@prefix admingeo: <http://data.ordnancesurvey.co.uk/ontology/admingeo/> .
@prefix traffic: <http://transport.data.gov.uk/def/traffic/> .

<http://statistics.data.gov.uk/id/country?name=England>
  a area:Country ;
  rdfs:label "England"@en .

<http://statistics.data.gov.uk/id/government-office-region/K>
  a admingeo:GovernmentOfficeRegion ;
  rdfs:label "South West"@en ;
  skos:notation "K"^^area:StandardCode ;
  area:country <http://statistics.data.gov.uk/id/country?name=England> .

<http://statistics.data.gov.uk/id/local-authority-district/18>
  a area:LocalAuthorityDistrict ;
  skos:notation "18"^^area:StandardCode ;
  skos:notation "1115"^^traffic:LAcode ;
  area:localAuthority <http://statistics.data.gov.uk/id/local-authority/18> ;
  area:country <http://statistics.data.gov.uk/id/country?name=England> ;
  area:region <http://statistics.data.gov.uk/id/government-office-region/K> .

<http://transport.data.gov.uk/id/local-authority-district/1115>
  owl:sameAs <http://statistics.data.gov.uk/id/local-authority-district/18> .

<http://statistics.data.gov.uk/id/local-authority/18>
  a area:LocalAuthority ;
  rdfs:label "Devon County Council"@en ;
  skos:notation "18"^^area:StandardCode ;
  skos:notation "1115"^^traffic:LAcode ;
  area:coverage <http://statistics.data.gov.uk/id/local-authority-district/18> .

<http://transport.data.gov.uk/id/local-authority/1116>
  owl:sameAs <http://statistics.data.gov.uk/id/local-authority/18> .

Roads

Here’s the kind of RDF we want to create for roads:

<http://transport.data.gov.uk/id/road/B3178>
  a :Road ;
  :code "B3178"^^:RoadNumber .

Obviously, we need a class for roads:

<http://transport.data.gov.uk/def/traffic/Road>
  a rdfs:Class ;
  rdfs:label "Road"@en .

Wherever there’s a code, I like to reuse skos:notation. But it’s important to define a datatype for the values used with that notation because (as we saw with local authorities above) there may be several different coding schemes that apply to the same Thing, and we need to be able to distinguish between them in case they clash. So:

<http://transport.data.gov.uk/def/traffic/RoadNumber>
  a rdfs:Datatype ;
  rdfs:label "Road Number"@en .

That’s all we have to define for roads; now the RDF can look like:

@prefix traffic: <http://transport.data.gov.uk/def/traffic/> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .

<http://transport.data.gov.uk/id/road/B3178>
  a traffic:Road ;
  skos:notation "B3178"^^traffic:RoadNumber .

Count Points

On to count points. Here’s the sketch of the RDF we want to create:

<http://transport.data.gov.uk/id/traffic-count-point/13>
  a :TrafficCountPoint ;
  :description "Salterton Road, EAST OF DINAN WAY, EXMOUTH"@en ;
  :code "13"^^:CountPointNumber ;
  :road <http://transport.data.gov.uk/id/road/B3178> ;
  :roadName "Salterton Road"@en ;
  :roadCategory 
    <http://transport.data.gov.uk/def/road-category/b> ,
    <http://transport.data.gov.uk/def/road-category/urban> ;
  :easting 302600 ;
  :northing 81984 ;
  :localAuthority <http://statistics.data.gov.uk/id/local-authority/18> ;
  :localAuthorityDistrict <http://statistics.data.gov.uk/id/local-authority-district/18> .

Of these, the description could be done with rdfs:comment. The code can be held by a skos:notation (provided we define a datatype for the count point number):

<http://transport.data.gov.uk/def/traffic/CountPointNumber>
  a rdfs:Datatype ;
  rdfs:label "Traffic Count Point Number"@en .

Properties for easting and northing are actually defined by the OS’s spatial relations ontology (although unfortunately neither the ontology nor the property is currently resolvable; the only way you’d know this is through looking at their use in the conversion of the edubase data). Links to local authorities and local authority districts can be done using the ONS-based administrative geography ontology, which again is currently only guessable at by looking at the online data.

That leaves us with a traffic:CountPoint class (no point calling it TrafficCountPoint if the namespace provides sufficient disambiguation):

<http://transport.data.gov.uk/def/traffic/CountPoint>
  a rdfs:Class ;
  rdfs:label "Traffic Count Point"@en .

A road property to point to a road:

<http://transport.data.gov.uk/def/traffic/road>
  a rdf:Property ;
  rdfs:label "road"@en ;
  rdfs:range <http://transport.data.gov.uk/def/traffic/Road> .

Note that properties are by convention named with a lowercase first letter, whereas classes are named with an uppercase first letter. It’s a good idea to follow that convention. Note also that I’ve defined a rdfs:range for this property, which means that anything that’s the object in a RDF statement that involves this property must be a traffic:Road.

We need a road name property to give the name of the road at the count point.

<http://transport.data.gov.uk/def/traffic/road>
  a rdf:Property ;
  rdfs:label "road name"@en ;
  rdfs:range <http://transport.data.gov.uk/def/traffic/Road> .

We also need a road category property to point to the categor(ies) of the road at the count point:

<http://transport.data.gov.uk/def/traffic/roadCategory>
  a rdf:Property ;
  rdfs:label "road category"@en .

You’ll remember that we defined different road categories using SKOS, such that each road category is a skos:Concept. But to give a range to the traffic:roadCategory property, we need to create a class for all the things that are categories of road. These are all skos:Concepts, and we can indicate that through an rdfs:subClassOf property:

<http://transport.data.gov.uk/def/traffic/RoadCategory>
  a rdfs:Class ;
  rdfs:subClassOf skos:Concept ;
  rdfs:label "Road Category"@en .

use this as the range of the traffic:roadCategory property:

<http://transport.data.gov.uk/def/traffic/roadCategory>
  a rdf:Property ;
  rdfs:label "road category"@en ;
  rdfs:range <http://transport.data.gov.uk/def/traffic/RoadCategory> .

and amend the concept scheme we created to include references to this new class, for example:

<motorway> a traffic:RoadCategory ;
  skos:prefLabel "Motorway"@en ;
  skos:broader <major> ;
  skos:scopeNote "Major roads often used for long distance travel. They are usually three or more lanes in each direction and generally have the maximum speed limit of 70mph."@en ;
  skos:inScheme <> .

So here is the RDF with the relevant properties properly defined:

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix area: <http://statistics.data.gov.uk/def/administrative-geography/> .
@prefix space: <http://data.ordnancesurvey.co.uk/ontology/spatialrelations/> .
@prefix traffic: <http://transport.data.gov.uk/def/traffic/> .

<http://transport.data.gov.uk/id/traffic-count-point/13>
  a traffic:CountPoint ;
  rdfs:comment "Salterton Road, EAST OF DINAN WAY, EXMOUTH"@en ;
  skos:notation "13"^^traffic:CountPointNumber ;
  traffic:road <http://transport.data.gov.uk/id/road/B3178> ;
  traffic:roadName "Salterton Road"@en ;
  traffic:roadCategory 
    <http://transport.data.gov.uk/def/road-category/b> ,
    <http://transport.data.gov.uk/def/road-category/urban> ;
  space:easting 302600 ;
  space:northing 81984 ;
  area:localAuthority <http://statistics.data.gov.uk/id/local-authority/18> ;
  area:district <http://statistics.data.gov.uk/id/local-authority-district/18> .

Traffic Counts

On to traffic counts. The un-namespaced RDF should look like:

<http://transport.data.gov.uk/id/traffic-count-point/13/direction/E/hour/2001-10-08T17:00:00>
  a :TrafficCount ;
  :countPoint <http://transport.data.gov.uk/id/traffic-count-point/13> ;
  :direction <http://dbpedia.org/resource/East> ;
  :hour <http://placetime.com/interval/gregorian/2001-10-08T17:00:00Z/PT1H> .

So for that we need a class for traffic counts:

<http://transport.data.gov.uk/def/traffic/Count>
  a rdfs:Class ;
  rdfs:label "Traffic Count"@en .

a property that can link to the traffic count to the count point where the count is taken:

<http://transport.data.gov.uk/def/traffic/countPoint>
  a rdf:Property ;
  rdfs:label "traffic count point"@en ;
  rdfs:range <http://transport.data.gov.uk/def/traffic/CountPoint> .

a property to link to the the direction the traffic is flowing in (we can’t put a range on this one because the DBPedia resources we’re using don’t have a common type):

<http://transport.data.gov.uk/def/traffic/direction>
  a rdf:Property ;
  rdfs:label "traffic direction"@en .

and finally a property to link to the hour during which the measurement was taken. This last one is a very common thing to need to do, so we’d imagine that there might be an existing property defined somewhere that we could use. SDMX, which includes a standard for representing statistical information in XML, defines a REF_PERIOD field which would seem to suit our purposes, but we don’t yet have a proper mapping of SDMX into RDF (I’ve had an initial cut, but it needs some input from statisticians).

So for now, we’ll use a specific property in our own namespace; we can always indicate that it’s a sub-property of a future SDMX property at a later date. I’m going to call it countHour and give it a domain of traffic:Count to indicate that the property has a pretty specific use for providing the count for an hour. We could just give its range as a generic time:Interval, but the kind of hours that are traffic count hours are kinda special intervals: they’re obviously an hour long, but are also restricted to start and end on the hour, cover an hour between 7am and 7pm, and don’t occur in winter. So it feels like we should have a special kind of interval for that purpose:

<http://transport.data.gov.uk/def/traffic/countHour>
  a rdf:Property ;
  rdfs:label "hour of count"@en ;
  rdfs:domain <http://transport.data.gov.uk/def/traffic/Count> ;
  rdfs:range <http://transport.data.gov.uk/def/traffic/CountHour> .

<http://transport.data.gov.uk/def/traffic/CountHour>
  a rdfs:Class ;
  rdfs:subClassOf time:Interval ;
  rdfs:label "Count Hour"@en .

All those properties were in the traffic namespace, so here’s the RDF with it added:

@prefix traffic: <http://transport.data.gov.uk/def/traffic/> .

<http://transport.data.gov.uk/id/traffic-count-point/13/direction/E/hour/2001-10-08T17:00:00>
  a traffic:Count ;
  traffic:countPoint <http://transport.data.gov.uk/id/traffic-count-point/13> ;
  traffic:direction <http://dbpedia.org/resource/East> ;
  traffic:countHour <http://placetime.com/interval/gregorian/2001-10-08T17:00:00Z/PT1H> .

Cardinal Directions

As I discussed in the last instalment, we’re not actually going to mint URIs for cardinal directions, but that doesn’t mean we can’t make statements about them in the RDF we generate. As I’ll discuss in more depth in the next instalment, it’s always good to provide a label at the very least:

<http://dbpedia.org/resource/East>
  rdfs:label "East"@en .

Intervals and Instants

Let’s look now at the RDF we want to generate about the hour during which the count was taken. As I’ve said above, these hours are a special kind of interval, and we’ve already created a class for them. I also discussed earlier that the things about this interval that are really useful for the purposes of querying are the year during which the count was taken and the hour at which it was taken, so we should pull out at least those pieces of information. Time-based data can be represented in RDF using the OWL-Time ontology.

Unfortunately, expressing time very specifically gets. This is what the statements we want to make look like using OWL-Time:

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix time: <http://www.w3.org/2006/time> .

<http://placetime.com/interval/gregorian/2001-10-08T17:00:00Z/PT1H>
  a traffic:CountHour ;
  rdfs:label "8 Oct 2001, 17:00-18:00"@en ;
  time:hasBeginning <http://placetime.com/instant/gregorian/2001-10-08T17:00:00Z> ;
  time:hasEnd <http://placetime.com/instant/gregorian/2001-10-08T18:00:00Z> ;
  time:hasDurationDescription _:OneHour ;
  time:intervalDuring <http://dbpedia.org/resource/2001> .

_:OneHour a time:DurationDescription ;
  rdfs:label "one hour"@en ;
  time:years 0 ;
  time:months 0 ;
  time:days 0 ;
  time:hours 1 ;
  time:minutes 0 ;
  time:seconds 0 .

<http://placetime.com/instant/gregorian/2001-10-08T17:00:00Z>
  a time:Instant ;
  rdfs:label "8 Oct 2001, 17:00"@en ;
  time:inXSDDateTime "2001-10-08T17:00:00Z"^^xsd:dateTime ;
  time:inDateTime [
    a time:DateTimeDescription ;
    time:unitType time:unitHour ;
    time:year "2001"^^xsd:gYear ;
    time:month "--10"^^xsd:gMonth ;
    time:day "---08"^^xsd:gDay ;
    time:hour 17 ;
  ] .

<http://placetime.com/interval/gregorian/2001-10-08T18:00:00Z>
  a time:Instant ;
  rdfs:label "8 Oct 2001, 18:00"@en ;
  time:inXSDDateTime "2001-10-08T18:00:00Z"^^xsd:dateTime ;
  time:inDateTime [
    a time:DateTimeDescription ;
    time:unitType time:unitHour ;
    time:year "2001"^^xsd:gYear ;
    time:month "--10"^^xsd:gMonth ;
    time:day "---08"^^xsd:gDay ;
    time:hour 18 ;
  ] .

<http://dbpedia.org/resource/2001>
  a time:Interval ;
  rdfs:label "2001" ;
  rdf:value "2001"^^xsd:gYear ;
  time:intervalEquals <http://placetime.com/interval/gregorian/2001-01-01T00:00:00Z/P1Y> .

Observations

Finally we’re on to the observations themselves. The un-namespaced RDF looks like:

<http://transport.data.gov.uk/id/traffic-count-point/13/direction/E/hour/2001-10-08T17:00:00/type/bicycle>
  a :Observation ;
  :count <http://transport.data.gov.uk/id/traffic-count-point/13/direction/E/hour/2001-10-08T17:00:00> ;
  :vehicleType <http://transport.data.gov.uk/def/vehicle/bicycle> ;
  :value 2 .

The SCOVO vocabulary exists to represent statistical information like this. In SCOVO, observations are called scovo:Items, the value of the statistical measure itself (the count in this case) should be held in the rdf:value property, and any other properties should be subtypes of scovo:dimension, which has a domain of scovo:Dimension.

To fit in with SCOVO, then, we need to have the pointer to the count that this observation belongs to as a property that is a sub-property of scovo:dimension:

<http://transport.data.gov.uk/def/traffic/count>
  a rdf:Property ;
  rdfs:subPropertyOf scovo:dimension ;
  rdfs:label "count"@en ;
  rdfs:range <http://transport.data.gov.uk/def/traffic/Count> .

We might be tempted to indicate that the type of thing pointed to by the traffic:count property is a subclass of scovo:Dimension, but this is unnecessary and probably untrue: there might exist some traffic counts that aren’t dimensions, and the ones that are will be linked to by the traffic:count property can be inferred to be dimensions.

Similarly, the property that provides the pointer to the vehicle type should be a sub-property of scovo:dimension and we need a class for those various vehicle types in order to restrict the range of that property:

<http://transport.data.gov.uk/def/vehicleType>
  a rdf:Property ;
  rdfs:subPropertyOf scovo:dimension ;
  rdfs:label "vehicle type"@en ;
  rdfs:range <http://transport.data.gov.uk/def/VehicleType> .

<http://transport.data.gov.uk/def/VehicleType>
  a rdfs:Class ;
  rdfs:subClassOf skos:Concept ;
  rdfs:label "Vehicle Type"@en .

Of course all the concepts that we created for the vehicle types need to be designated as instances of this new traffic:VehicleType class:

<bicycle> a traffic:VehicleType ;
  ... .

So, the RDF with the proper namespaces is:

@prefix scovo: <http://purl.org/NET/scovo#> .
@prefix traffic: <http://transport.data.gov.uk/def/traffic/> .

<http://transport.data.gov.uk/id/traffic-count-point/13/direction/E/hour/2001-10-08T17:00:00/type/bicycle>
  a scovo:Item ;
  traffic:count <http://transport.data.gov.uk/id/traffic-count-point/13/direction/E/hour/2001-10-08T17:00:00> ;
  traffic:vehicleType <http://transport.data.gov.uk/def/vehicle/bicycle> ;
  rdf:value 2 .

That concludes our initial walkthrough of the data to create a vocabulary. I’ve duplicated the schema and the example data below so that it’s all in one place. But it’s not quite done. In the next instalment, I’ll look at adding some finishing touches that make the RDF easier to use.

Schema

This is the full schema. It contains just six classes, seven properties and three datatypes at the moment, so it’s pretty small as vocabularies go. We’ve been able to reuse a lot of classes, properties and datatypes that have already been defined elsewhere in the RDF itself, so this vocabulary is pretty focused on just what we need to describe traffic counts.

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix scovo: <http://purl.org/NET/scovo#> .
@prefix time: <http://www.w3.org/2006/time> .

# Classes #

<http://transport.data.gov.uk/def/traffic/Road>
  a rdfs:Class ;
  rdfs:label "Road"@en .

<http://transport.data.gov.uk/def/traffic/CountPoint>
  a rdfs:Class ;
  rdfs:label "Traffic Count Point"@en .

<http://transport.data.gov.uk/def/traffic/Count>
  a rdfs:Class ;
  rdfs:label "Traffic Count"@en .

<http://transport.data.gov.uk/def/traffic/RoadCategory>
  a rdfs:Class ;
  rdfs:subClassOf skos:Concept ;
  rdfs:label "Road Category"@en .    

<http://transport.data.gov.uk/def/traffic/CountHour>
  a rdfs:Class ;
  rdfs:subClassOf time:Interval ;
  rdfs:label "Count Hour"@en .

<http://transport.data.gov.uk/def/VehicleType>
  a rdfs:Class ;
  rdfs:subClassOf skos:Concept ;
  rdfs:label "Vehicle Type"@en .

# Properties #

<http://transport.data.gov.uk/def/traffic/road>
  a rdf:Property ;
  rdfs:label "road name"@en ;
  rdfs:range <http://transport.data.gov.uk/def/traffic/Road> .

<http://transport.data.gov.uk/def/traffic/countPoint>
  a rdf:Property ;
  rdfs:label "traffic count point"@en ;
  rdfs:range <http://transport.data.gov.uk/def/traffic/CountPoint> .

<http://transport.data.gov.uk/def/traffic/count>
  a rdf:Property ;
  rdfs:subPropertyOf scovo:dimension ;
  rdfs:label "count"@en ;
  rdfs:range <http://transport.data.gov.uk/def/traffic/Count> .

<http://transport.data.gov.uk/def/traffic/roadCategory>
  a rdf:Property ;
  rdfs:label "road category"@en ;
  rdfs:range <http://transport.data.gov.uk/def/traffic/RoadCategory> .

<http://transport.data.gov.uk/def/traffic/direction>
  a rdf:Property ;
  rdfs:label "traffic direction"@en .

<http://transport.data.gov.uk/def/traffic/countHour>
  a rdf:Property ;
  rdfs:label "hour of count"@en ;
  rdfs:domain <http://transport.data.gov.uk/def/traffic/Count> ;
  rdfs:range <http://transport.data.gov.uk/def/traffic/CountHour> .

<http://transport.data.gov.uk/def/vehicleType>
  a rdf:Property ;
  rdfs:subPropertyOf scovo:dimension ;
  rdfs:label "vehicle type"@en ;
  rdfs:range <http://transport.data.gov.uk/def/VehicleType> .

# Datatypes #

<http://transport.data.gov.uk/def/traffic/LAcode>
  a rdfs:Datatype ;
  rdfs:label "Local Authority Code"@en .

<http://transport.data.gov.uk/def/traffic/RoadNumber>
  a rdfs:Datatype ;
  rdfs:label "Road Number"@en .

<http://transport.data.gov.uk/def/traffic/CountPointNumber>
  a rdfs:Datatype ;
  rdfs:label "Traffic Count Point Number"@en .

RDF Data

Here’s a sample set of data. It looks like rather a lot to simply describe the number of bicycles at a particular point on a road (and it doesn’t even include the SKOS concept schemes that we did last time), but (a) it all provides valuable context for that measurement and (b) most of it will be reused by a lot of other measurements.

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#"> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix time: <http://www.w3.org/2006/time> .
@prefix scovo: <http://purl.org/NET/scovo#> .
@prefix area: <http://statistics.data.gov.uk/def/administrative-geography/> .
@prefix admingeo: <http://data.ordnancesurvey.co.uk/ontology/admingeo/> .
@prefix space: <http://data.ordnancesurvey.co.uk/ontology/spatialrelations/> .
@prefix traffic: <http://transport.data.gov.uk/def/traffic/> .

<http://statistics.data.gov.uk/id/country?name=England>
  a area:Country ;
  rdfs:label "England"@en .

<http://statistics.data.gov.uk/id/government-office-region/K>
  a admingeo:GovernmentOfficeRegion ;
  rdfs:label "South West"@en ;
  skos:notation "K"^^area:StandardCode ;
  area:country <http://statistics.data.gov.uk/id/country?name=England> .

<http://statistics.data.gov.uk/id/local-authority-district/18>
  a area:LocalAuthorityDistrict ;
  skos:notation "18"^^area:StandardCode ;
  skos:notation "1115"^^traffic:LAcode ;
  area:localAuthority <http://statistics.data.gov.uk/id/local-authority/18> ;
  area:country <http://statistics.data.gov.uk/id/country?name=England> ;
  area:region <http://statistics.data.gov.uk/id/government-office-region/K> .

<http://transport.data.gov.uk/id/local-authority-district/1115>
  owl:sameAs <http://statistics.data.gov.uk/id/local-authority-district/18> .

<http://statistics.data.gov.uk/id/local-authority/18>
  a area:LocalAuthority ;
  rdfs:label "Devon County Council"@en ;
  skos:notation "18"^^area:StandardCode ;
  skos:notation "1115"^^traffic:LAcode ;
  area:coverage <http://statistics.data.gov.uk/id/local-authority-district/18> .

<http://transport.data.gov.uk/id/local-authority/1116>
  owl:sameAs <http://statistics.data.gov.uk/id/local-authority/18> .

<http://transport.data.gov.uk/id/road/B3178>
  a traffic:Road ;
  skos:notation "B3178"^^traffic:RoadNumber .

<http://transport.data.gov.uk/id/traffic-count-point/13>
  a traffic:CountPoint ;
  rdfs:comment "Salterton Road, EAST OF DINAN WAY, EXMOUTH"@en ;
  skos:notation "13"^^traffic:CountPointNumber ;
  traffic:road <http://transport.data.gov.uk/id/road/B3178> ;
  traffic:roadName "Salterton Road"@en ;
  traffic:roadCategory 
    <http://transport.data.gov.uk/def/road-category/b> ,
    <http://transport.data.gov.uk/def/road-category/urban> ;
  space:easting 302600 ;
  space:northing 81984 ;
  area:localAuthority <http://statistics.data.gov.uk/id/local-authority/18> ;
  area:district <http://statistics.data.gov.uk/id/local-authority-district/18> .

<http://transport.data.gov.uk/id/traffic-count-point/13/direction/E/hour/2001-10-08T17:00:00>
  a traffic:Count ;
  traffic:countPoint <http://transport.data.gov.uk/id/traffic-count-point/13> ;
  traffic:direction <http://dbpedia.org/resource/East> ;
  traffic:countHour <http://placetime.com/interval/gregorian/2001-10-08T17:00:00Z/PT1H> .

<http://dbpedia.org/resource/East>
  rdfs:label "East"@en .

<http://placetime.com/interval/gregorian/2001-10-08T17:00:00Z/PT1H>
  a traffic:CountHour ;
  rdfs:label "8 Oct 2001, 17:00-18:00"@en ;
  time:hasBeginning <http://placetime.com/instant/gregorian/2001-10-08T17:00:00Z> ;
  time:hasEnd <http://placetime.com/instant/gregorian/2001-10-08T18:00:00Z> ;
  time:hasDurationDescription _:OneHour ;
  time:intervalDuring <http://dbpedia.org/resource/2001> .

_:OneHour a time:DurationDescription ;
  rdfs:label "one hour"@en ;
  time:years 0 ;
  time:months 0 ;
  time:days 0 ;
  time:hours 1 ;
  time:minutes 0 ;
  time:seconds 0 .

<http://placetime.com/instant/gregorian/2001-10-08T17:00:00Z>
  a time:Instant ;
  rdfs:label "8 Oct 2001, 17:00"@en ;
  time:inXSDDateTime "2001-10-08T17:00:00Z"^^xsd:dateTime ;
  time:inDateTime [
    a time:DateTimeDescription ;
    time:unitType time:unitHour ;
    time:year "2001"^^xsd:gYear ;
    time:month "--10"^^xsd:gMonth ;
    time:day "---08"^^xsd:gDay ;
    time:hour 17 ;
  ] .

<http://placetime.com/instant/gregorian/2001-10-08T18:00:00Z>
  a time:Instant ;
  rdfs:label "8 Oct 2001, 18:00"@en ;
  time:inXSDDateTime "2001-10-08T18:00:00Z"^^xsd:dateTime ;
  time:inDateTime [
    a time:DateTimeDescription ;
    time:unitType time:unitHour ;
    time:year "2001"^^xsd:gYear ;
    time:month "--10"^^xsd:gMonth ;
    time:day "---08"^^xsd:gDay ;
    time:hour 18 ;
  ] .

<http://dbpedia.org/resource/2001>
  a time:Interval ;
  rdfs:label "2001" ;
  rdf:value "2001"^^xsd:gYear ;
  time:intervalEquals <http://placetime.com/interval/gregorian/2001-01-01T00:00:00Z/P1Y> .

<http://transport.data.gov.uk/id/traffic-count-point/13/direction/E/hour/2001-10-08T17:00:00/type/bicycle>
  a scovo:Item ;
  traffic:count <http://transport.data.gov.uk/id/traffic-count-point/13/direction/E/hour/2001-10-08T17:00:00> ;
  traffic:vehicleType <http://transport.data.gov.uk/def/vehicle/bicycle> ;
  rdf:value 2 .

This part of the process is the same as what you’d do if you were simply creating a RESTful API to a website. The principal is that everything has a URI, and if you resolve that URI you get information about the thing.

For the data.gov.uk site, we now have some guidelines about the design of URIs for the UK public sector. Basically, URIs for things should look like:

http://{sector}.data.gov.uk/id/{type of thing}/{thing identifier}

There’ll be plenty of examples in what follows.

Areas

Some of the things that we’ve identified as being part of the traffic count dataset already have centrally-defined identifiers. As part of other data.gov.uk work, we’ve defined URIs for administrative areas like countries, regions, local authority districts and local authorities. The templates for these URIs are:

http://statistics.data.gov.uk/id/country/{ONS code}
http://statistics.data.gov.uk/id/government-office-region/{ONS code}
http://statistics.data.gov.uk/id/local-authority-district/{ONS code}
http://statistics.data.gov.uk/id/local-authority/{ONS code}

We can use these identifiers directly for the regions, districts and local authorities. But there’s a problem with the country URI: we don’t have the ONS code for the country, only the name of the country. Fortunately, we’ve also defined URIs with this pattern:

http://statistics.data.gov.uk/id/country?name={country name}
http://statistics.data.gov.uk/id/government-office-region?name={region name}
http://statistics.data.gov.uk/id/local-authority-district?name={district name}
http://statistics.data.gov.uk/id/local-authority?name={authority name}

so in this situation we can use the name-based country URI and we’ll get redirected to the canonical, code-based URI.

Local authorities actually have two codes within the dataset that we have: the ONS code and a DfT code. I can well imagine that other datasets from the Department for Transport will only reference the DfT code, so it’s a good idea to create URIs that are based on these codes; later on, we can state that the two identifiers actually mean exactly the same thing.

http://transport.data.gov.uk/id/local-authority-district/{DfT code}
http://transport.data.gov.uk/id/local-authority/{DfT code}

So given the record:

"England","North West","B",4315.00,"00BZ","St.Helens Metropolitan Borough Council",
4,"U",,"Unclassified Urban",,
,352100,398200,
7/6/2001 00:00:00,"N",7,1,0,5,1,0,0,0,0,0,0,0,0,6

the URIs we’ve defined so far are:

http://statistics.data.gov.uk/id/country?name=England
http://statistics.data.gov.uk/id/government-office-region/B
http://statistics.data.gov.uk/id/local-authority-district/00BZ
http://statistics.data.gov.uk/id/local-authority/00BZ
http://transport.data.gov.uk/id/local-authority-district/4315
http://transport.data.gov.uk/id/local-authority/4315

Roads

Now we’re onto things that aren’t defined already. First is roads. If there’s a road number, the obvious thing to use is that road number; something like:

http://transport.data.gov.uk/id/road/{road number}

For example:

http://transport.data.gov.uk/id/road/B3178

If there isn’t a road number, we’ll have to construct a URI. Since each count point is on one particular road, we can use the identifier of the count point to identify the road, so:

http://transport.data.gov.uk/id/road/{class}-{count point number}

For example:

http://transport.data.gov.uk/id/road/U-4

Count Points

Count points can be identified through their number, so it makes sense to use that in the URI:

http://transport.data.gov.uk/id/traffic-count-point/{count point number}

For example:

http://transport.data.gov.uk/id/traffic-count-point/4

Counts

The counts themselves don’t have their own identifiers, but they can be identified through a combination of the count point that they’re associated with, the direction of travel of the traffic that’s being counted, and the date and time that the count is made. So we can create a URI that combines these things. To aid hackability, I’m going to build on top of the traffic count point URI that we’ve already defined:

http://transport.data.gov.uk/id/traffic-count-point/{count point number}/direction/{direction}/hour/{time}

For example:

http://transport.data.gov.uk/id/traffic-count-point/4/direction/N/hour/2001-06-07T07:00:00

Observations

Again, observations build on top of the counts by adding a vehicle type to the mix, so we can construct URIs that reflect that:

http://transport.data.gov.uk/id/traffic-count-point/{count point number}/direction/{direction}/hour/{time}/type/{vehicle type}

For example:

http://transport.data.gov.uk/id/traffic-count-point/4/direction/N/hour/2001-06-07T07:00:00/type/motor-vehicle

Road Categories

Road categories are a bit different from the kinds of things that we’ve been talking about so far: they are concepts. For these URIs we use a slightly different pattern from the URIs above: /def/ rather than /id/. For road categories we can use:

http://transport.data.gov.uk/def/road-category/{category}

For example:

http://transport.data.gov.uk/def/road-category/motorway

Vehicle Types

Vehicle types are also concepts, so have similar URIs:

http://transport.data.gov.uk/def/vehicle-category/{type}

For example:

http://transport.data.gov.uk/def/vehicle-category/HGVa5

Cardinal Directions

Cardinal directions are also concepts, but really they are global concepts, not specific to transport, or even to the UK. So it feels a bit strange to use URIs for them that imply that they somehow belong to data.gov.uk.

Fortunately, for this kind of general concept we can use URIs defined by DBPedia. DBPedia is a linked data view on Wikipedia, so it has URIs for everything that Wikipedia has a page about, making it an excellent general purpose resource. The relevant URIs for the cardinal directions are:

http://dbpedia.org/resource/North
http://dbpedia.org/resource/South
http://dbpedia.org/resource/East
http://dbpedia.org/resource/West

so that’s what we’ll use.

Dates, Times and Periods

For dates, times and periods, we can use the URIs provided by another general-purpose linked data resource: placetime.com. URIs for instants have the pattern:

http://placetime.com/instant/gregorian/{dateTime}

while periods have the pattern:

http://placetime.com/interval/gregorian/{dateTime}/{duration}

So the hour from 7-8am on 7th June 2001 would be:

http://placetime.com/interval/gregorian/2001-06-07T07:00:00/PT1H

and the year 2001 would be:

http://placetime.com/interval/gregorian/2001-01-01T00:00:00/P1Y

The thing is that the latter isn’t particularly approachable. Calendar years are used all over the place, so it would be nice to have a set of URIs for them that we use consistently. Again, DBPedia provides URIs for every year, such as:

http://dbpedia.org/resource/2001

so where we need to refer to a calendar year, it would be good to reuse that.

And that completes the sets of URIs that we need for this data. Stay tuned.

This raises the questions of “what information should you publish?” Let’s make this concrete by using a real example: UK Legislation, which TSO is publishing for OPSI as Linked Data.

UK Legislation now has a set of URIs that are explicitly intended to be used as unique identifiers for items of legislation and parts, sections, subsections and so on within them. If you request one of these URIs, requesting RDF/XML, you will get some information about that bit of legislation, such as:

• bibliographic metadata such as its title, publisher, created date and so on
• links to other related sections or items of legislation
• links to particular versions of that bit of legislation

So we provide some basic information, and the links we know about, ie those within UK Legislation.

It turns out that lots of things aside from UK Legislation reference legislation, and that when you publish information about them it’s helpful to be able to point to the relevant legislation. For example:

• the Home Office relate offences to sections of legislation that state that a particular activity is illegal and has a certain maximum penalty
• local authorities are bound to provide certain services by law, so there’s a natural pointer from the definition of a service to that law
• administrative areas such as counties and local authorities are defined by law, so when the Ordnance Survey publish information about those areas, it helps to point to the law in which their names are legally defined as the authority on which their statements are based
• the publication of notices posted within the London Gazette is enforced by legislation, and the text of the notices usually indicates which piece of legislation caused the notice to be published

These are all inward pointers. As we publish information about UK Legislation, we won’t know about all these links to the information we publish. But people who access information about UK Legislation might well want to know about those links. Wouldn’t it be useful to know — given an item of legislation — what it makes illegal, what it compels local authorities to do, which administrative areas it defines, which notices it has caused to be published?

We were discussing the same issue the other day in respect of spatial objects. The Ordnance Survey, or other organisations peddling spatial data, may define spatial objects, but other people define the things that those spatial objects represent, such as schools, roads, parks and so on. It’s obviously useful to go from a school to the spatial objects that represent its buildings, but it would also be useful to go from a spatial object that is a school building to the school.

So what should we, as publishers, do about the inward links (that we know about)? When we publish information about something should we also try to publish information about the things that (we know) reference that thing? I think the answer’s “yes,” at the very least in any human-readable access we give to the information. And from that come two further thoughts:

• If you are publishing data with outward links, it would be a good idea to provide feeds or other mechanisms that enable people to pull in basic information about the things that you’re publishing that link to something they’re publishing. SPARQL queries would do, but something a bit less general purpose and more approachable — I’m thinking a URL like http://example.org/links?url=http://example.net/linked/resource — would be better.

• Information from another source is going to have different provenance/trust etc characteristics than the primary information you publish. That needs to be clearly indicated somehow; sounds to me like a requirement for named graphs.

One of my favourite tweets from Rob McKinnon (aka @delineator) is this one:

because it’s one of the things that bugs me on occasion too, and because the issues he mentions are so vitally important when we’re talking about public sector information but (because they’re the hard issues) are easy to de-prioritise in the rush to make data available.

Let’s go back to basics: How do you know whether you can trust a piece of information? Think of an infographic in your daily newspaper showing the results of a survey. You could just decide based on your trust in the newspaper itself. But if you’re feeling suspicious, there are any number of things that you need to trust:

• the designer who created the infographic, that they didn’t skew the graphic to make it imply something that the data doesn’t warrant
• the data munger who cleaned up the data and supplied it to the designer, that they didn’t introduce errors into the data while cleaning it up
• the organisation who published the data, that they aggregated it accurately and published all the results
• the organisation who conducted the survey, that they surveyed a large enough and representative enough collection of people and collated the results accurately
• the people who responded to the survey, that they didn’t lie

What enables us to determine how much to trust the results of each of these steps? Well, if the organisation who conducted the survey published enough information such that anyone could replicate the survey if they wanted to, we’re more likely to trust their results. That’s at least partly because in order to publish sufficient information for someone to replicate the study, they have to go into the kind of detail that necessarily exposes biases the study might have, but also because they’re unlikely to be that open about what they did if they were trying to cover something up. That’s why reproducability is one of the fundamental principles in the scientific method.

That same principle applies at the data-processing end of the chain of processes that led to the infographic. We will trust the infographic more if we can get hold of

1. the raw survey results (open data)
2. details about all the programs that aggregated, cleaned up or otherwise transformed the data, including their source code (open source)

because with these details we could, if we chose, replicate the resulting data and create our own visualisation of it.

The question is, given some RDF, how do we provide enough detail about how it was generated to enable others to work out whether to trust it or not?

The answer should come as no surprise: “With RDF!”

I’ve been looking at a couple of vocabularies for recording provenance: the Open Provenance Model and the Provenance Vocabulary.

The Open Provenance Model is a general purpose model that can be expressed in RDF. It splits the world into three main things:

• Artifacts which are things that you might want to record the provenance of
• Processes which are things that happen to artifacts
• Agents who initiate processes

These three types of things interact with each other in three main ways:

• artifacts are generated by processes
• processes use artifacts
• processes are controlled by agents

and two subsidiary ones which occur as a result of these:

• artifacts are derived from other artifacts
• processes trigger other processes

So far so good. But then it starts getting complicated. A given process might use and generate several artifacts (for example, an XSLT transformation might use a source document and a stylesheet, and generate an index and a number of pages), so each of the three main relationships above is qualified through the use of a particular role.

Further, different artifacts might be used or created at different times in the process, so each of the relationships is also qualified with a timestamp. (The Open Provenance Model is built to describe processes that might take days, or even longer, with different bits of information coming into play at different times.)

And then to add one more twist, each provenance graph is just one possible account of the history of an item; in particular a different account might break down the processes into subprocesses, or aggregate the processes differently.

The complications of having timestamps on relationships, and having multiple accounts, means that describing provenance with the Open Provenance Model is a little tedious, especially when you’re mostly concerned about the provenance of data (as opposed to, say, a car).

The Provenance Vocabulary has the same basic types, which they call Artifacts, Executions and Actors, but the different roles that artifacts play are indicated through the properties prv:usedData, prv:usedGuideline and its sub-properties, and timestamps are associated directly with executions and artifacts. It’s also specifically oriented towards the kinds of operations that we typically need to do when transforming and publishing linked data.

To give you an idea about how it might work, here’s an illustration of how we might use the provenance vocabulary to describe the construction of some RDF from a CSV file:

Here are the prefix bindings. Note the reuse of the HTTP vocabulary, FOAF, Dublin Core and VoID.

@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix prv: <http://purl.org/net/provenance/ns#> .
@prefix prvTypes: <http://purl.org/net/provenance/types#> .
@prefix http: <http://www.w3.org/2006/http#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix dct: <http://purl.org/dc/terms/> .
@prefix void: <http://rdfs.org/ns/void#> .

The provenance record itself and caches of relevant documents somewhere web accessible; a log subdirectory on my website seems as good a place as any.

@base <http://www.jenitennison.com/log/2009-10-24/> .

Now the meat of the provenance information. I’m defining a dataset identified as http://statistics.data.gov.uk/id/region, which is a dataset of Government Office Regions within the UK. The resources described by the dataset have URIs of the form http://statistics.data.gov.uk/id/region/{regionCode}, where regionCode is a single capital letter (assigned by ONS).

<http://statistics.data.gov.uk/id/region> a void:Dataset ;
  dct:title "Government Office Regions" ;
  foaf:homepage <http://statistics.data.gov.uk/doc/region> ;
  void:exampleResource <http://statistics.data.gov.uk/id/region/H> ;
  void:uriRegexPattern "http://statistics.data.gov.uk/id/region/[A-Z]" ;
  void:subset _:GORRDF .

I’m not describing the provenance of this entire dataset here: the dataset of information about Government Office Regions will likely contain information from many different sources, created in many different ways at many different times. I’m just describing a particular subset of that information (identified here by a blank node with the ID _:GORRDF).

This dataset is captured as a dump in the web-accessible cache in which I’m keeping all the provenance-related information. Here we start seeing the provenance-related properties. The dataset was created by a prv:DataCreation event performed at 12:20 today by me. The creation used data from a CSV document that is also in the web-accessible cache, using the “guideline” (in this case an XSLT transformation) that is again in the web-accessible cache. I’ve also provided provenance information about that XSLT transformation (that it was created by me at 12:10 today; these times are made up, by the way! :)

_:GORRDF a void:Dataset ;
  a prv:DataItem ;
  prv:containedBy <cache/GOR_DEC_2008_EN_NC.rdf> ;
  void:dataDump <cache/GOR_DEC_2008_EN_NC.rdf> ;
  prv:createdBy [
    a prv:DataCreation ;
    prv:performedAt "2009-10-24T12:20:00Z"^^xsd:dateTime ;
    prv:performedBy _:Jeni ;
    prv:usedData [
      a prv:DataItem ;
      prv:containedBy <cache/GOR_DEC_2008_EN_NC.csv> ;
    ] ;
    prv:usedGuideline [
      a prv:DataItem ;
      prv:containedBy <cache/region.xsl> ;
      prv:createdBy [
        a prv:DataCreation ;
        prv:performedAt "2009-10-24T12:10:00Z"^^xsd:dateTime ;
        prv:performedBy _:Jeni ;
      ] .
    ] ;
  ] .

Now we have some descriptions of those cached documents:

<cache/GOR_DEC_2008_EN_NC.rdf> a prv:Document ;
  dct:format <http://www.iana.org/assignments/media-types/application/rdf+xml> ;
  rdfs:label "GOR_DEC_2008_EN_NC.rdf" .

<cache/region.xsl> a prv:Document ;
  dct:format <http://www.iana.org/assignments/media-types/application/xslt+xml> ;
  rdfs:label "gor.xsl" .

<cache/GOR_DEC_2008_EN_NC.csv> a prv:Document ;
  dct:format <http://www.iana.org/assignments/media-types/text/csv> ;
  rdfs:label "GOR_DEC_2008_EN_NC.csv" ;
  dct:isPartOf <cache/government-office-regions.zip> .

This last file — the CSV that contained the data — was part of a zip file. The zip file was retrieved via HTTP at 12:00 today through a GET request to the URI http://www.ons.gov.uk/about-statistics/geography/products/geog-products-area/names-codes/administrative/government-office-regions.zip, but I also make it available in the cache in case that original file either disappears or gets changed at a later date.

<cache/government-office-regions.zip>
  a prv:Document ;
  rdfs:label "government-office-regions.zip" ;
  dct:format <http://www.iana.org/assignments/media-types/application/zip> ;
  dct:hasPart <cache/GOR_DEC_2008_EN_NC.csv> ;
  prv:retrievedBy [ 
    a prvTypes:HTTPBasedDataAccess ;
    prv:performedAt "2009-10-24T12:00:21Z"^^xsd:dateTime ;
    prvTypes:exchangedHTTPMessage [
      a http:GetRequest ;
      http:requestURI "http://www.ons.gov.uk/about-statistics/geography/products/geog-products-area/names-codes/administrative/government-office-regions.zip"^^xsd:anyURI .
    ] ;
  ] .

The final bits and pieces provide extra information about the resources that have been referenced above, including the provenance of the file that is providing this provenance information!

_:Jeni a foaf:Person ;
  foaf:name "Jeni Tennison" ;
  foaf:homepage <http://www.jenitennison.com/> .

<http://www.jenitennison.com/log/> a void:Dataset ;
  dct:title "Jeni's Activity Log" ;
  foaf:homepage <http://www.jenitennison.com/log/> ;
  void:uriRegexPattern "http://www.jenitennison.com/log/(.+)" ;
  void:subset <> .

<> a void:Dataset ;
  dct:title "Jeni's log for 19th October 2009" ;
  foaf:homepage <> ;
  void:exampleResource <log.ttl> ;
  void:uriRegexPattern "http://www.jenitennison.com/log/2009-10-24/(.+)" ;
  void:subset [
    prv:containedBy <log.ttl> ;
    void:dataDump <log.ttl> ;
    prv:createdBy [
      a prv:DataCreation ;
      prv:performedAt "2009-10-24T18:57:00"^^xsd:dateTime ;
      prv:performedBy _:Jeni 
    ] ;
  ] .

<log.ttl> a prv:Document ;
  dct:format <http://www.iana.org/assignments/media-types/text/turtle> .

<http://www.iana.org/assignments/media-types/application/xslt+xml>
  rdf:value "application/xslt+xml" ;
  rdfs:label "XSLT" .

<http://www.iana.org/assignments/media-types/application/rdf+xml>
  rdf:value "application/rdf+xml" ;
  rdfs:label "RDF/XML" .

<http://www.iana.org/assignments/media-types/text/turtle>
  rdf:value "text/turtle" ;
  rdfs:label "Turtle" .

<http://www.iana.org/assignments/media-types/application/zip>
  rdf:value "application/zip" ;
  rdfs:label "Zip" .

<http://www.iana.org/assignments/media-types/text/csv>
  rdf:value "text/csv" ;
  rdfs:label "CSV" .

This pattern for providing provenance information isn’t a complete answer because it doesn’t address how you might assess the provenance of a particular statement. If I went to http://statistics.data.gov.uk/id/region/H the only way I could establish that the rdfs:label (say) for the region was generated through the process described above would be to match the URI to the void:uriRegexPattern above, get hold of the original RDF from the cache and work out whether it contains the rdfs:label statement that I’m interested in.

I have a hunch that this would be more viable with named graphs: if statements with different provenance were actually placed in different graphs, then it would be possible with a SPARQL query to identify the graph(s) in which a statement was made, and their provenance. I think that the _:GORRDF blank node in the above could be a trix:Graph, for example.

Regardless, the Provenance Vocabulary that I’ve used above seems to do the job reasonably well. I’m intending to try this approach out on a few datasets and see how it stands up to real-world complexities. Comments and suggestions appreciated.

1. We’ll use SCOVO as our main vocabulary.

2. Dimensions (the things a statistic are about) should be instances of specialised classes such as ‘Hospital’ or ‘School’; these will often be SKOS concepts. We will try to reuse these as much as possible across datasets (see below).

3. We will create subproperties of scv:dimension that have appropriate names and different subclasses of scv:Dimensions as ranges. We will try to reuse these as much as possible across datasets (see below).

4. The scv:Items we use (representing individual statistics) should not be blank nodes (because giving them URIs allows us to attach other information to them); they will each have a scv:dataset property that points to the scv:Dataset they belong to (which will probably also be a void:Dataset).

5. Every scv:Item will also be the object of at least one triple that involves one of its dimensions; this will usually be the real-world thing that the statistic is associated with (eg the school or hospital).

6. Most statistics are provided for a particular time period; for these, we will define relationships from OWL-Time to placetime.com resources, but will also use appropriately datatyped literals where possible to make querying easier.

Here’s an example of what this looks like:

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix scv: <http://purl.org/NET/scovo#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix dct: <http://purl.org/dc/terms/> .
@prefix void: <http://rdfs.org/ns/void#> .
@prefix time: <http://www.w3.org/2006/time#> .
@prefix sdmx: <http://proxy.data.gov.uk/sdmx.org/def/sdmx/> .
@prefix pop: <http://statistics.data.gov.uk/def/population/> .
@prefix year: <http://statistics.data.gov.uk/def/census-year/> .

# The statistics themselves

<http://statistics.data.gov.uk/id/local-authority-district/00HE>
  rdfs:label "Cornwall" ;
  pop:totalPopulation <http://statistics.data.gov.uk/id/local-authority-district/00HE/population/total/year/2001> ;
  pop:ruralPopulation <http://statistics.data.gov.uk/id/local-authority-district/00HE/population/rural/year/2001> ;
  ... .

<http://statistics.data.gov.uk/id/local-authority-district/00HE/population/total/year/2001>
  a scv:Item ;
  rdf:value "499399"^^xsd:integer ;
  scv:dataset <http://statistics.data.gov.uk/doc/local-authority-district/*/population> ;
  sdmx:refArea <http://statistics.data.gov.uk/id/local-authority-district/00HE> ;
  pop:populationType pop:total ;
  sdmx:timePeriod <http://statistics.data.gov.uk/def/census-year/2001> .

<http://statistics.data.gov.uk/id/local-authority-district/00HE/population/rural/year/2001>
  a scv:Item ;
  rdf:value "127904"^^xsd:integer ;
  scv:dataset <http://statistics.data.gov.uk/doc/local-authority-district/*/population> ;
  sdmx:refArea <http://statistics.data.gov.uk/id/local-authority-district/00HE> ;
  pop:populationType pop:rural ;
  sdmx:timePeriod <http://statistics.data.gov.uk/def/census-year/2001> .

...

# Datasets

<http://statistics.data.gov.uk/doc/local-authority-district/*/population/*/year/2001>
  a scv:Dataset ;
  a void:Dataset ;
  dct:title "Populations of Local Authority Districts" ;
  ... .

# Common definitions for the dataset

pop:totalPopulation a rdf:Property ;
  rdfs:label "total population" ;
  rdfs:range scv:Item .
pop:ruralPopulation a rdf:Property ;
  rdfs:label "rural population" ;
  rdfs:range scv:Item .
...

pop:populationType rdfs:subPropertyOf scv:dimension ;
  rdfs:label "population type" ;
  rdfs:domain scv:Item ;
  rdfs:range pop:Population .

pop:Population a rdfs:Class ;
  rdfs:subClassOf skos:Concept ;
  rdfs:subClassOf scv:Dimension ;
  rdfs:label "population type" .

pop:populationScheme a skos:ConceptScheme ;
  skos:prefLabel "Population Types" ;
  pop:hasTopConcept pop:total .

pop:total a pop:Population ;
  skos:prefLabel "total population" ;
  skos:topConceptOf pop:populationScheme ;
  skos:narrower pop:rural ;
  ... .

pop:rural a pop:Population ;
  skos:prefLabel "rural population" ;
  skos:inScheme pop:populationScheme ;
  skos:broader pop:total ;
  ... .

year:Year a rdfs:Class ;
  rdfs:subClassOf time:Interval ;
  rdfs:subClassOf scv:Dimension .

<http://statistics.data.gov.uk/def/census-year/2001>
  rdfs:label "mid-2001" ;
  time:intervalDuring <http://www.placetime.com/interval/gregorian/2001-01-01T00:00:00Z/P1Y> .

<http://www.placetime.com/interval/gregorian/2001-01-01T00:00:00Z/P1Y>
  rdfs:label "2001" ;
  rdf:value "2001"^^xsd:gYear .

One source of sub-properties of scv:dimension (and subtypes of scv:Dimension) is SDMX (Statistical Data and Metadata eXchange). This provides standard ways of indicating things like the area and time that a statistic applies to. I’ve made an initial mapping into some RDFS properties and SKOS schemes as an indication of the kind of thing that would work here, but expect it to change.

We’re currently working on providing identifiers for the areas that statistics are likely to be about (such as local authority districts, MSOAs or wards). They are of the form:

http://statistics.data.gov.uk/id/{area-type}/{ONS-area-code}

and they tie into the newly released OS data. I hope we’ll have them available as Linked Data soon.

One issue that hasn’t been resolved is how to handle the huge amount of repetition that is inherent in this method of representing statistical data. For example, in the data above, all the scv:DataItems in the scv:Dataset http://statistics.data.gov.uk/doc/local-authority-district/*/population/*/year/2001 are from 2001. Rather than indicating the year of each individual scv:DataItem, it would be nice if we could have a property on the dataset that indicated that all the items in that dataset had the same value for a particular dimension. If this were called scv:itemDimension, for example, then we could do:

<http://statistics.data.gov.uk/doc/local-authority-district/*/population/*/year/2001>
  a scv:Dataset ;
  a void:Dataset ;
  dct:title "Populations of Local Authority Districts" ;
  sdmx:itemTimePeriod <http://statistics.data.gov.uk/def/census-year/2001> ;
  ... .

sdmx:itemTimePeriod rdfs:subPropertyOf scv:itemDimension ;
  rdfs:label "time period of items in the dataset" ;
  rdfs:domain scv:Dataset .

and the individual scv:Items would not have to have any sdmx:timePeriod properties explicitly. Perhaps this is something that the people beind SCOVO might consider, or we might create the property ourselves.

As far as I know, this pattern for representing statistics has yet to be used “in anger”, but I hope that we’ll have some illustrations soon which will help us assess whether it’s viable. Any comments and suggestions would, of course, be very welcome!