• No se han encontrado resultados

3.1

Overview

Linked datatackles the specifics of deploying RDF data on the web. It is currently not supported by CoIM (and thus not prerequisite knowledge for understanding it), but the logical next step in its RDF support. What this next step might look like is explained as “future research” at the end of this chapter.

Linked data is a collection of best practices for the deployment of RDF data: How can it be distributed and processed on a large scale? How can machine readability, navigability and usability for humans be ensured at that scale? Linked data is based on the ideas that made the web of documents successful and extends them to build a web of data [Hea09]. For practical applications, the termlinked datais increasingly replacing the termsemantic web. There is no clear consensus1 how the two terms

are related, the most common understanding is that linked data is a sub-topic of the semantic web, providing a data infrastructure on which semantics can be based. This chapter first explains the core concepts surrounding linked data and shows how linked data can be made easy to discover. A number of technologies help with write-enabling linked data and turn sets of linked data into lean web services that are founded on simple principles. The chapter concludes with future research.

3.2

Core concepts

[BHBL09] describes linked data as follows:

1http://tomheath.com/blog/2009/03/linked-data-web-of-data-semantic- web-wtf/

Linked data refers to data published on the web in such a way that it is machine-readable, its meaning is explicitly defined, it is linked to other external datasets, and can in turn be linked to from external datasets.

Linked data adheres to and builds on the core principles of the classic world wide web [BHBL09] to create aweb of data: The web of data can contain any kind of data, published by anyone, without being subject to vocabulary constraints. Entities are linked into a global data graph that spans data sources and enables the discovery of new sources.

Application developers enjoy the following benefits [BHBL09]: Data is clearly separated from presentational aspects. Data is also self-describing, because there is a standard way of looking up the definition of a URI, for machines and for humans. HTTP as a standard data access mechanism and RDF as a standard data format make linked data simpler than most web APIs which rely on heterogeneous data models and access interfaces. Finally, the web of data is open, meaning that applications need not work with a fixed set of data, but can be written to discover new data by following links. In the following, linked data’s core concepts are explained. Sect.24.3describes “Tabulator”, a linked data client program for end users.

3.2.1

Linking documents and data

The following concepts refer to the linking aspect of linked data.

The web of documents is “the web as we currently know it”: it is the equivalent of a global file system, designed for humans, its primary objects are documents, there are untyped links between documents, the content is relatively low on structure and semantics are implicit. Even though there is a lot of data on the web of documents, it is difficult to access, because it is typically unstructured and it does not adhere to a common standard.

The graph of linked things (the web of data) is the equivalent of a global database, designed for machines, primary objects are things, there are typed links between things, the content has a high amount of structure and explicit semantics. This is the core component of linked data, but the graph complements the web of documents, it does not replace it.

Dereferencing a URI is the process of looking up on the web a so-calledresource, information that is pointed to by a URI. The two main involved parties are the client making the request and the server answering it. During the request,content negotiation

takes place: The client tells the server what formats it prefers and the server can then create and deliver the appropriaterepresentationof the resource. For example, web browsers normally request HTML via the HTTP headerAccept: text/html, while linked data clients requesting RDF might sendAccept: application/ rdf+xml. The idea is that when humans looks up a resource, they usually want to read text and browse data, while machines are only interested in the raw data. Flexible servers react accordingly and generate the appropriate representation on the fly.

3.2 Core concepts 31

3.2.2

Information resources and non-information resources

URIs can represent two kinds of resources. Information resources are things (docu- ments, images, etc.) that actually exist on the web. During content negotiation, there are two ways of providing different representations: one can directly serve a repre- sentation or one can forward to an appropriate resource with the response code302 Found. That means in both cases that data has been found at the location of the URI.

