Deploying Linked Data v1.2 (Virtuoso 5.0) April 2008 This document describes the process of deploying Linked Data into the existing Web. It discusses some of the difficulties faced in exposing RDF data and in bridging the "Semantic Data-Web" and the traditional "Document Web". Two generic approaches to resolving these deployment challenges are described, content negotiation and URL rewriting, before looking at OpenLink Virtuoso, both from the standpoint of how it implements these solutions and how Linked Data is deployed. A companion document, Virtuoso Linked Data Views Getting Started Guide, focuses on Virtuoso Linked Data Views, a facility for exposing relational data as RDF. In addition, it provides useful background information for readers unfamiliar with RDF and outlines some of the key technologies of the Semantic Web. Introduction The ubiquitous "Web," born as the "World Wide Web," is primarily experienced today as a "Web of Documents," where documents (or Web pages) are connected by simple hypertext links. When you click on a hypertext link within one document, the result is simply that the browser loads (or downloads) the linked document. This widely understood and accepted pattern of interaction with the Web is made possible by two things — the Uniform Resource Identifier, or URI, and the Hypertext Transfer Protocol, or HTTP. (Uniform Resource Identifier? URI? Don't we mean URL, or Uniform Resource Locator? Yes and no. A Uniform Resource Locator (URL) is a particular kind of Uniform Resource Identifier; a Uniform Resource Name, or URN, is another. As may be obvious from these names, a URL specifies the location of a resource -- like, "the piece of paper centered on the blotter on your desk," or "the third book from the left on the top shelf of the bookcase in the entryway." A URN specifies the name of a resource -- like "your resume," or "the local Chicago telephone directory." Both of these are URIs -- as both can be used to identify the resource in question, at a given moment in time. The piece of paper centered on the blotter on your desk, and where the book is shelved, may change -- and though the URL is the same as what once referred to your resume, the URN is now different, as it is now "the menu for the pizza place down the street," or "the Tom Robbins novel, Still Life With Woodpecker." On the Web, URLs can only lead to HTTP-transmissible documents, so the paper on which your resume is printed cannot actually have a URL -- but the word processing document which was printed on that paper can have a URL. In this example, both the word processing document and the printout are associated with the URN, "your resume," and each is a different representation thereof -- one which is only easily consumable by humans, and one which is easily consumable by humans or machines. URNs are typically less transient, as "your resume" will always mean the same document, but that document's content will change over time -- so increasingly common practice is to have URNs that incorporate some sense of time into the name, often leading to two "special" URNs which are tied to the "first" and the "latest" version of the document. The "first" always leads to the same content -- but the "latest" is obviously likely to change over time.) The popularity of the current "Document Web" sometimes obscures the fact that from the onset, Tim Berners-Lee envisaged a broader and deeper Web of Linked Data, where URIs weren't simply URLs and therefor limited to association with HTTP-transmissible documents, and where links between resources were not limited to simple hypertext. URNs make it possible to have "hyperdata" links — explicit connections between Named Entities or Data Objects, rather than vague connections between document locations. Hyperdata links include descriptions of the kind of link exposed — such as "the PDF representation of your resume," "the Microsoft Word representation of your resume," "the website of the company at which you worked in 1998 which was named Widgets, Inc." There is no natural requirement that URNs be based on HTTP, but as we discuss below this is necessary to enabling the Web of Linked Data. This document describes one way to start sprinkling Linked Data into the existing Document Web, gradually bringing the Web closer to Tim Berners-Lee's vision, without breaking its current functionality. What is Linked Data? "Linked Data" is the title of a Web Design Issues Note by Berners-Lee that issues a best practice recipe for injecting data into the Web as part of a broader effort to evolve the current Web of interlinked documents to a Web of interlinked data known as the "Semantic Data-Web" (Data-Web). The principles he outlined are paraphrased as: Identify things (real or abstract) in your universe-of-discourse (or "data space") using URIs (whether URNs or URLs — each has its place) Make each URI (URN, URL, or otherwise) acessible via HTTP, so that people can discover and explore your data spaces via the Web Use URIs to expose the context of your data (i.e., describe and provide other information about your data, using URIs) Enhance your URIs by adding links to other URIs, enabling discovery of other things on the Web Deployment Challenges The Data-Web and the Document Web are two dimensions of the same Web separated by a common element: the URI. On the Document Web, URIs always point to physical resources, while in the Data-Web they point to physical things that are associated with physical and/or abstract things. Of course, this unveils a number of deployment challenges. Data Object Names In the current Document Web, resource URIs do not separate identity from representation. The Document Web assumes that a resource URI points to the location of a physical Web information resource. The HTTP payload that conveys the "GET" request for a resource also includes a mechanism for defining representation. Thus, the URI http://demo.openlinksw.com/Northwind/Customer/ALFKI points to the (X)HTML document representation of the physical resource ALFKI located in the directory /Northwind/Customer/ on host machine demo.openlinksw.com that accepts HTTP requests at the default port 80. The Data-web on the other hand, seeks to use the URI scheme in a manner that separates identity from representation. A URI may simply identify a physical or abstract entity, aka a "data object", and so serve as a unique data object name or ID. Accessing, or de-referencing, the data object returns a representation of the object, not the object itself. (For instance, the object in question may be Paris!) Unambiguous Reference vs Ambiguous Access When we refer to, or identify, a data object through a data object name, that reference should be unambiguous. However, when we access (or de-reference) a data object, access is inherently ambiguous. Accessing an abstract data object relies on materialization of a description of the entity in a form compatible with the transmission medium. As the object may have many possible descriptions (facets), the act of accessing it is ambiguous. URIs As Unique Data Object Names Thus, unlike in the Document Web, in the Semantic Web the same URI http://demo.openlinksw.com/Northwind/Customer/ALFKI cannot serve as both the identity and representation of the Customer ALFKI. The Linked Data provider needs to adhere to a URI based naming convention in order to avoid data access ambiguity. For example, the URI http://demo.openlinksw.com/Northwind/Customer/ALFKI#this, could always to taken to imply the ID of the Customer data object referred to as ?ALFKI?. The URI with the #this suffix is a so-called hash URI, which is a convention adopted by some practitioners. Difficulties with Hash URIs As Data Object Names In the prior section, we established the need for disambiguating references and accesses to resources via the Data-Web, and highlighted the hash URI scheme as one scheme some practitioners have adopted when using URIs as unique data object names. However from the perspective of the Data-Web Server (the piece responsible for understanding Reference), the URIs http://demo.openlinksw.com/Northwind/Customer/ALFKI and http://demo.openlinksw.com/Northwind/Customer/ALFKI#this are identical, and thereby inherently ambiguous, because nothing following the fragment identifier, "#", ever leaves the Web Client, due to the fact that the Web Client expects to process "#this" locally, post resource retrieval. As a result, the Data-Web Server has to figure out how to dereference the Information Resource URI http://demo.openlinksw.com/Northwind/Customer/ALFKI and the Identity URI http://demo.openlinksw.com/Northwind/Customer/ALFKI#this from the HTTP GET request payload that will only predictably contain the URI http://demo.openlinksw.com/Northwind/Customer/ALFKI. (Even if a Web client knowingly tacks the data following the "#" to the HTTP GET request it has no control over proxies along the way that may strip out "#this".) Likewise, referencing an entity via its identity URI (the act of dereferencing) is only achieved via interaction with an associated Web information resource that "DESCRIBE" the entities in question. In reality, this associative process is inherently ambiguous and unavoidable. It is also important to note that descriptive Web information resources can take the form of bona fide parameterized URLs of the kind commonly associated with RESTful Web Services. Resolution of the Deployment Challenge To unobtrusively evolve the dominant Document Web usage pattern to a Data-Web usage pattern, the challenges of Data Access and Data Reference need to be resolved using the existing Web infrastructure. The best means of resolution is content negotiation as it provides the foundation for an unobtrusive mechanism known as URL rewriting. Content Negotiation Content negotiation is a mechanism defined in the HTTP specification that makes it possible to serve different representations of a document (or any resource) at the same (Note 1) URL, so that software agents can choose which representation best fits their capabilities. The originally conceived need for this mechanism stemmed from mobile phone browsers, which were better suited to smaller page sizes, without many graphics and other niceties of the fully featured Web, often satisfied by a WAP representation. In the world of RDF, a user interacting through a traditional Web browser may want a resource represented in HTML or XHTML, whereas a Semantic Web application would prefer an RDF/XML representation due to its Structured Data orientation. A browser or any other HTTP based web application indicates it resource representation preferences by packaging these preferences via the "Accept:" headers of each HTTP request. For example, a browser could send this HTTP request to indicate that it wants an HTML or XHTML version of http://www.openlinksw.com/whitepapers/data_management in English or French: GET /whitepapers/data_management HTTP/1.1 Host: www.openlinksw.com Accept: text/html, application/xhtml+xml Accept-Language: en, fr Here, the HTTP Accept header sent by the browser indicates the MIME types it wants (text/html or application/xhtml+xml). An RDF browser, in contrast, might stipulate a MIME type of application/rdf+xml or application/rdf+n3 to receive a rendering in RDF/XML or N3 respectively. Rather than returning the content in the required format directly, servers often implement content negotiation by redirecting to a URL where the appropriate representation is found. For example, a server might respond with: HTTP/1.1 302 Found Location: http://www.openlinksw.com/whitepapers/data_management.en.html The redirect is indicated by the HTTP status code 302 (Found). The client would then send another HTTP request to the new URL. HTTP defines a number of 3xx status codes all of which indicate the client is being redirected. Instead of 302, servers can also use 303 (See Other) to indicate the response to the request can be found at another location (as expressed via the "Location:" response header). HttpRange - 14 Recommendations The problem of URI/resource-type interpretation was originally addressed by the W3C Technical Architecture Group (TAG) around 2005 and was known as the "HttpRange-14" issue. After a good deal of deliberation, the TAG proposed the guidelines below on the information that can be inferred from the HTTP protocol response codes when dereferencing a URI: