Linked Data: Evolving the Web into a Global Data Space

Tom Heath

Christian Bizer , Talis, Freie Universität Berlin



This book gives an overview of the principles of Linked Data as well as the Web of Data that has emerged through the application of these principles. The book discusses patterns for publishing Linked Data, describes deployed Linked Data applications and examines their architecture.

Abstract

The World Wide Web has enabled the creation of a global information space comprising linked documents. As the Web becomes ever more enmeshed with our daily lives, there is a growing desire for direct access to raw data not currently available on the Web or bound up in hypertext documents. Linked Data provides a publishing paradigm in which not only documents, but also data, can be a first class citizen of the Web, thereby enabling the extension of the Web with a global data space based on open standards - the Web of Data. In this Synthesis lecture we provide readers with a detailed technical introduction to Linked Data. We begin by outlining the basic principles of Linked Data, including coverage of relevant aspects of Web architecture. The remainder of the text is based around two main themes - the publication and consumption of Linked Data. Drawing on a practical Linked Data scenario, we provide guidance and best practices on: architectural approaches to publishing Linked Data; choosing URIs and vocabularies to identify and describe resources; deciding what data to return in a description of a resource on the Web; methods and frameworks for automated linking of data sets; and testing and debugging approaches for Linked Data deployments. We give an overview of existing Linked Data applications and then examine the architectures that are used to consume Linked Data from the Web, alongside existing tools and frameworks that enable these. Readers can expect to gain a rich technical understanding of Linked Data fundamentals, as the basis for application development, research or further study.

Keywords: web technology, databases, linked data, web of data, semantic web, world wide web, dataspaces, data integration, data management, web engineering, resource description framework

Table of Contents

This book provides a conceptual and technical introduction to the field of Linked Data. It is intended for anyone who cares about data – using it, managing it, sharing it, interacting with it – and is passionate about the Web. We think this will include data geeks, managers and owners of data sets, system implementors and Web developers. We hope that students and teachers of information management and computer science will find the book a suitable reference point for courses that explore topics in Web development and data management. Established practitioners of Linked Data will find in this book a distillation of much of their knowledge and experience, and a reference work that can bring this to all those who follow in their footsteps.

Chapter 2 introduces the basic principles and terminology of Linked Data. Chapter 3 provides a 30,000 ft view of the Web of Data that has arisen from the publication of large volumes of Linked Data on the Web. Chapter 4 discusses the primary design considerations that must be taken into account when preparing to publish Linked Data, covering topics such as choosing and using URIs, describing things using RDF, data licensing and waivers, and linking data to external data sets. Chapter 5 introduces a number of recipes that highlight the wide variety of approaches that can be adopted to publish Linked Data, while Chapter 6 describes deployed Linked Data applications and examines their architecture. The book concludes in Chapter 7 with a summary and discussion of the outlook for Linked Data.

We would like to thank the series editors Jim Hendler and Frank van Harmelen for giving us the opportunity and the impetus to write this book. Summarizing the state of the art in Linked Data was a job that needed doing – we are glad they asked us. It has been a long process, throughout which Mike Morgan of Morgan & Claypool has shown the patience of a saint, for which we are extremely grateful. Richard Cyganiak wrote a significant portion of the 2007 tutorial “How to Publish Linked Data on the Web” which inspired a number of sections of this book – thank you Richard. Mike Bergman, Dan Brickley, Fabio Ciravegna, Ian Dickinson, John Goodwin, Harry Halpin, Frank van Harmelen, Olaf Hartig, Andreas Harth, Michael Hausenblas, Jim Hendler, Bernadette Hyland, Toby Inkster, Anja Jentzsch, Libby Miller, Yves Raimond, Matthew Rowe, Daniel Schwabe, Denny Vrandecic, and David Wood reviewed drafts of the book and provided valuable feedback when we needed fresh pairs of eyes – they deserve our gratitude. We also thank the European Commission for supporting the creation of this book by funding the LATC – LOD Around The Clock project (Ref. No. 256975). Many thanks are due to Ulrich Zellbeck for creating the HTML version of this book using HEVEA. Lastly, we would like to thank the developers of LaTeX and Subversion, without which this exercise in remote, collaborative authoring would not have been possible.



Tom Heath and Christian Bizer

February 2011

1.1 The Data Deluge

We are surrounded by data – data about the performance of our locals schools, the fuel efficiency of our cars, a multitude of products from different vendors, or the way our taxes are spent. By helping us make better decisions, this data is playing an increasingly central role in our lives and driving the emergence of a data economy [47]. Increasing numbers of individuals and organizations are contributing to this deluge by choosing to share their data with others, including Web-native companies such as Amazon and Yahoo!, newspapers such as The Guardian and The New York Times, public bodies such as the UK and US governments, and research initiatives within various scientific disciplines.

Third parties, in turn, are consuming this data to build new businesses, streamline online commerce, accelerate scientific progress, and enhance the democratic process. For example:

The online retailer Amazon makes their product data available to third parties via a Web API 1 . In doing so they have created a highly successful ecosystem of affiliates 2 who build micro-businesses, based on driving transactions to Amazon sites.

. In doing so they have created a highly successful ecosystem of affiliates who build micro-businesses, based on driving transactions to Amazon sites. Search engines such as Google and Yahoo! consume structured data from the Web sites of various online stores, and use this to enhance the search listings of items from these stores. Users and online retailers benefit through enhanced user experience and higher transaction rates, while the search engines need expend fewer resources on extracting structured data from plain HTML pages.

Innovation in disciplines such as Life Sciences requires the world-wide exchange of research data between scientists, as demonstrated by the progress resulting from cooperative initiatives such as the Human Genome Project.

The availability of data about the political process, such as members of parliament, voting records, and transcripts of debates, has enabled the organisation mySociety3 to create services such as TheyWorkForYou4, through which voters can readily assess the performance of elected representatives.

The strength and diversity of the ecosystems that have evolved in these cases demonstrates a previously unrecognised, and certainly unfulfilled, demand for access to data, and that those organizations and individuals who choose to share data stand to benefit from the emergence of these ecosystems. This raises three key questions:

How best to provide access to data so it can be most easily reused?

How to enable the discovery of relevant data within the multitude of available data sets?

How to enable applications to integrate data from large numbers of formerly unknown data sources?

Just as the World Wide Web has revolutionized the way we connect and consume documents, so can it revolutionize the way we discover, access, integrate and use data. The Web is the ideal medium to enable these processes, due to its ubiquity, its distributed and scalable nature, and its mature, well-understood technology stack.

The topic of this book is on how a set of principles and technologies, known as Linked Data, harnesses the ethos and infrastructure of the Web to enable data sharing and reuse on a massive scale.

1.2 The Rationale for Linked Data

In order to understand the concept and value of Linked Data, it is important to consider contemporary mechanisms for sharing and reusing data on the Web.

1.2.1 Structure Enables Sophisticated Processing

A key factor in the re-usability of data is the extent to which it is well structured. The more regular and well-defined the structure of the data the more easily people can create tools to reliably process it for reuse.

While most Web sites have some degree of structure, the language in which they are created, HTML, is oriented towards structuring textual documents rather than data. As data is intermingled into the surrounding text, it is hard for software applications to extract snippets of structured data from HTML pages.

To address this issue, a variety of microformats5 have been invented. Microformats can be used to published structured data describing specific types of entities, such as people and organizations, events, reviews and ratings, through embedding of data in HTML pages. As microformats tightly specify how to embed data, applications can unambiguously extract the data from the pages. Weak points of microformats are that they are restricted to representing data about a small set of different types of entities; they only provide a small set of attributes that may used to describe these entities; and that it is often not possible to express relationships between entities, such as, for example, that a person is the speaker of an event, rather than being just an attendee or the organizer of the event. Therefore, microformats are not suitable for sharing arbitrary data on the Web.

A more generic approach to making structured data available on the Web are Web APIs. Web APIs provide simple query access to structured data over the HTTP protocol. High profile examples of these APIs include the Amazon Product Advertising API6 and the Flickr API7. The site ProgrammableWeb8 maintains a directory containing several thousand Web APIs.

The advent of Web APIs has led to an explosion in small, specialized applications (or mashups) that combine data from several sources, each of which is accessed through an API specific to the data provider. While the benefits of programmatic access to structured data are indisputable, the existence of a specialized API for each data set creates a landscape where significant effort is required to integrate each novel data set into an application. Every programmer must understand the methods available to retrieve data from each API, and write custom code for accessing data from each data source.

1.2.2 Hyperlinks Connect Distributed Data

It is common for Web APIs to provide results in structured data formats such as XML and JSON9, which have extensive support in a wide range of programming languages. However, from a Web perspective, they have some limitations, which are best explained by comparison with HTML. The HTML specification defines the anchor element, a , one of the valid attributes of which is the href . When used together, the anchor tag and href attribute indicate an outgoing link from the current document. Web user agents, such as browsers and search engine crawlers, are programmed to recognize the significance of this combination, and either render a clickable link that a human user can follow, or to traverse the link directly in order to retrieve and process the referenced document. It is this connectivity between documents, supported by a standard syntax for indicating links, that has enabled the Web of documents. By contrast, the data returned from the majority of Web APIs does not have the equivalent of the HTML anchor tag and href attribute, to indicate links that should be followed to find related data.

Furthermore, many Web APIs refer to items of interest using identifiers that have only local scope – e.g., a product identifier 123456 that is meaningless when taken out of the context of that specific API. In such cases, there is no standard mechanism to refer to items described by one API in data returned by another.

Consequently, data returned from Web APIs typically exists as isolated fragments, lacking reliable onward links signposting the way to related data. Therefore, while Web APIs make data accessible on the Web, they do not place it truly in the Web, making it linkable and therefore discoverable.