Non-information resources such as abstract concepts and people do not actually exist on the web. To honor the semantics of this fact while still serving data, servers usually forward to a resource that contains related information with the response code 303 See Other. Alternatively, a non-information resource can have a URI with a fragment identifier such ashttp://example.com/file#fragment. Then the non-fragment part of the URI can be served and the URI with fragment retains its abstract status. The former method has the advantage of being more flexible, but it requires redirects. The latter method has to serve the complete parent resource every time one of its fragments is accessed. On the other hand, no redirects are required. Fragments work well for small stable vocabularies, while 303 redirects should be used for large evolving vocabularies [SC].

As an example, here are three URIs related to “Russia” [BCH07]:

1. http://www4.wiwiss.fu-berlin.de/factbook/resource/Russia

(URI identifying the non-information resource Russia)

2. http://www4.wiwiss.fu-berlin.de/factbook/data/Russia

(information resource with an RDF/XML representation describing Russia)

3. http://www4.wiwiss.fu-berlin.de/factbook/page/Russia

(information resource with an HTML representation describing Russia)

In this context, the following usage scenarios are conceivable: accessing the non- information resource (1) will 303 forward web browsers to (2) and RDF clients to (3). Accessing the HTML page (3) with a web browser will directly serve that page, while RDF clients will be 302 forwarded to (2).

To avoid the complexities of content negotiation, one can also serve HTML and RDF at the same time, by marking up an HTML page with RDFa (Sect.3.3.3). This allows humans to read the rendered HTML, while machines can extract the embedded RDF.

3.2.3

Berners-Lee’s four rules for linked data

Tim Berners-Lee [BLa] states four rules for linked data:

• Use URIs as names for things.URIs can denote anything, not just documents. • Use HTTP URIs so that people can look up those names. HTTP URIs have

the advantage of being globally unique with distributed ownership.

• When someone looks up a URI, provide useful information.What represen- tation (RDF, HTML, . . . ) of a URI is useful depends on who accesses it. Content negotiation is a clean solution for this problem.

• Include links to other URIs, so that they can discover more things.Note that this rule holds for both RDF and HTML. In both cases, linking is essential to the distributed nature of the web.

3.2.4

Datasets

In the linked data universe, adatasetis a graph of RDF data. It is often hosted in a single place and there are several possible ways of accessing it:

• As linked data. Granularity is the namespace for hash URIs and the resource for slash URIs. In the former case, one usually serves all statements whose subjects are part of the namespace. In the latter case, one usually serves all statements whose subject is the URI.

• Via SPARQL endpoints: web services where one sends SPARQL queries and receives query results, see Sect.3.4.4.

• As a data dump, a complete files with all of the data.

• ViaURI lookup, as defined by the voiD specification (Sect.3.3.2): one URL- encodes a resource URIR, appends it to aURI lookup endpoint, and downloads the resulting URI which is expected to contain an RDF description ofR.

3.3

Discovery

This section describes techniques to make a dataset easy to discover, given either an HTML web page, a web server, or another data set. Fig.3.1provides an overview.

dataset URI

dataset dataset URI

dataset

robots.txt (one per server)

sitemap2.xml sitemap1.xml semantic extensions vocabulary of interlinked datasets HTML <link> tag HTML RDF RDFa

Figure 3.1: Datasets can be discovered by following the per-serverrobots.txtto semantic sitemaps. HTML files can refer to related RDF datasets, if those are stored in files. The RDFa standard allows one to embed related RDF data inside HTML. The RDF vocabulary of interlinked datasets is used to provide further meta data.

3.3 Discovery 33

3.3.1

Semantic sitemaps

Classic sitemaps are XML files that are declared in the per-domainrobots.txtfile.

Semantic sitemaps[CSD+08] extend this format to allow one to describe datasets: • datasetLabel: a human description of the dataset.

• datasetURI: points to a URI in the dataset that contains more information about the dataset. This information can be expressed in the voiD vocabulary (Sect.3.3.2). • linkedDataPrefix: describes how the resources in the dataset are served as linked

data. URIs that begin with this prefix must resolve to RDF descriptions. What exactly such a description entails can also be specified (statements whose subject the URI is, statements whose subject or object the URI is, etc.).

• sparqlEndpoint: where can SPARQL be used to query the dataset? • dataDump: where can a dump of the dataset be downloaded? • changefreq: how frequently does the data change?

• sparqlGraphName: what is the graph URI of the dataset inside the SPARQL endpoint?

• sampleURI: provides starting points for human exploration of the dataset. • authority: normally, the only way to get information about who is responsible for

a web site is via the DNS records, which are external to the site. By specifying a URI for an authority, this kind of information can be served via linked data principles.

Having this kind of information solves the following problems:

• Crawling performance and exhaustive data enumeration: crawling linked data can be expensive, because each resource might be served separately and there is no definitive way of retrieving all of the dataset. By associating a linked data prefix with a data dump, this can be fixed.

• Scattered RDF files: instead of having to crawl a complete site to find RDF data, crawlers simply look up the site map.

• Cataloging SPARQL endpoints: semantic sitemaps provide a standard way of discovering SPARQL endpoints.

• Discovering a SPARQL endpoint for a given resource: is especially interesting for linked data, because it allows one to go from looking up a resource to making sophisticated queries about it. Sitemaps allow this by associating linked data prefixes with SPARQL endpoints.

• Closed-world queries about self-contained data: Usually, RDF’s open world as- sumption makes queries such as “Does Example Inc. have an employee named Eric?” impossible. By delineating datasets, one can temporarily assume a closed world. If a query fails to produce results, the dataset label can be used to report the failure.

3.3.2

Vocabulary of Interlinked Datasets (voiD)

TheVocabulary of Interlinked Datasets(voiD, [ACHZ]) extends semantic sitemaps by providing a detailed RDF vocabulary for describing datasets and how different datasets are linked.

Describing datasets

The vocabulary for datasets comprises the typevoid:Datasetfor datasets and lets one specify the following data:

• About the dataset: title, description, home page.

• Who created it: creator (main author), publisher, contributor.

• URIs in the dataset: example resources (as entry points) and a regular expression that matches one or more URIs in the dataset.

• Dates: date of creation, issuance, modification.

• Describing the content: URIs tag a dataset with categories (such as “computer science” or “biology”), a URL points to the license under which the dataset has been published.

• Composition of the content: one can specify a source from which the current dataset has been derived, sub-datasets which are combined to form the whole dataset, and the vocabularies used in the dataset.

• Access methods: one can declare SPARQL endpoints, URI lookup and data dumps.

Describing links between datasets

dataset dataset

linkset

Figure 3.2: A linkset is a dataset that connects two datasets.

A linksetis a dataset that contains links between two datasets (Fig.3.2). These links can declare a URI from one dataset to be equivalent to a URI from the other dataset. Or they can otherwise relate URIs (who knows whom, who lives where, etc.). voiD distinguishes two kinds of linksets: “classic linked data” means that one of the involved datasets contains the links, “3rd-party” means that the linkset is external to the datasets. The description of the links can specify a direction or be undirected. The following URIs are available:

3.3 Discovery 35

• void:subset(read as “has subset”) declares that one dataset is a superset of another one. In particular, it can be used to declare that one of the datasets contains the linkset (which is also a dataset), as is the case in the “classic linked data” scenario.

• void:linkPredicatestates one predicate that is used for linking the datasets. • void:targetto declare the involved datasets in the undirected case.

• void:subjectsTarget,void:objectsTarget to describe the direc- tion of the links between the datasets.

The following example (taken from [ACHZ]) describes a linkset connecting the Ja- mendo and Geonames datasets. The former describes a collection of Creative Com- mons licensed songs, including the artists that performed them. The latter is an on- tology of places (continents, countries, cities, etc.). The linkset is contained in the Jamendo vocabulary (classic linked data). The links are directed from Jamendo to Geonames and have the predicatefoaf:based_near. Such links can be used to express where, for example, bands are located.

:Jamendo void:subset :Jamendo2Geonames .

:Jamendo2Geonames a void:Linkset ;