To return to the comparison with HTML, the analogous situation would be a search engine that required a priori knowledge of all Web documents before it could assemble its index. To provide this a priori knowledge, every Web publisher would need to register each Web page with each search engine. The ability for anyone to add new documents to the Web at will, and for these documents to be automatically discovered by search engines and humans with browsers, have historically been key drivers of the Web’s explosive growth. The same principles of linking, and therefore ease of discovery, can be applied to data on the Web, and Linked Data provides a technical solution to realize such linkage.

1.3 From Data Islands to a Global Data Space

Linking data distributed across the Web requires a standard mechanism for specifying the existence and meaning of connections between items described in this data.

This mechanism is provided by the Resource Description Framework (RDF), which is examined in detail in Chapter 2. The key things to note at this stage are that RDF provides a flexible way to describe things in the world – such as people, locations, or abstract concepts – and how they relate to other things. These statements of relationships between things are, in essence, links connecting things in the world. Therefore, if we wish to say that a book described in data from one API is for sale at a (physical) bookshop described in data from a second API, and that bookshop is located in a city described by data from a third, RDF enables us to do this, and publish this information on the Web in a form that others can discover and reuse.

To conclude the comparison with HTML documents and conventional Web APIs, the key features of RDF worth noting in this context are the following:

RDF links things, not just documents : therefore, in the book selling example above, RDF links would not simply connect the data fragments from each API, but assert connections between the entities described in the data fragments – in this case the book, the bookshop and the city.

: therefore, in the book selling example above, RDF links would not simply connect the data fragments from each API, but assert connections between the entities described in the data fragments – in this case the book, the bookshop and the city. RDF links are typed: HTML links typically indicate that two documents are related in some way, but mostly leave the user to infer the nature of the relationship. In contrast, RDF enables the data publisher to state explicitly the nature of the connection. Therefore, in practice, the links in the book selling example above would read something like: mybook forSaleIn thatbookshop, thatbookshop locatedIn mycity.

While these sorts of connections between things in the world may be implicit in XML or JSON data returned from Web APIs, RDF enables Web publishers to make these links explicit, and in such a way that RDF-aware applications can follow them to discover more data. Therefore, a Web in which data is both published and linked using RDF is a Web where data is significantly more discoverable, and therefore more usable.

Just as hyperlinks in the classic Web connect documents into a single global information space, Linked Data enables links to be set between items in different data sources and therefore connect these sources into a single global data space. The use of Web standards and a common data model make it possible to implement generic applications that operate over the complete data space. This is the essence of Linked Data.

Increasing numbers of data providers and application developers have adopted Linked Data. In doing so they have created this global, interconnected data space - the Web of Data. Echoing the diversity of the classic document Web, the Web of Data spans numerous topical domains, such as people, companies, films, music, locations, books and other publications, online communities, as well as an increasing volume of scientific and government data.

This Web of Data [30], also referred to as Semantic Web [21], presents a revolutionary opportunity for deriving insight and value from data. By enabling seamless connections between data sets, we can transform the way drugs are discovered, create rich pathways through diverse learning resources, spot previously unseen factors in road traffic accidents, and scrutinise more effectively the operation of our democratic systems.

The focus of this book is data sharing in the context of the public Web. However, the principles and techniques described can be equally well applied to data that exists behind a personal or corporate firewall, or that straddles the public and the private. For example, many aspects of Linked Data have been implemented in desktop computing environments through the Semantic Desktop initiative10. Similarly, these principles can be employed entirely behind the corporate firewall, to help ease the pain of data integration in enterprise environments [114]. The Linking Open Drug Data [68] initiative represents a hybrid scenario, where Linked Data is enabling commercial organizations to connect and integrate data they are willing to share with each other for the purposes of collaboration.

1.4 Introducing Big Lynx Productions

Throughout this book we will illustrate the principles and technical aspects of Linked Data with examples from a scenario involving Big Lynx Productions. Big Lynx is a (fictional) independent television production company specialising in wildlife documentaries, primarily produced under contract for major television networks in the UK. The company employs around 30 permanent staff, such as Managing Director Dave Smith, Lead Cameraman Matt Briggs, and Webmaster Nelly Jones, plus a large team of freelancers that evolves according to the needs of current contracts.

Big Lynx maintains its own Web site at http://biglynx.co.uk/ that contains:

information about the company’s goals and structure

profiles of the permanent staff and of freelancers

listings of vacancies for freelancers to work on specific contracts

listings of productions that have been broadcast by the commissioning network

a blog where staff post news items of interest to the television networks and/or freelancers

Information that changes rarely (such as the company overview) is published on the site as static HTML documents. Frequently changing information (such as listing of productions) is stored in a relational database and published to the Web site as HTML by a series of PHP scripts developed for the company. The company blog is based on a blogging platform developed in-house and forms part of the main Big Lynx site.

In the remainder of this book we will explore how Linked Data can be integrated into the workflows and technical architectures of Big Lynx, thereby maximising the discoverability of the Big Lynx data and making it easy for search engines as well as specialized Web sites, such as film and TV sites, freelancer directories or online job markets, to pick up and integrate Big Lynx data with data from other companies.

The term Linked Data refers to a set of best practices for publishing and interlinking structured data on the Web. These best practices were introduced by Tim Berners-Lee in his Web architecture note Linked Data [16] and have become known as the Linked Data principles. These principles are the following:

Use URIs as names for things. Use HTTP URIs, so that people can look up those names. When someone looks up a URI, provide useful information, using the standards (RDF, SPARQL). Include links to other URIs, so that they can discover more things.

The basic idea of Linked Data is to apply the general architecture of the World Wide Web [67] to the task of sharing structured data on global scale. In order to understand these Linked Data principles, it is important to understand the architecture of the classic document Web.

The document Web is built on a small set of simple standards: Uniform Resource Identifiers (URIs) as globally unique identification mechanism [20], the Hypertext Transfer Protocol (HTTP) as universal access mechanism [50], and the Hypertext Markup Language (HTML) as a widely used content format [97]. In addition, the Web is built on the idea of setting hyperlinks between Web documents that may reside on different Web servers.

The development and use of standards enables the Web to transcend different technical architectures. Hyperlinks enable users to navigate between different servers. They also enable search engines to crawl the Web and to provide sophisticated search capabilities on top of crawled content. Hyperlinks are therefore crucial in connecting content from different servers into a single global information space. By combining simplicity with decentralization and openness, the Web seems to have hit an architectural sweet spot, as demonstrated by its rapid growth over the past 20 years.

Linked Data builds directly on Web architecture and applies this architecture to the task of sharing data on global scale.

2.1 The Principles in a Nutshell

The first Linked Data principle advocates using URI references to identify, not just Web documents and digital content, but also real world objects and abstract concepts. These may include tangible things such as people, places and cars, or those that are more abstract, such as the relationship type of knowing somebody, the set of all green cars in the world, or the color green itself. This principle can be seen as extending the scope of the Web from online resources to encompass any object or concept in the world.

The HTTP protocol is the Web’s universal access mechanism. In the classic Web, HTTP URIs are used to combine globally unique identification with a simple, well-understood retrieval mechanism. Thus, the second Linked Data principle advocates the use of HTTP URIs to identify objects and abstract concepts, enabling these URIs to be dereferenced (i.e., looked up) over the HTTP protocol into a description of the identified object or concept.

In order to enable a wide range of different applications to process Web content, it is important to agree on standardized content formats. The agreement on HTML as a dominant document format was an important factor that made the Web scale. The third Linked Data principle therefore advocates use of a single data model for publishing structured data on the Web – the Resource Description Framework (RDF), a simple graph-based data model that has been designed for use in the context of the Web [70]. The RDF data model is explained in more detail later in this chapter.

The fourth Linked Data principle advocates the use of hyperlinks to connect not only Web documents, but any type of thing. For example, a hyperlink may be set between a person and a place, or between a place and a company. In contrast to the classic Web where hyperlinks are largely untyped, hyperlinks that connect things in a Linked Data context have types which describe the relationship between the things. For example, a hyperlink of the type friend of may be set between two people, or a hyperlink of the type based near may be set between a person and a place. Hyperlinks in the Linked Data context are called RDF links in order to distinguish them from hyperlinks between classic Web documents.

Across the Web, many different servers are responsible for answering requests attempting to dereference HTTP URIs in many different namespaces, and (in a Linked Data context) returning RDF descriptions of the resources identified by these URIs. Therefore, in a Linked Data context, if an RDF link connects URIs in different namespaces, it ultimately connects resources in different data sets.

Just as hyperlinks in the classic Web connect documents into a single global information space, Linked Data uses hyperlinks to connect disparate data into a single global data space. These links, in turn, enable applications to navigate the data space. For example, a Linked Data application that has looked up a URI and retrieved RDF data describing a person may follow links from that data to data on different Web servers, describing, for instance, the place where the person lives or the company for which the person works.

As the resulting Web of Data is based on standards and a common data model, it becomes possible to implement generic applications that operate over the complete data space. Examples of such applications include Linked Data browsers which enable the user to view data from one data source and then follow RDF links within the data to other data sources. Other examples are Linked Data Search engines that crawl the Web of Data and provide sophisticated query capabilities on top of the complete data space. Section 6.1 will give an overview of deployed Linked Data applications.

In summary, the Linked Data principles lay the foundations for extending the Web with a global data space based on the same architectural principles as the classic document Web. The following sections explain the technical realization of the Linked Data principles in more detail.

2.2 Naming Things with URIs