void:linkPredicate foaf:based_near ; void:subjectsTarget :Jamendo ;

void:objectsTarget :Geonames .

Discovering voiD descriptions

Usually, one uses the dataset URI specified in a semantic sitemap to look for linksets whose target is that URI. Should the dataset be spread across several documents, each of those documents can usedcterms:isPartOfto refer to the main dataset URI with the voiD description:

<document.rdf> dcterms:isPartOf <void.ttl#MyDataset>

3.3.3

Associating RDF data with HTML files

To associate an HTML file with related RDF data, one can either refer to an RDF file via an HTML tag or embed the RDF inside the HTML. There are two reasons for performing such an association. First, the RDF can be meta-data, describe what the page is about, its intended audience, topics covered, etc. Second, it can be a more precise version of the data displayed on the web page, given that many web pages display structured data (such as contacts and events) as unstructured text. Obviously, translating that unstructured text to structured data for further processing is a non-trivial task.

Linking from HTML to RDF.

<link>tags allow one to tell browsers about content that is related to the current HTML document. This is already frequently used for RSS feeds: If a feed version of the current pages is available, it is linked to in HTML and a status icon indicating the

additional content shows up in the web browser. In a similar fashion, one can link to RDF data by including the following tag in the header:

<link rel="alternate" type="application/rdf+xml" title="RDF Version" href="mydoc.rdf">

RDFa: Embedding RDF inside HTML

Many web pages are produced by translating a database to HTML. Alas, this process is not reversible: Even though there are many lists of contacts or dates available on the web, one cannot easily import this data into address books and calendars and usually ends up entering it manually. Help comes in the form of an (X)HTML extension called

RDFa[AB06]. It defines a small set of attributes that remain hidden inside the HTML, but their values allow one to extract the RDF triples that were used to generate the HTML in the first place.

In the following example (which is taken from [Wikb]), relatively free text is marked up with RDFa:

<p xmlns:dc="http://purl.org/dc/elements/1.1/" about="http://www.example.com/books/wikinomics"> In his latest book

<em property="dc:title">Wikinomics</em>, <span property="dc:author">Don Tapscott</span> explains deep changes in technology,

demographics and business.

The book is due to be published in <span property="dcterms:date"

content="2006-10-01">October 2006</span>. </p>

All RDFa-specific parts are underlined: we initially define the namespace prefixdc2 for the URI http://purl.org/dc/elements/1.1/. Then we say that the paragraph isaboutthe resourcehttp://www.example.com/books/wikinomics, meaning that the properties we are about to define should be attached to it. Then we define thedc:titleanddc:authorof that book. For the date, we use an RDFa mechanism that lets us displayOctober 2006to the user, but store2006-10-01 in RDF. Note that even though we discard the former, it is still semantically marked up as the value of propertydcterms:date. Thus, the following three triples have been embedded in the HTML fragment and can be easily extracted:

http://www.example.com/books/wikinomics dc:title "Wikinomics" ;

dc:author "Don Tapscott" ; dcterms:date "2006-10-01" .

There are tools such asbookmarklets[rdf] available with which it is easy to extract the RDF from RDFa-enriched web sites. All HTML generated via Fresnel lenses in HYENAhas RDFa in it.

RDFa is similar tomicroformats[sit]. Microformats introduce a new set of HTML attributes and CSS classes for each kind of data. Examples include People and Or- ganizations; Calendars and Events; Opinions, Ratings and Reviews; Licenses; Tags, 2dcstands for the standard RDF vocabularyDublin Corewhich defines predicates for author information

3.4 Write-enabling linked data 37

Keywords, Categories; Lists and Outlines. In contrast, RDFa relies on the universal- ity of RDF and just needs a new RDF type. On the other hand, microformats do not require one to handle RDF and are already broadly supported via browser plugins.

Google has recently begun using RDFa to improve search efficiency. Google sup- ports what they call “rich snippets”3 to improve how a web page is displayed in the