To publish data on the Web, the items in a domain of interest must first be identified. These are the things whose properties and relationships will be described in the data, and may include Web documents as well as real-world entities and abstract concepts. As Linked Data builds directly on Web architecture [67], the Web architecture term resource is used to refer to these things of interest, which are, in turn, identified by HTTP URIs.

Figure 2.111

depicts the use of HTTP URIs to identify real-world entities and their relationships. The picture shows a Big Lynx film team at work. Within the picture, Big Lynx Lead Cameraman Matt Briggs as well as his two assistants, Linda Meyer and Scott Miller, are identified by HTTP URIs from the Big Lynx namespace. The relationship, that they know each other, is represented by connecting lines having the relationship type http://xmlns.com/foaf/0.1/knows .

As discussed above, Linked Data uses only HTTP URIs, avoiding other URI schemes such as URNs [83] and DOIs [92]. HTTP URIs make good names for two reasons:

They provide a simple way to create globally unique names in a decentralized fashion, as every owner of a domain name, or delegate of the domain name owner, may create new URI references. They serve not just as a name but also as a means of accessing information describing the identified entity.

If thinking about HTTP URIs as names for things rather than as addresses for Web documents feels strange to you, then references [113] and [106] are highly recommended reading and warrant re-visiting on a regular basis.

2.3 Making URIs Defererenceable

Any HTTP URI should be dereferenceable, meaning that HTTP clients can look up the URI using the HTTP protocol and retrieve a description of the resource that is identified by the URI. This applies to URIs that are used to identify classic HTML documents, as well as URIs that are used in the Linked Data context to identify real-world objects and abstract concepts.

Descriptions of resources are embodied in the form of Web documents. Descriptions that are intended to be read by humans are often represented as HTML. Descriptions that are intended for consumption by machines are represented as RDF data.

Where URIs identify real-world objects, it is essential to not confuse the objects themselves with the Web documents that describe them. It is, therefore, common practice to use different URIs to identify the real-world object and the document that describes it, in order to be unambiguous. This practice allows separate statements to be made about an object and about a document that describes that object. For example, the creation date of a person may be rather different to the creation date of a document that describes this person. Being able to distinguish the two through use of different URIs is critical to the coherence of the Web of Data.

The Web is intended to be an information space that may be used by humans as well as by machines. Both should be able to retrieve representations of resources in a form that meets their needs, such as HTML for humans and RDF for machines. This can be achieved using an HTTP mechanism called content negotiation [50]. The basic idea of content negotiation is that HTTP clients send HTTP headers with each request to indicate what kinds of documents they prefer. Servers can inspect these headers and select an appropriate response. If the headers indicate that the client prefers HTML, then the server will respond by sending an HTML document. If the client prefers RDF, then the server will send the client an RDF document.

There are two different strategies to make URIs that identify real-world objects dereferenceable. Both strategies ensure that objects and the documents that describe them are not confused, and that humans as well as machines can retrieve appropriate representations. The strategies are called 303 URIs and hash URIs. The W3C Interest Group Note Cool URIs for the Semantic Web [98] describes and motivates both strategies in detail. The following sections summarize both strategies and illustrate each with an example HTTP session.

2.3.1 303 URIs

Real-world objects, like houses or people, can not be transmitted over the wire using the HTTP protocol. Thus, it is also not possible to directly dereference URIs that identify real-world objects. Therefore, in the 303 URIs strategy, instead of sending the object itself over the network, the server responds to the client with the HTTP response code 303 See Other and the URI of a Web document which describes the real-world object. This is called a 303 redirect. In a second step, the client dereferences this new URI and gets a Web document describing the real-world object.

Dereferencing a HTTP URI that identifies a real-world object or abstract concept thus involves a four step procedure:

The client performs a HTTP GET request on a URI identifying a real-world object or abstract concept. If the client is a Linked Data application and would prefer an RDF/XML representation of the resource, it sends an Accept: application/rdf+xml header along with the request. HTML browsers would send an Accept: text/html header instead. The server recognizes that the URI identifies a real-world object or abstract concept. As the server can not return a representation of this resource, it answers using the HTTP 303 See Other response code and sends the client the URI of a Web document that describes the real-world object or abstract concept in the requested format. The client now performs an HTTP GET request on this URI returned by the server. The server answers with a HTTP response code 200 OK and sends the client the requested document, describing the original resource in the requested format.

This process can be illustrated with a concrete example. Imagine Big Lynx wants to serve data about their Managing Director Dave Smith on the Web. This data should be understandable for humans as well as for machines. Big Lynx therefore defines a URI reference that identifies the person Dave Smith (real-world object) and publishes two documents on its Web server: an RDF document containing the data about Dave Smith and an HTML document containing a human-readable representation of the same data. Big Lynx uses the following three URIs to refer to Dave and the two documents:

http://biglynx.co.uk/people/dave-smith (URI identifying the person Dave Smith)

(URI identifying the person Dave Smith) http://biglynx.co.uk/people/dave-smith.rdf (URI identifying the RDF/XML document describing Dave Smith)

(URI identifying the RDF/XML document describing Dave Smith) http://biglynx.co.uk/people/dave-smith.html (URI identifying the HTML document describing Dave Smith)

To obtain the RDF data describing Dave Smith, a Linked Data client would connect to the http://biglynx.co.uk/ server and issue the following HTTP GET request:

1 GET /people/dave-smith HTTP/1.1

2 Host: biglynx.co.uk

3 Accept: text/html;q=0.5, application/rdf+xml

The client sends an Accept: header to indicate that it would take either HTML or RDF, but would prefer RDF. This preference is indicated by the quality value q=0.5 for HTML. The server would answer:

1 HTTP/1.1 303 See Other

2 Location: http://biglynx.co.uk/people/dave-smith.rdf

3 Vary: Accept

This is a 303 redirect, which tells the client that a Web document containing a description of the requested resource, in the requested format, can be found at the URI given in the Location: response header. Note that if the Accept: header had indicated a preference for HTML, the client would have been redirected to a different URI. This is indicated by the Vary: header, which is required so that caches work correctly. Next, the client will try to dereference the URI given in the response from the server.

1 GET /people/dave-smith.rdf HTTP/1.1

2 Host: biglynx.co.uk

3 Accept: text/html;q=0.5, application/rdf+xml

The Big Lynx Web server would answer this request by sending the client the RDF/XML document containing data about Dave Smith:

1 HTTP/1.1 200 OK

2 Content-Type: application/rdf+xml

3

4

5 <?xml version="1.0" encoding="UTF-8"?>

6 <rdf:RDF

7 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

8 xmlns:foaf="http://xmlns.com/foaf/0.1/">

9

10 <rdf:Description rdf:about="http://biglynx.co.uk/people/dave-smith">

11 <rdf:type rdf:resource="http://xmlns.com/foaf/0.1/Person"/>

12 <foaf:name>Dave Smith</foaf:name>

13 ...

The 200 status code tells the client that the response contains a representation of the requested resource. The Content-Type: header indicates that the representation is in RDF/XML format. The rest of the message contains the representation itself, in this case an RDF/XML description of Dave Smith. Only the beginning of this description is shown. The RDF data model, in general, will be described in 2.4.1, while the RDF/XML syntax itself will be described in Section 2.4.2.

2.3.2 Hash URIs

A widespread criticism of the 303 URI strategy is that it requires two HTTP requests to retrieve a single description of a real-world object. One option for avoiding these two requests is provided by the hash URI strategy.

The hash URI strategy builds on the characteristic that URIs may contain a special part that is separated from the base part of the URI by a hash symbol (#). This special part is called the fragment identifier.

When a client wants to retrieve a hash URI, the HTTP protocol requires the fragment part to be stripped off before requesting the URI from the server. This means a URI that includes a hash cannot be retrieved directly and therefore does not necessarily identify a Web document. This enables such URIs to be used to identify real-world objects and abstract concepts, without creating ambiguity [98].

Big Lynx has defined various vocabulary terms in order to describe the company in data published on the Web. They may decide to use the hash URI strategy to serve an RDF/XML file containing the definitions of all these vocabulary terms. Big Lynx therefore assigns the URI

http://biglynx.co.uk/vocab/sme/

to the file (which contains a vocabulary of Small and Medium-sized Enterprises) and appends fragment identifiers to the file’s URI in order to identify the different vocabulary terms that are defined in the document. In this fashion, URIs such as the following are created for the vocabulary terms:

http://biglynx.co.uk/vocab/sme#SmallMediumEnterprise

http://biglynx.co.uk/vocab/sme#Team

To dereference any of these URIs, the HTTP communication between a client application and the server would look as follows:

First, the client truncates the URI, removing the fragment identifier (e.g., #Team ). Then, it connects to the server at biglynx.co.uk and issues the following HTTP GET request:

1 GET /vocab/sme HTTP/1.1

2 Host: biglynx.co.uk

3 Accept: application/rdf+xml

The server answers by sending the requested RDF/XML document, an abbreviated version of which is shown below:

1 HTTP/1.1 200 OK

2 Content-Type: application/rdf+xml;charset=utf-8

3

4

5 <?xml version="1.0"?>

6 <rdf:RDF

7 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

8 xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#">

9

10 <rdf:Description rdf:about="http://biglynx.co.uk/vocab/sme#SmallMediumEnterprise">

11 <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class" />

12 </rdf:Description>

13 <rdf:Description rdf:about="http://biglynx.co.uk/vocab/sme#Team">

14 <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class" />

15 </rdf:Description>

16 ...

This demonstrates that the returned document contains not only a description of the vocabulary term http://biglynx.co.uk/vocab/sme#Team but also of the term http://biglynx.co.uk/vocab/sme#SmallMediumEnterprise . The Linked Data-aware client will now inspect the response and find triples that tell it more about the http://biglynx.co.uk/vocab/sme#Team resource. If it is not interested in the triples describing the second resource, it can discard them before continuing to process the retrieved data.

2.3.3 Hash versus 303

So which strategy should be used? Both approaches have their advantages and disadvantages. Section 4.4. of the W3C Interest Group Note Cool URIs for the Semantic Web compares both approaches [98]: hash URIs have the advantage of reducing the number of necessary HTTP round-trips, which, in turn, reduces access latency. The downside of the hash URI approach is that the descriptions of all resources that share the same non-fragment URI part are always returned to the client together, irrespective of whether the client is interested in only one URI or all. If these descriptions consist of a large number of triples, the hash URI approach can lead to large amounts of data being unnecessarily transmitted to the client. 303 URIs, on the other hand, are very flexible because the redirection target can be configured separately for each resource. There could be one describing document for each resource, or one large document for all of them, or any combination in between. It is also possible to change the policy later on.

As a result of these factors, 303 URIs are often used to serve resource descriptions that are part of very large data sets, such as the description of an individual concept from DBpedia, an RDF-ized version of Wikipedia, consisting of 3.6 million concepts which are described by over 380 million triples [32] (see Section 3.2.1 for a fuller description of DBpedia).

Hash URIs are often used to identify terms within RDF vocabularies, as the definitions of RDF vocabularies are usually rather small, maybe a thousand RDF triples, and as it is also often convenient for client applications to retrieve the complete vocabulary definition at once, instead of having to look up every term separately. Hash URIs are also used when RDF is embedded into HTML pages using RDFa (described in Section 2.4.2.2). Within the RDFa context, hash URIs are defined using the RDFa about= attribute. Using them ensures that the URI of the HTML document is not mixed up with the URIs of the resources described within this document.

It is also possible to combine the advantages of the 303 URI and the hash URI approach. By using URIs that follow a http://domain/resource#this pattern, for instance, http://biglynx.co.uk/vocab/sme/Team#this , you can flexibly configure what data is returned as a description of a resource and still avoid the second HTTP request, as the #this part, which distinguished between the document and the described resource, is stripped off before the URI is dereferenced [98].

The examples in this book will use a mixture of Hash and 303 URIs to reflect the variety of usage in Linked Data published on the Web at large.

2.4 Providing Useful RDF Information

In order to enable a wide range of different applications to process Web content, it is important to agree on standardized content formats. When publishing Linked Data on the Web, data is represented using the Resource Description Framework (RDF) [70]. RDF provides a data model that is extremely simple on the one hand but strictly tailored towards Web architecture on the other hand. To be published on the Web, RDF data can be serialized in different formats. The two RDF serialization formats most commonly used to published Linked Data on the Web are RDF/XML [9] and RDFa [1].

This section gives an overview of the RDF data model, followed by a comparison of the different RDF serialization formats that are used in the Linked Data context.

2.4.1 The RDF Data Model

The RDF data model [70] represents information as node-and-arc-labeled directed graphs. The data model is designed for the integrated representation of information that originates from multiple sources, is heterogeneously structured, and is represented using different schemata [12]. RDF aims at being employed as a lingua franca, capable of moderating between other data models that are used on the Web. The RDF data model is described in detail as part of the W3C RDF Primer [76]. Below, we give a short overview of the data model.

In RDF, a description of a resource is represented as a number of triples. The three parts of each triple are called its subject, predicate, and object. A triple mirrors the basic structure of a simple sentence, such as this one:

Matt Briggs has nick name Matty Subject Predicate Object

The subject of a triple is the URI identifying the described resource. The object can either be a simple literal value, like a string, number, or date; or the URI of another resource that is somehow related to the subject. The predicate, in the middle, indicates what kind of relation exists between subject and object, e.g., this is the name or date of birth (in the case of a literal), or the employer or someone the person knows (in the case of another resource). The predicate is also identified by a URI. These predicate URIs come from vocabularies, collections of URIs that can be used to represent information about a certain domain. Please refer to Section 4.4.4 for more information about which vocabularies to use in a Linked Data context.

Two principal types of RDF triples can be distinguished, Literal Triples and RDF Links:

Literal Triples have an RDF literal such as a string, number, or date as the object. Literal triples are used to describe the properties of resources. For instance, literal triples are used to describe the name or date of birth of a person. Literals may be plain or typed: A plain literal is a string combined with an optional language tag. The language tag identifies a natural language, such as English or German. A typed literal is a string combined with a datatype URI. The datatype URI identifies the datatype of the literal. Datatype URIs for common datatypes such as integers, floating point numbers and dates are defined by the XML Schema datatypes specification [26]. The first triple in the code example below is a literal triple, stating that Big Lynx Lead Cameraman Matt Briggs has the nick name Matty. RDF Links describe the relationship between two resources. RDF links consist of three URI references. The URIs in the subject and the object position of the link identify the related resources. The URI in the predicate position defines the type of relationship between the resources. For instance, the second triple in the example below states that Matt Briggs knows Dave Smith. The third triple states that he leads something identified by the URI http://biglynx.co.uk/teams/production (in this case the Big Lynx Production Team). A useful distinction can be made between internal and external RDF links. Internal RDF links connect resources within a single Linked Data source. Thus, the subject and object URIs are in the same namespace. External RDF links connect resources that are served by different Linked Data sources. The subject and object URIs of external RDF links are in different namespaces. External RDF links are crucial for the Web of Data as they are the glue that connects data islands into a global, interconnected data space. The different roles that external RDF links have on the Web of Data will be discussed in detail in Section 2.5.

1 http://biglynx.co.uk/people/matt-briggs http://xmlns.com/foaf/0.1/nick "Matty"

2 http://biglynx.co.uk/people/matt-briggs http://xmlns.com/foaf/0.1/knows http://biglynx.co.uk/people/dave-smith

3 http://biglynx.co.uk/people/matt-briggs http://biglynx.co.uk/vocab/sme#leads http://biglynx.co.uk/teams/production

One way to think of a set of RDF triples is as an RDF graph. The URIs occurring as subject and object are the nodes in the graph, and each triple is a directed arc that connects the subject and the object. As Linked Data URIs are globally unique and can be dereferenced into sets of RDF triples, it is possible to imagine all Linked Data as one giant global graph, as proposed by Tim Berners-Lee in [17]. Linked Data applications operate on top of this giant global graph and retrieve parts of it by dereferencing URIs as required.

Benefits of using the RDF Data Model in the Linked Data Context

The main benefits of using the RDF data model in a Linked Data context are that:

By using HTTP URIs as globally unique identifiers for data items as well as for vocabulary terms, the RDF data model is inherently designed for being used at global scale and enables anybody to refer to anything. Clients can look up any URI in an RDF graph over the Web to retrieve additional information. Thus each RDF triple is part of the global Web of Data and each RDF triple can be used as a starting point to explore this data space. The data model enables you to set RDF links between data from different sources. Information from different sources can easily be combined by merging the two sets of triples into a single graph. RDF allows you to represent information that is expressed using different schemata in a single graph, meaning that you can mix terms for different vocabularies to represent data. This practice is explained in Section 4.4. Combined with schema languages such as RDF-Schema [37] and OWL [79], the data model allows the use of as much or as little structure as desired, meaning that tightly structured data as well as semi-structured data can be represented. A short introduction to RDF Schema and OWL is also given in Section 4.4.

RDF Features Best Avoided in the Linked Data Context

Besides the features mentioned above, the RDF Recommendation [70] also specifies a range of other features which have not achieved widespread adoption in the Linked Data community. In order to make it easier for clients to consume data, it is recommended to use only the subset of the RDF data model described above. In particular, the following features should be avoided in a Linked Data context.

RDF reification should be avoided, as reified statements are rather cumbersome to query with the SPARQL query language [95]. Instead of using reification to publish metadata about individual RDF statements, meta-information should instead be attached to the Web document containing the relevant triples, as explained in Section 4.3. RDF collections and RDF containers are also problematic if the data needs to be queried with SPARQL. Therefore, in cases where the relative ordering of items in a set is not significant, the use of multiple triples with the same predicate is recommended. The scope of blank nodes is limited to the document in which they appear, meaning it is not possible to create RDF links to them from external documents, reducing the potential for interlinking between different Linked Data sources. In addition, it becomes much more difficult to merge data from different sources when blank nodes are used, as there is no URI to serve as a common key. Therefore, all resources in a data set should be named using URI references.

2.4.2 RDF Serialization Formats

It is important to remember that RDF is not a data format, but a data model for describing resources in the form of subject, predicate, object triples. In order to publish an RDF graph on the Web, it must first be serialized using an RDF syntax. This simply means taking the triples that make up an RDF graph, and using a particular syntax to write these out to a file (either in advance for a static data set or on demand if the data set is more dynamic). Two RDF serialization formats - RDF/XML and RDFa - have been standardized by the W3C. In addition several other non-standard serialization formats are used to fulfill specific needs. The relative advantages and disadvantages of the different serialization formats are discussed below, along with a code sample showing a simple graph expressed in each serialization.

RDF/XML

The RDF/XML syntax [9] is standardized by the W3C and is widely used to publish Linked Data on the Web. However, the syntax is also viewed as difficult for humans to read and write, and, therefore, consideration should be given to using other serializations in data management and curation workflows that involve human intervention, and to the provision of alternative serializations for consumers who may wish to eyeball the data. The RDF/XML syntax is described in detail as part of the W3C RDF Primer [76]. The MIME type that should be used for RDF/XML within HTTP content negotiation is application/rdf+xml . The listing below show the RDF/XML serialization of two RDF triples. The first one states that there is a thing, identified by the URI http://biglynx.co.uk/people/dave-smith of type Person . The second triple state that this thing has the name Dave Smith.

1 <?xml version="1.0" encoding="UTF-8"?>

2 <rdf:RDF

3 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

4 xmlns:foaf="http://xmlns.com/foaf/0.1/">

5

6 <rdf:Description rdf:about="http://biglynx.co.uk/people/dave-smith">

7 <rdf:type rdf:resource="http://xmlns.com/foaf/0.1/Person"/>

8 <foaf:name>Dave Smith</foaf:name>

9 </rdf:Description>

10

11 </rdf:RDF>

RDFa

RDFa [1] is a serialization format that embeds RDF triples in HTML documents. The RDF data is not embedded in comments within the HTML document, as was the case with some early attempts to mix RDF and HTML, but is interwoven within the HTML Document Object Model (DOM). This means that existing content within the page can be marked up with RDFa by modifying HTML code, thereby exposing structured data to the Web. A detailed introduction into RDFa is given in the W3C RDFa Primer [1].

RDFa is popular in contexts where data publishers are able to modify HTML templates but have relatively little additional control over the publishing infrastructure. For example, many content management systems will enable publishers to configure the HTML templates used to expose different types of information, but may not be flexible enough to support 303 redirects and HTTP content negotiation. When using RDFa to publish Linked Data on the Web, it is important to maintain the unambiguous distinction between the real-world objects described by the data and the HTML+RDFa document that embodies these descriptions. This can be achieved by using the RDFa about= attribute to assign URI references to the real-world objects described by the data. If these URIs are first defined in an RDFa document they will follow the hash URI pattern.

1 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">

2 <html xmlns="http://www.w3.org/1999/xhtml" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:foaf="http://xmlns.com/foaf/0.1/">

3

4 <head>

5 <meta http-equiv="Content-Type" content="application/xhtml+xml; charset=UTF-8"/>

6 <title>Profile Page for Dave Smith

7 </head>

8

9 <body>

10 <div about="http://biglynx.co.uk/people#dave-smith" typeof="foaf:Person">

11 <span property="foaf:name">Dave Smith

12 </div>

13 </body>

14

15 </html>

Turtle

Turtle is a plain text format for serializing RDF data. Due to its support for namespace prefixes and various other shorthands, Turtle is typically the serialization format of choice for reading RDF triples or writing them by hand. A detailed introduction to Turtle is given in the W3C Team Submission document Turtle - Terse RDF Triple Language [10]. The MIME type for Turtle is text/turtle;charset=utf-8 .

1 @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

2 @prefix foaf: <http://xmlns.com/foaf/0.1/> .

3

4 <http://biglynx.co.uk/people/dave-smith>

5 rdf:type foaf:Person ;

6 foaf:name "Dave Smith" .

N-Triples

N-Triples is a subset of Turtle, minus features such as namespace prefixes and shorthands. The result is a serialization format with lots of redundancy, as all URIs must be specified in full in each triple. Consequently, N-Triples files can be rather large relative to Turtle and even RDF/XML. However, this redundancy is also the primary advantage of N-Triples over other serialization formats, as it enables N-Triples files to be parsed one line at a time, making it ideal for loading large data files that will not fit into main memory. The redundancy also makes N-Triples very amenable to compression, thereby reducing network traffic when exchanging files. These two factors make N-Triples the de facto standard for exchanging large dumps of Linked Data, e.g., for backup or mirroring purposes. The complete definition of the N-Triples syntax is given as part of the W3C RDF Test Cases recommendation12.

1 <http://biglynx.co.uk/people/dave-smith> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://xmlns.com/foaf/0.1/Person> .

2 <http://biglynx.co.uk/people/dave-smith> <http://xmlns.com/foaf/0.1/name> "Dave Smith" .

RDF/JSON

RDF/JSON refers to efforts to provide a JSON (JavaScript Object Notation) serialization for RDF, the most widely adopted of which is the Talis specification13 [4]. Availability of a JSON serialization of RDF is highly desirable, as a growing number of programming languages provide native JSON support, including staples of Web programming such as JavaScript and PHP. Publishing RDF data in JSON therefore makes it accessible to Web developers without the need to install additional software libraries for parsing and manipulating RDF data. It is likely that further efforts will be made in the near future to standardize a JSON serialization of RDF14.

2.5 Including Links to other Things

The forth Linked Data principle is to set RDF links pointing into other data sources on the Web. Such external RDF links are fundamental for the Web of Data as they are the glue that connects data islands into a global, interconnected data space and as they enable applications to discover additional data sources in a follow-your-nose fashion.

Technically, an external RDF link is an RDF triple in which the subject of the triple is a URI reference in the namespace of one data set, while the predicate and/or object of the triple are URI references pointing into the namespaces of other data sets. Dereferencing these URIs yields a description of the linked resource provided by the remote server. This description will usually contain additional RDF links which point to other URIs that, in turn, can also be dereferenced, and so on. This is how individual resource descriptions are woven into the Web of Data. This is also how the Web of Data can be navigated using a Linked Data browser or crawled by the robot of a search engine. There are three important types of RDF links:

Relationship Links point at related things in other data sources, for instance, other people, places or genes. For example, relationship links enable people to point to background information about the place they live, or to bibliographic data about the publications they have written. Identity Links point at URI aliases used by other data sources to identify the same real-world object or abstract concept. Identity links enable clients to retrieve further descriptions about an entity from other data sources. Identity links have an important social function as they enable different views of the world to be expressed on the Web of Data. Vocabulary Links point from data to the definitions of the vocabulary terms that are used to represent the data, as well as from these definitions to the definitions of related terms in other vocabularies. Vocabulary links make data self-descriptive and enable Linked Data applications to understand and integrate data across vocabularies.

The following section gives examples of all three types of RDF link and discusses their role on the Web of Data.

2.5.1 Relationship Links

The Web of Data contains information about a multitude of things ranging from people, companies, and places, to films, music, books, genes, and various other types of data. Chapter 3 will give an overview of the data sources that currently make up the Web of Data.

RDF links enable references to be set from within one data set to entities described in another, which may, in turn, have descriptions that refer to entities in a third data set, and so on. Therefore, setting RDF links not only connects one data source to another, but enables connections into a potentially infinite network of data that can be used collectively by client applications.

1 @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

2 @prefix foaf: <http://xmlns.com/foaf/0.1/> .

3

4 <http://biglynx.co.uk/people/dave-smith>

5 rdf:type foaf:Person ;

6 foaf:name "Dave Smith" ;

7 foaf:based_near <http://sws.geonames.org/3333125/> ;

8 foaf:based_near <http://dbpedia.org/resource/Birmingham> ;

9 foaf:topic_interest <http://dbpedia.org/resource/Wildlife_photography> ;

10 foaf:knows <http://dbpedia.org/resource/David_Attenborough> .

The example above demonstrates how Big Lynx uses RDF links pointing at related entities to enrich the data it publishes about its Managing Director Dave Smith. In order to provide background information about the place where he lives, the example contains an RDF link stating that Dave is based_near something identified by the URI http://sws.geonames.org/3333125/ . Linked Data applications that look up this URI will retrieve a extensive description of Birmingham from Geonames15, a data source that provides names of places (in different languages), geo-coordinates, and information about administrative structures. The Geonames data about Birmingham will contain a further RDF link pointing at http://dbpedia.org/resource/Birmingham .

By following this link, applications can find population counts, postal codes, descriptions in 90 languages, and lists of famous people and bands that are related to Birmingham . The description of Birmingham provided by DBpedia, in turn, contains RDF links pointing at further data sources that contain data about Birmingham. Therefore, by setting a single RDF link, Big Lynx has enabled applications to retrieve data from a network of interlinked data sources.

2.5.2 Identity Links

The fact that HTTP URIs are not only identifiers, but also a means to access information, results in many different URIs being used to refer to the same real-world object.

The rationale for, and implications of, this can be illustrated with an example of someone (who will be known as Jeff) who wants to publish data on the Web describing himself. Jeff must first define a URI to identify himself, in a namespace that he owns, or in which the domain name owner has allowed him to create new URIs. He then sets up a Web server to return the data describing himself, in response to someone looking up his URI over the HTTP protocol. After looking up the URI and receiving the descriptive data, an information consumer knows two things: first, the data about Jeff; second, the origin of that data, as he has retrieved the data from a URI under Jeff’s control.

But what happens if Jeff wants to publish data describing a location or a famous person on the Web? The same procedure applies: Jeff defines URIs identifying the location and the famous person in his namespace and serves the data when somebody looks up these URIs. Information consumers that look up Jeff’s URIs get his data and know again that he has published it.

In an open environment like the Web it is likely that Jeff is not the only one talking about the place or the famous person, but that there are many different information providers who talk about the same entities. As they all use their own URIs to refer to the person or place, the result is multiple URIs identifying the same entity. These URIs are called URI aliases.

In order to still be able to track the different information providers speak about the same entity, Linked Data relies on setting RDF links between URI aliases. By common agreement, Linked Data publishers use the link type http://www.w3.org/2002/07/owl#sameAs to state that two URI aliases refer to the same resource. For instance, if Dave Smith would also maintain a private data homepage besides the data that Big Lynx publishes about him, he could add a http://www.w3.org/2002/07/owl#sameAs link to his private data homepage, stating that the URI used to refer to him in this document and the URI used by Big Lynx both refer to the same real-world entity.

1 <http://www.dave-smith.eg.uk#me> <http://www.w3.org/2002/07/owl#sameAs> <http://biglynx.co.uk/people/dave-smith> .

To use different URIs to refer to the same entity and to use owl:sameAs links to connect these URIs appears to be cumbersome at first sight, but is actually essential to make the Web of Data work as a social system. The reasons for this are:

Different opinions. URI aliases have an important social function on the Web of Data as they are dereferenced to descriptions of the same resource provided by different data publishers and thus allow different views and opinions to be expressed. Traceability. Using different URIs allows consumers of Linked Data to know what a particular publisher has to say about a specific entity by dereferencing the URI that is used by this publisher to identify the entity. No central points of failure. If all things in the world were to each have one, and only one, URI, this would entail the creation and operation of a centralized naming authority to assign URIs. The coordination complexity, administrative and bureaucratic overhead this would introduce would create a major barrier to growth in the Web of Data.

The last point becomes especially clear when one considers the size of many data sets that are part of the Web of Data. For instance, the Geonames data set provides information about over eight million locations. If in order to start publishing their data on the Web of Data, the Geonames team would need to find out what the commonly accepted URIs for all these places would be, doing so would be so much effort that it would likely prevent Geonames from publishing their dataset as Linked Data at all. Defining URIs for the locations in their own namespace lowers the barrier to entry, as they do not need to know about other people’s URIs for these places. Later, they, or somebody else, may invest effort into finding and publishing owl:sameAs links pointing to data about these places other datasets, enabling progressive adoption of the Linked Data principles.

Therefore, in contrast to relying on upfront agreement on URIs, the Web of Linked Data relies on solving the identity resolution problem in an evolutionary and distributed fashion: evolutionary, in that more and more owl:sameAs links can be added over time; and distributed, in that different data providers can publish owl:sameAs links and as the overall effort for creating these links can thus shared between the different parties.

There has been significant uncertainty in recent years about whether owl:sameAs or other predicates should be used to express identity links [53]. A major source of this uncertainty is that the OWL semantics [93] treat RDF statements as facts rather then as claims by different information providers. Today, owl:sameAs is widely used in the Linked Data context and hundreds of millions of owl:sameAs links are published on the Web. Therefore, we recommend to also use owl:sameAs to express identity links, but always to keep in mind that the Web is a social system and that all its content needs to be treated as claims by different parties rather than as facts (see Section 6.3.5 on Data Quality Assessment). This guidance is also supported by members of the W3C Technical Architecture Group (TAG)16.

2.5.3 Vocabulary Links

The promise of the Web of Data is not only to enable client applications to discover new data sources by following RDF links at run-time but also to help them to integrate data from these sources. Integrating data requires bridging between the schemata that are used by different data sources to publish their data. The term schema is understood in the Linked Data context as the mixture of distinct terms from different RDF vocabularies that are used by a data source to publish data on the Web. This mixture may include terms from widely used vocabularies (see Section 4.4.4) as well as proprietary terms.

The Web of Data takes a two-fold approach to dealing with heterogeneous data representation [22]. On the one hand side, it tries to avoid heterogeneity by advocating the reuse of terms from widely deployed vocabularies. As discussed in Section 4.4.4 a set of vocabularies for describing common things like people, places or projects has emerged in the Linked Data community. Thus, whenever these vocabularies already contain the terms needed to represent a specific data set, they should be used. This helps to avoid heterogeneity by relying on ontological agreement.

On the other hand, the Web of Data tries to deal with heterogeneity by making data as self-descriptive as possible. Self-descriptiveness [80] means that a Linked Data application which discovers some data on the Web that is represented using a previously unknown vocabulary should be able to find all meta-information that it requires to translate the data into a representation that it understands and can process. Technically, this is realized in a twofold manner: first, by making the URIs that identify vocabulary terms dereferenceable so that client applications can look up the RDFS and OWL definition of terms – this means that every vocabulary term links to its own definition [23]; second, by publishing mappings between terms from different vocabularies in the form of RDF links [80]. Together these techniques enable Linked Data applications to discover the meta-information that they need to integrate data in a follow-your-nose fashion along RDF links.

Linked Data publishers should therefore adopt the following workflow: first, search for terms from widely used vocabularies that could be reused to represent data (as described in Section 4.4.4); if widely deployed vocabularies do not provide all terms that are needed to publish the complete content of a data set, the required terms should be defined as a proprietary vocabulary (as described in Section 4.4.6) and used in addition to terms from widely deployed vocabularies. Wherever possible, the publisher should seek wider adoption for the new, proprietary vocabulary from others with related data.

If at a later point in time, the data publisher discovers that another vocabulary contains the same term as the proprietary vocabulary, an RDF link should be set between the URIs identifying the two vocabulary terms, stating that these URIs actually refer to the same concept (= the term). The Web Ontology Language (OWL) [79], RDF Schema (RDFS) [37] and the Simple Knowledge Organization System (SKOS) [81] define RDF link types that can be used to represent such mappings. owl:equivalentClass and owl:equivalentProperty can be used to state that terms in different vocabularies are equivalent. If a looser mapping is desired, then rdfs:subClassOf , rdfs:subPropertyOf , skos:broadMatch , and skos:narrowMatch can be used.

The example below illustrates how the proprietary vocabulary term http://biglynx.co.uk/vocab/sme#SmallMediumEnterprise is interlinked with related terms from the DBpedia, Freebase, UMBEL, and OpenCyc.

1 @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

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

3 @prefix owl: <http://www.w3.org/2002/07/owl#> .

4 @prefix co: <http://biglynx.co.uk/vocab/sme#> .

5

6 <http://biglynx.co.uk/vocab/sme#SmallMediumEnterprise>

7 rdf:type rdfs:Class ;

8 rdfs:label "Small or Medium-sized Enterprise" ;

9 rdfs:subClassOf <http://dbpedia.org/ontology/Company> .

10 rdfs:subClassOf <http://umbel.org/umbel/sc/Business> ;

11 rdfs:subClassOf <http://sw.opencyc.org/concept/Mx4rvVjQNpwpEbGdrcN5Y29ycA> ;

12 rdfs:subClassOf <http://rdf.freebase.com/ns/m/0qb7t> .

Just as owl:sameAs links can be used to incrementally interconnect URI aliases, term-level links between different vocabularies can also be set over time by different parties. The more links that are set between vocabulary terms, the better client applications can integrate data that is represented using different vocabularies. Thus, the Web of Data relies on a distributed, pay-as-you-go approach to data integration, which enables the integration effort to be split over time and between different parties [51][74][34]. This type of data integration is discussed in more detail in Section 6.4.

This chapter has outlined the basic principles of Linked Data and has described how the principles interplay in order to extend the Web with a global data space. Similar to the classic document Web, the Web of Data is built on a small set of standards and the idea to use links to connect content from different sources. The extent of its dependence on URIs and HTTP demonstrates that Linked Data is not disjoint from the Web at large, but simply an application of its principles and key components to novel forms of usage. Far from being an additional layer on top of but separate from the Web, Linked Data is just another warp or weft being steadily interwoven with the fabric of the Web.

Structured data is made available on the Web today in forms. Data is published as CSV data dumps, Excel spreadsheets, and in a multitude of domain-specific data formats. Structured data is embedded into HTML pages using Microformats17. Various data providers have started to allow direct access to their databases via Web APIs.

So what is the rationale for adopting Linked Data instead of, or in addition to, these well-established publishing techniques? In summary, Linked Data provides a more generic, more flexible publishing paradigm which makes it easier for data consumers to discover and integrate data from large numbers of data sources. In particular, Linked Data provides:

A unifying data model . Linked Data relies on RDF as a single, unifying data model. By providing for the globally unique identification of entities and by allowing different schemata to be used in parallel to represent data, the RDF data model has been especially designed for the use case of global data sharing. In contrast, the other methods for publishing data on the Web rely on a wide variety of different data models, and the resulting heterogeneity needs to be bridged in the integration process.

. Linked Data relies on RDF as a single, unifying data model. By providing for the globally unique identification of entities and by allowing different schemata to be used in parallel to represent data, the RDF data model has been especially designed for the use case of global data sharing. In contrast, the other methods for publishing data on the Web rely on a wide variety of different data models, and the resulting heterogeneity needs to be bridged in the integration process. A standardized data access mechanism. Linked Data commits itself to a specific pattern of using the HTTP protocol. This agreement allows data sources to be accessed using generic data browsers and enables the complete data space to be crawled by search engines. In contrast, Web APIs are accessed using different proprietary interfaces.

Linked Data commits itself to a specific pattern of using the HTTP protocol. This agreement allows data sources to be accessed using generic data browsers and enables the complete data space to be crawled by search engines. In contrast, Web APIs are accessed using different proprietary interfaces. Hyperlink-based data discovery . By using URIs as global identifiers for entities, Linked Data allows hyperlinks to be set between entities in different data sources. These data links connect all Linked Data into a single global data space and enable Linked Data applications to discover new data sources at run-time. In contrast, Web APIs as well as data dumps in proprietary formats remain isolated data islands.

. By using URIs as global identifiers for entities, Linked Data allows hyperlinks to be set between entities in different data sources. These data links connect all Linked Data into a single global data space and enable Linked Data applications to discover new data sources at run-time. In contrast, Web APIs as well as data dumps in proprietary formats remain isolated data islands. Self-descriptive data. Linked Data eases the integration of data from different sources by relying on shared vocabularies, making the definitions of these vocabularies retrievable, and by allowing terms from different vocabularies to be connected to each other by vocabulary links.

Compared to the other methods of publishing data on the Web, these properties of the Linked Data architecture make it easier for data consumers to discover, access and integrate data. However, it is important to remember that the various publication methods represent a continuum of benefit, from making data available on the Web in any form, to publishing Linked Data according to the principles described in this chapter.

Progressive steps can be taken towards Linked Data publishing, each of which make it easier for third parties to consume and work with the data. These steps include making data available on the Web in any format but under an open license, to using structured, machine-readable formats that are preferably non-proprietary, to adoption of open standards such as RDF, and to inclusion of links to other data sources.

Tim Berners-Lee has described this continuum in terms of a five-star rating scheme [16], whereby data publishers can nominally award stars to their data sets according to the following criteria:

1 Star: data is available on the web (whatever format), but with an open license.

2 Stars: data is available as machine-readable structured data (e.g., Microsoft Excel instead of a scanned image of a table).

3 Stars: data is available as (2) but in a non-proprietary format (e.g., CSV instead of Excel).

4 Stars: data is available according to all the above, plus the use of open standards from the W3C (RDF and SPARQL) to identify things, so that people can link to it.

5 Stars: data is available according to all the above, plus outgoing links to other people’s data to provide context.

Crucially, each rating can be obtained in turn, representing a progressive transition to Linked Data rather than a wholesale adoption in one operation.

A significant number of individuals and organisations have adopted Linked Data as a way to publish their data, not just placing it on the Web but using Linked Data to ground it in the Web [80]. The result is a global data space we call the Web of Data [30]. The Web of Data forms a giant global graph [17] consisting of billions of RDF statements from numerous sources covering all sorts of topics, such as geographic locations, people, companies, books, scientific publications, films, music, television and radio programmes, genes, proteins, drugs and clinical trials, statistical data, census results, online communities and reviews.

The Web of Data can be seen as an additional layer that is tightly interwoven with the classic document Web and has many of the same properties:

The Web of Data is generic and can contain any type of data. Anyone can publish data to the Web of Data. The Web of Data is able to represent disagreement and contradictionary information about an entity. Entities are connected by RDF links, creating a global data graph that spans data sources and enables the discovery of new data sources. This means that applications do not have to be implemented against a fixed set of data sources, but they can discover new data sources at run-time by following RDF links. Data publishers are not constrained in their choice of vocabularies with which to represent data. Data is self-describing. If an application consuming Linked Data encounters data described with an unfamiliar vocabulary, the application can dereference the URIs that identify vocabulary terms in order to find their definition. The use of HTTP as a standardized data access mechanism and RDF as a standardized data model simplifies data access compared to Web APIs, which rely on heterogeneous data models and access interfaces.

3.1 Bootstrapping the Web of Data

The origins of this Web of Data lie in the efforts of the Semantic Web research community and particularly in the activities of the W3C Linking Open Data (LOD) project18, a grassroots community effort founded in January 2007. The founding aim of the project, which has spawned a vibrant and growing Linked Data community, was to bootstrap the Web of Data by identifying existing data sets available under open licenses, convert them to RDF according to the Linked Data principles, and to publish them on the Web. As a point of principle, the project has always been open to anyone who publishes data according to the Linked Data principles. This openness is a likely factor in the success of the project in bootstrapping the Web of Data.

Figure 3.1 and Figure 3.2 demonstrates how the number of data sets published on the Web as Linked Data has grown since the inception of the Linking Open Data project. Each node in the diagram represents a distinct data set published as Linked Data. The arcs indicate the existence of links between items in the two data sets. Heavier arcs correspond to a greater number of links, while bidirectional arcs indicate that outward links to the other exist in each data set.

Figure 3.2 illustrates the November 2010 scale of the Linked Data Cloud originating from the Linking Open Data project and classifies the data sets by topical domain, highlighting the diversity of data sets present in the Web of Data. The graphic shown in this figure is available online at http://lod-cloud.net . Updated versions of the graphic will be published on this website in regular intervals. More information about each of these data sets can be found by exploring the LOD Cloud Data Catalog19 which is maintained by the LOD community within the Comprehensive Knowledge Archive Network (CKAN)20, a generic catalog that lists open-license datasets represented using any format.

If you publish a linked data set yourself, please also add it to this catalog so that it will be included into the next version of the cloud diagram. Instructions on how to add data sets to the catalog are found in the ESW wiki21.

3.2 Topology of the Web of Data

This section gives an overview of the topology of the Web of Data as of November 2010. Data sets are classified into the following topical domains: geographic, government, media, libraries, life science, retail and commerce, user-generated content, and cross-domain data sets. Table3.1 gives an overview of the number of triples at this point in time, as well as the number of RDF links per domain. The number of RDF links refers to out-going links that are set from data sources within a domain to other data sources. The numbers are taken from the State of the LOD Cloud document22 which on a regular basis compiles summary statistics about the data sets that are cataloged within the LOD Cloud Data Catalog on CKAN.

Domain Data Sets Triples Percent RDF Links Percent Cross-domain 20 1,999,085,950 7.42 29,105,638 7.36 Geographic 16 5,904,980,833 21.93 16,589,086 4.19 Government 25 11,613,525,437 43.12 17,658,869 4.46 Media 26 2,453,898,811 9.11 50,374,304 12.74 Libraries 67 2,237,435,732 8.31 77,951,898 19.71 Life sciences 42 2,664,119,184 9.89 200,417,873 50.67 User Content 7 57,463,756 0.21 3,402,228 0.86 203 26,930,509,703 395,499,896

Some of the first data sets that appeared in the Web of Data are not specific to one topic, but span multiple domains. This cross-domain coverage is crucial for helping to connect domain-specific data sets into a single, interconnected data space, thereby avoiding fragmentation of the Web of Data into isolated, topical data islands. The prototypical example of cross-domain Linked Data is DBpedia23 [32], a data set automatically extracted from publicly available Wikipedia dumps. Things that are the subject of a Wikipedia article are automatically assigned a DBpedia URI, based on the URI of that Wikipedia article. For example, the Wikipedia article about the city of Birmingham has the following URI http://en.wikipedia.org/wiki/Birmingham . Therefore, Birmingham has the corresponding DBpedia URI http://dbpedia.org/resource/Birmingham which is not the URI of a Web page about Birmingham , but a URI that identifies the city itself. RDF statements that refer to this URI are then generated by extracting information from various parts of the Wikipedia articles, in particular the infoboxes commonly seen on the right hand side of Wikipedia articles. Because of its breadth of topical coverage, DBpedia has served as a hub within the Web of Data from the early stages of the Linking Open Data project. The wealth of inward and outward links connecting items in DBpedia to items in other data sets is apparent in Figure 3.2.

A second major source of cross-domain Linked Data is Freebase24, an editable, openly-licensed database populated through user contributions and data imports from sources such as Wikipedia and Geonames. Freebase provides RDF descriptions of items in the database, which are linked to items in DBpedia with incoming and outgoing links.

Further cross-domain data sets include UMBEL25, YAGO [104], and OpenCyc26. These are, in turn, linked with DBpedia, helping to facilitate data integration across a wide range of interlinked sources.

3.2.2 Geographic Data

Geography is another factor that can often connect information from varied topical domains. This is apparent in the Web of Data, where the Geonames27 data set frequently serves as a hub for other data sets that have some geographical component. Geonames is an open-license geographical database that publishes Linked Data about 8 million locations.

A second significant data set in this area is LinkedGeoData [102], a Linked Data conversion of data from the OpenStreetMap project, which provided information about more than 350 million spatial features. Wherever possible, locations in Geonames and LinkedGeoData are interlinked with corresponding locations in DBpedia, ensuring there is a core of interlinked data about geographical locations.

Linked Data versions of the EuroStat28, World Factbook29 and US Census30 data sets begin to bridge the worlds of statistics, politics and social geography, while Ordnance Survey (the national mapping agency of Great Britain) has begun to publish Linked Data describing the administrative areas within the Great Britain31, in efforts related to the data.gov.uk initiative described below.

3.2.3 Media Data

One of the first large organisations to recognise the potential of Linked Data and adopt the principles and technologies into their publishing and content management workflows has been the British Broadcasting Corporation (BBC). Following earlier experiments with publishing their catalogue of programmes as RDF, the BBC released in 2008 two large sites that combine publication of Linked Data and conventional Web pages. The first of these, /programmes32 provides a URI for and RDF description of every episode of every TV or radio programme broadcast across the BBC’s various channels [71].

The second of these sites, /music33, publishes Linked Data about every artist whose music has been played on BBC radio stations, including incoming links from the specific programme episode during which it was broadcasted. This music data is interlinked with DBpedia, and it receives incoming links from a range of music-related Linked Data sources. These cross-data set links allow applications to consume data from all these sources and integrate it to provide rich artist profiles, while the playlist data can be mined to find similarities between artists that may be used to generate recommendations.

More recently, the BBC have launched the site Wildlife Finder34, which presents itself to users as a conventional Web site with extensive information about animal species, behaviours and habitats. Behind the scenes, each of these is identified by an HTTP URI and described in RDF. Outgoing links connect each species, behaviour and habitat to the corresponding resources in the DBpedia data set, and to BBC Programmes that depict these.

An indicator of the potential for Linked Data technologies within the enterprise, as well as on the public Web, comes from the BBC’s World Cup 2010 Web site35. This high-traffic, public-facing Web site was populated with data modelled in RDF and stored in an RDF triple store36. In this case, the goal of using RDF was not to expose Linked Data for consumption by third parties, but to aid internal content management and data integration in a domain with high levels of connectivity between players, teams, fixtures and stadia.

Elsewhere in the media sector, there have also been significant moves towards Linked Data by major players. The New York Times has published a significant proportion of its internal subject headings as Linked Data37 under a Creative Commons Attribution license (see Section 4.3.3), interlinking these topics with DBpedia, Freebase and Geonames. The intention is to use this liberally-licensed data as a map to lead people to the rich archive of content maintained by the New York Times.

As early as 2008, Thomson Reuters launched Calais38, a Web service capable of annotating documents with the URIs of entities (e.g., places, people and companies) mentioned in the text. In many cases these Calais URIs are linked to equivalent URIs elsewhere in the Web of Data, such as to DBpedia and the CIA World Factbook. Services such as this are particularly significant for their ability to bridge Linked Data and conventional hypertext documents, potentially allowing documents such as blog posts or news articles to be enhanced with relevant pictures or background data.

3.2.4 Government Data

Governmental bodies and public-sector organisations produce a wealth of data, ranging from economic statistics, to registers of companies and land ownership, reports on the performance of schools, crime statistics, and the voting records of elected representatives. Recent drives to increase government transparency, most notably in countries such as Australia39, New Zealand40, the U.K.41 and U.S.A.42, have led to a significant increase in the amount of governmental and public-sector data that is made accessible on the Web. Making this data easily accessible enables organisations and members of the public to work with the data, analyse it to discover new insights, and build tools that help communicate these findings to others, thereby helping citizens make informed choices and hold public servants to account.

The potential of Linked Data for easing the access to government data is increasingly understood, with both the data.gov.uk43 and data.gov44 initiatives publishing significant volumes of data in RDF. The approach taken in the two countries differs slightly: to date the latter has converted very large volumes of data, while the former has focused on the creation of core data-level infrastructure for publishing Linked Data, such as stable URIs to which increasing amounts of data can be connected [101].

In a very interesting initiative is being pursued by the UK Civil Service45 which has started to mark up job vacancies using RDFa. By providing information about open positions in a structured form, it becomes easier for external job portals to incorporate civil service jobs [25]. If more organizations would follow this example, the transparency in the labor market could be significantly increased [31].

Further high-level guidance on "Putting Government Data online" can be found in [18]. In order to provide a forum for coordinating the work on using Linked Data and other Web standards to improve access to government data and increase government transparency, W3C has formed a eGovernment Interest Group46.

3.2.5 Libraries and Education

With an imperative to support novel means of discovery, and a wealth of experience in producing high-quality structured data, libraries are natural complementors to Linked Data. This field has seen some significant early developments which aim at integrating library catalogs on a global scale; interlinking the content of multiple library catalogs, for instance, by topic, location, or historical period; interlink library catalogs with third party information (picture and video archives, or knowledge bases like DBpedia); and at making library data easier accessible by relying on Web standards.

Examples include the American Library of Congress and the German National Library of Economics which publish their subject heading taxonomies as Linked Data (see 47 and [86], respectively), while the complete content of LIBRIS and the Swedish National Union Catalogue is available as Linked Data4849. Similarly, the OpenLibrary, a collaborative effort to create "one Web page for every book ever published"50 publishes its catalogue in RDF, with incoming links from data sets such as ProductDB (see Section 3.2.7 below).

Scholarly articles from journals and conferences are also well represented in the Web of Data through community publishing efforts such as DBLP as Linked Data515253, RKBexplorer54, and the Semantic Web Dogfood Server55 [84].

An application that facilitates this scholarly data space is Talis Aspire56. The application supports educators in the creation and management of literature lists for university courses. Items are added to these lists through a conventional Web interface; however, behind the scenes, the system stores these records as RDF and makes the lists available as Linked Data. Aspire is used by various universities in the UK, which, in turn, have become Linked Data providers. The Aspire application is explored in more detail in Section 6.1.2.

High levels of ongoing activity in the library community will no doubt lead to further significant Linked Data deployments in this area. Of particular note in this area is the new Object Reuse and Exhange (OAI-ORE) standard from the Open Archives Initiative [110], which is based on the Linked Data principles. The OAI-ORE, Dublin Core, SKOS, and FOAF vocabularies form the foundation of the new Europeana Data Model57. The adoption of this model by libraries, museums and cultural institutions that participate in Europeana will further accelerate the availability of Linked Data related to publications and cultural heritage artifacts.

In order to provide a forum and to coordinate the efforts to increase the global interoperability of library data, W3C has started a Library Linked Data Incubator Group58.

3.2.6 Life Sciences Data

Linked Data has gained significant uptake in the Life Sciences as a technology to connect the various data sets that are used by researchers in this field. In particular, the Bio2RDF project [11] has interlinked more than 30 widely used data sets, including UniProt (the Universal Protein Resource), KEGG (the Kyoto Encyclopedia of Genes and Genomes), CAS (the Chemical Abstracts Service), PubMed, and the Gene Ontology. The W3C Linking Open Drug Data effort59 has brought together the pharmaceutical companies Eli Lilly, AstraZeneca, and Johnson & Johnson, in a cooperative effort to interlink openly-licensed data about drugs and clinical trials, in order to aid drug-discovery [68].

3.2.7 Retail and Commerce

The RDF Book Mashup60 [29] provided an early example of publishing Linked Data related to retail and commerce. The Book Mashup uses the Simple Commerce Vocabulary61 to represent and republish data about book offers retrieved from the Amazon.com and Google Base Web APIs.

More recently, the GoodRelations ontology62 [63] has provided a richer ontology for describing many aspects of e-commerce, such as businesses, products and services, offerings, opening hours, and prices. GoodRelations has seen significant uptake from retailers such as Best Buy63 and Overstock.com64 seeking to increase their visibility in search engines such as Yahoo! and Google, that recognise data published in RDFa using certain vocabularies and use this data to enhance search results (see Section 6.1.1.2). The adoption of the GoodRelations ontology has even extended to the publication of price lists for courses offered by The Open University65.

The ProductDB Web site and data set66 aggregates and links data about products for a range of different sources and demonstrates the potential of Linked Data for the area of product data integration.

3.2.8 User Generated Content and Social Media

Some of the earliest data sets in the Web of Data were based on conversions of, or wrappers around, Web 2.0 sites with large volumes of user-generated content. This has produced data sets and services such as DBpedia and the FlickrWrappr67, a Linked Data wrapper around the Flickr photo-sharing service. These were complemented by user-generated content sites that were built with native support for Linked Data, such as Revyu.com [61] for reviews and ratings, and Faviki68 for annotating Web content with Linked Data URIs. Wiki systems that provide for publishing structured content as Linked Data on the Web include Semantic MediaWiki69 and Ontowiki70. There are several hundred publicly accessible Semantic MediaWiki installations71 that publish their content to the Web of Data.

More recently, Linked Data principles and technologies have been adopted by major players in the user-generated content and social media spheres, the most significant example of which is the development and adoption by Facebook of the Open Graph Protocol72. The Open Graph Protocol enables Web publishers to express a few basic pieces of information about the items described in their Web pages, using RDFa (see Section 2.4.2). This enables Facebook to more easily consume data from sites across the Web, as it is published at source in structured form. Within a few months of its launch, numerous major destination sites on the Web, such as the Internet Movie Database73, had adopted the Open Graph Protocol to publish structured data describing items featured on their Web pages. The primary challenge for the Open Graph Protocol is to enable a greater degree of linking between data sources, within the framework that has already been well established.

Another area in which RDFa is enabling the publication of user-generated content as Linked Data is through the Drupal content management system74. Version 7 of Drupal enables the description of Drupal entities, such as users, in RDFa.

The data sets described in this chapter demonstrate the diversity in the Web of Data. Recently published data sets, such as Ordnance Survey, legislation.gov.uk, the BBC, and the New York Times data sets, demonstrate how the Web of Data is evolving from data publication primarily by third party enthusiasts and researchers, to data publication at source by large media and public sector organisations. This trend is expected to gather significant momentum, with organisations in other industry sectors publishing their own data according to the Linked Data principles.

Linked Data is made available on the Web using a wide variety of tools and publishing patterns. In the following Chapters 4 and 5, we will examine the design decisions that must be taken to ensure your Linked Data sits well in the Web, and the technical options available for publishing it.

So far this book has introduced the basic principles of Linked Data (Chapter 2) and given an overview of how these principles are being applied to the publication of data from a wide variety of domains (Chapter 3). This chapter will discuss the primary design considerations that must be taken into account when preparing data to be published as Linked Data on the Web, before introducing specific publishing recipes in Chapter 5.

These design considerations are not about visual design, but about how one shapes and structures data to fit neatly in the Web. They break down into three areas, each of which maps onto one or two of the Linked Data principles: [(1)] naming things with URIs; describing things with RDF; and making links to other data sets.

The outcome of these design decisions contributes directly to the utility and usability of a set of Linked Data, and therefore ultimately its value to the people and software programs that use it.

4.1 Using URIs as Names for Things

As discussed in Chapter 2, the first principle of Linked Data is that URIs should be used as names for things that feature in your data set. These things might be concrete real-world entities such as a person, a building, your dog, or more abstract notions such as a scientific concept. Each of these things needs a name so that you and others can refer to it. Just as significant care should go into the design of URIs for pages in a conventional Web site, so should careful decisions be made about the design of URIs for a set of Linked Data. This section will explore these issues in detail.

4.1.1 Minting HTTP URIs

The second principle of Linked Data is that URIs should be created using the http:// URI scheme. This allows these names to be looked up using any client, such as a Web browser, that speaks the HTTP protocol.

In practical terms, using http:// URIs as names for things simply amounts to a data publisher choosing part of an http:// namespace that she controls, by virtue of owning the domain name, running a Web server at that location, and minting URIs in this namespace to identify the things in her data set.

For example, Big Lynx owns the domain name biglynx.co.uk and runs a Web server at http://biglynx.co.uk/ . Therefore, they are free to mint URIs in this namespace to use as names for things they want to talk about. If Big Lynx wish to mint URIs to identify members of staff, they may do this in the namespace http://biglynx.co.uk/people/ .

4.1.2 Guidelines for Creating Cool URIs

As discussed in Chapter 1, 