Provided by the author(s) and NUI Galway in accordance with publisher policies. Please cite the published version when available. Title Linked Data and the Semantic Web Standards Author(s) Hogan, Aidan Publication 2013 Date Aidan Hogan (2013) 'Linked Data and the Semantic Web Publication Standards' In: Linked Data and the Semantic Web Standards. Information na : Chapman and Hall / CRC Press. Publisher Chapman and Hall / CRC Press Link to publisher's http://www.crcpress.com/product/isbn/9781466582408 version Item record http://hdl.handle.net/10379/4386 Downloaded 2019-04-10T09:05:31Z Some rights reserved. For more information, please see the item record link above. Chapter 1 Linked Data & the Semantic Web Standards Aidan Hogan Digital Enterprise Research Institute, National Univerity of Ireland, Galway 1.1 Introduction ............................................................... 3 1.2 Semantic Web ............................................................. 6 1.3 Resource Description Framework (RDF) ................................. 10 1.3.1 RDF Terms ........................................................ 11 1.3.2 RDF Triples and Graphs .......................................... 12 1.3.3 RDF Vocabulary .................................................. 16 1.3.4 RDF Syntaxes ..................................................... 19 1.4 RDF Semantics, Schemata and Ontologies ............................... 20 1.4.1 RDF Semantics .................................................... 20 1.4.2 RDF Schema (RDFS) ............................................. 23 1.4.3 Web Ontology Language (OWL) ................................. 25 1.5 Querying RDF with SPARQL ............................................ 31 1.5.1 Query Types ...................................................... 33 1.5.2 Dataset Clause and Named Graphs ............................... 34 1.5.3 Query Clause ...................................................... 35 1.5.4 Solution Modifiers ................................................. 39 1.5.5 Towards SPARQL 1.1 ............................................. 40 1.6 Linked Data ............................................................... 41 1.6.1 The Early Semantic Web on the Web ............................ 42 1.6.2 Linked Data Principles and Best Practices ....................... 43 1.6.3 Linking Open Data ................................................ 44 Chapter Acknowledgements: .................................... 47 1.1 Introduction On the traditional World Wide Web we all know and love, machines are used as brokers of content: they store, organize, request, route, transmit, re- ceive and display content encapsulated as documents. In order for machines to process the content of documents automatically—for whatever purpose— they primarily require two things: machine-readable structure and semantics. Unfortunately,despitevariousadvancementsintheareaofNaturalLanguage Processing(NLP)downthroughthedecades,moderncomputersstillstruggle to meaningfully process the idiosyncratic structure and semantics of natural language due to ambiguities present in grammar, coreference and word-sense. 3 4 Linked Data Management: Principles and Techniques Hence, machines require a more “formal” notion of structure and semantics using unambiguous grammar, referencing and vocabulary. As such, various standards (both de facto and de jure) have emerged to partially structure the Web’s content using agreed-upon formal syntaxes and data-models. The current structure of the Web’s content is predom- inantly based around the idea of markup whereby the different elemental parts of the content in a document are delimited by use of syntactic con- ventions, including matching start tags and end tags (e.g., <title>Title of Document</title>), nested elements, attributes, and so forth. The eXtensi- ble Markup Language (XML) provides a generic standard for markup-style languages, allowing machines to parse XML content into a data model con- sisting of an ordered tree of typed strings. Other non-markup-based methods forstructuringcontenthavealsobecomecommon.Forexample,CommaSep- arated Values (CSV) provides a simple syntax that allows machines to parse contentintotabular(orevenrelational)data-structures.Recently,JavaScript Object Notation (JSON) has seen growth in adoption, providing syntax to represent content that can be parsed into nested complex objects and asso- ciative arrays. However,asfarasamachineisconcerned,havingformallystructuredcon- tent is only half the battle. Without some semantics (aka. meaning) for at least some parts of the content, machines would not be able to do much more than split the content up by its delimiters and load its structure. Much of the semantics that powers the current Web is based on consensus collected in standards(e.g.,RFCs,W3C,etc.)forsoftwaredevelopersandcontentcreators to read and follow. The HyperText Markup Language (HTML) standard is perhaps the most prominent such example, providing a markup-based vocab- ulary that allows to state how a document should be rendered in a browser; for example, the <title> tag is used by publishers to denote the title of the document, which will then be predictably displayed by a Web browser in its top tool-bar (or tab-bar). The agreed-upon semantics for the HTML vocabu- lary of tags and elements, then, lie in the annotation of a HTML document for consistent rendering purposes. Other markup-based specifications on the Web (such as Rich Site Summary (RSS)) promote an agreed-upon meaning for a set of terms that fulfill the needs of specific other applications (in the case of RSS, providing details of site updates to a feed reader). Importantly,foragreed-uponvocabulariessuchasHTMLorRSS,theaddi- tion(orrenaming/removal)oftermsfromthevocabularyrequiresanewstan- dard,andeventuallynewapplicationstointerpretthenewtermsaccordingly: the semantics of relevant terms are enumerated in human-readable documen- tation and hard-coded in (often imperative) programs. Although standards suchasXMLSchema(XSD)canbeusedtoassignsomemachine-readablese- manticstoXMLcontent—suchaswhatarethelegaland/orrequiredchildren of an element or attribute (e.g., an element employee should have a staffID attribute), or simple typing of elements and text values—such semantics are limitedtodefiningconstraintsthatdefinethenotionofa“validdocument”for Linked Data & the Semantic Web Standards 5 some purpose, or for parsing datatypes such as integers, booleans and dates. In other words, XSD is more concerned with machine validation rather than machinereadability.Furthermore,termsoftenserveasingularpurposewithin the context of a given application or a given schema: as an example, there is a <title> tag in both HTML and RSS, but how they should be interpreted differs significantly for the respective consumer applications. So where does this leave the Web? Considerabunchofcookingenthusiastswhowanttostartsharingpersonal recipes with each other over the Web. Each participant will want to search over all recipes to find things like: “citrus-free desserts” or “winter soups made from root vegetables” or “wine-based gravy for beef” or “barbeque” and so forth. Some of the enthusiasts create a new site and invite users to enter recipes in structured (HTML) forms, allowing to state what ingredients are needed,inwhatquantitiesandunits,whatstepsarerequiredforpreparation, and in what order. The recipes are stored in inverted keyword indexes and structuredrelationaldatabasestoallowforsearchingandqueryingoverlater. Asthesite’scontentgrows,atag-basedsystemiscreatedtoallowuserstofill incommonlysearchedtermsnotmentionedintherecipetext,likebbq,gravy, vegan and so forth. Users can comment on recipes to give their experience and ratings. After all of the hard work, the users of the site are quite happy with thefunctionality.Userscansearchforcontentbykeyword,byrating,orusing facetedbrowsingovertheingredientsofdifferentrecipes.However,someusers still find it difficult to find the recipe they want. For example, Sally is allergic to citrus and although tags exist for common allergies, there are no tags for citrus. Thus, Sally has to go through each individual dessert recipe to ensure that the ingredient list does not contain lemons, oranges, limes, grapefruit, tangerines and other agrumes, or processed ingredients that themselves con- tainagrumes.Anotheruser,Fred,hashiseyeonarecipeforBlackrisottoafter enjoying it on holiday. Preferably, the recipe uses fresh cuttlefish, but if that is not available, whole squid can be used instead. Both of these are obscure ingredients and Fred is unsure where to find either of them in his local area. He searches through a variety of online shopping sites for local supermarkets and eventually finds fresh squid but is still unsure whether or not cuttlefish is available close-by. Later, the maintainers of the cooking site decide to merge with another site that contains recipes for cocktails. There is much overlap between both sites in terms of the structure of input forms, ingredients used, preparation details, tags, and so forth. The maintainers of both sites decide to extend the cooking site and prepare a site-dump of the cocktail site to integrate with the cooking database. However, aside from all of the manual effort required in manually mapping and restructuring the content of the cocktail corpus, there are further alignment problems. Recipes on the cooking site are expected to have a preparation time, which is missing from the cocktail site; the cocktail site has alternative names for some ingredients, such as “cantaloupe” instead 6 Linked Data Management: Principles and Techniques of “melon”; the cocktail recipes have no tags; and so forth. The maintainers eventually have to heavily adapt their database design to accomodate the incoming data, and hack together some imperative scripts to align terms and to seed common tags for cocktails like non-alcoholic, vegan, etc., based on ingredient lists, extending them manually. Although this example admittedly takes some liberties, it serves to illus- trate some of the shortcomings of the current Web. The advent of Web 2.0 technologies has blurred the line between users and publishers: the Web now containsalotofuser-generatedcontent,beitprimarycontentsuchasrecipes, or secondary content in the form of comments, ratings, lists, tags, etc. How- ever, content is heavily fragmented across different sites—even where there is a high degree of overlap across that content—with only a coarse layer of hyperlinks bridging individual sites. Content is often created in the context of a given site for the functionality of that site: though content may often be of general interest, it is often created with a singular purpose (e.g., manually taggingrecipescontaininglemonswithcitrus).Asaresult,contentbecomes locked into a site, due to some combination of licensing or technical issues, or simply because the content is not stated in a reusable way. Because so much of the content on the Web is not directly reusable, there are then high levels of redundancy in the manual creation of factual content across different sites (e.g., tagging lemon cocktails again with citrus). Similarly, content gained through one site cannot be used to automatically interact with another site (such as to search nearby shops for ingredients of recipes). Andso,inanefforttoaddresstheseshortcomings,theprimarygoalofthe “SemanticWeb”istomakemoreoftheWeb’scontentavailableinamachine- readable format such that it can be reused for (m)any purpose(s), such that itcanbeautomaticallycombinedandintegratedwithothermachine-readable content, and such that machines can (to some known extent) interpret and automatically act upon that content. For this envisaged Semantic Web, you wouldonlyneedtosaythat“all lemons are citrus fruits”once:solongasyou said it the right way—on the Web, using an globally agreed-upon identifier for lemon, described using an agreed-upon data-model, formalizing the claim using an agreed-upon vocabulary with well-defined meaning—the machines could do the rest. ThischaptercontinuesbyfirstoutliningtheoriginalvisionoftheSemantic Web and the core components and technologies deemed necessary to make it a reality. Thereafter, we discuss the various core Semantic Web languages that have been standardized in recent years and that comprise the heart of the modern Semantic Web. Finally, we discuss Linked Data: a set of best- practicesonhowtoidentifySemanticWebresourcesandhowtoorganizeand interlinkSemanticWebdatapublishedinadecentralizedmannerontheWeb. Linked Data & the Semantic Web Standards 7 Trust Proof Unifying Logic C Querying & Rules Schema & Ontologies ry p (SPARQL& RIF) (RDFS & OWL) to g r a Data Model(RDF) ph y Syntax(XML/Turtle/XHTML/JSON) Identifiers(URI/IRI) Characters(Unicode) FIGURE 1.1: Semantic Web Stack (aka. Semantic Web Layer Cake) 1.2 Semantic Web On a high-level, the Semantic Web can be conceptualized as an extension of the current Web so as to enable the creation, sharing and intelligent re-use of (deeply) machine-readable content on the Web. This idea of the Semantic WebisalmostasoldastheWebitself,andtheroots oftheSemanticWebare, of course, much older than the Web. However, two major milestones for the inception of the modern notion of the Semantic Web were the original W3C recommendationofthefirstResourceDescriptionFramework(RDF)standard in February 1999 [39] outlining the core data model (described in detail later inSection1.3),andthe2001publicationofBerners-Leeetal.’sseminalpaper where the authors outlined their vision for the Semantic Web [9]. Traditionally,thetechnicalblue-printsforbuildingtheSemanticWebfrom thegrounduphaveoftenbeenrepresentedthroughvariousincarnationsofthe high-level“SemanticWebStack”(aka.“SemanticWebLayerCake”)originally conceived by Berners-Lee; yet another such incarnation is illustrated in Fig- ure 1.1. Each layer of the stack represents a technical “piece of the puzzle” needed to realize the vision of the Semantic Web. Some parts of the puzzle alreadyexistandcanbere-used.However,muchofthestacknecessarilyneeds novel techniques; these parts are italicized in Figure 1.1. ThelowerlevelsofthestackrelatetofoundationalelementsoftheSeman- tic Web that are in-common with the Web itself: Characters: Like the current Web and various other software applications, the Semantic Web requires some standard to map from binary streams 8 Linked Data Management: Principles and Techniques andstoragetotextualinformation.Forthis,theSemanticWebrelieson the standard Unicode character-set. Identifiers: If the Semantic Web is about describing things—be they concep- tual or concrete—in a machine-readable manner, these things will need globallyagreed-uponidentifiers.Thenaturalchoiceforidentifiersisthus to use the Uniform Resource Identifier (URI) specification, which is al- readyusedontheWebtoidentifydocuments(ormoreaccurately,repre- sentations). Newer Semantic Web standards have also started to adopt the Internationalized Resource Identifier (IRI) specification: a general- ization of URIs to support the broader Unicode standard. Syntax: Toallowmachinestoautomaticallyparsecontentintoitselementary constituents, the Semantic Web requires syntaxes with formally defined grammars. For this, existing generic syntaxes such as XML and JSON canbeused.Thoughtheuseofexistingsyntaxesallowsforusinglegacy tools, custom syntaxes have also been created to encode Semantic Web data using terse and intuitive grammars; these novel syntaxes are all a derivative of the Terse RDF Triple Language (Turtle) syntax.1 Above the Syntax layer lies the beating heart of the Semantic Web: Data Model: In order for machines to exchange machine-readable data in a generic fashion, they need to agree upon a common data-model under whichtostructurecontent.Thisdata-modelshouldbegenericenoughto provideacanonicalrepresentation(withoutidiosyncrasies)forarbitrary content irrespective of its domain or nature or syntax, and to enable processing this content using standard off-the-shelf technologies. The coredata-modelelectedforuseontheSemanticWebisRDF,whichcan be serialized using one or more of the aforementioned syntaxes. Schema & Ontologies: While the RDF data-model brings a universal struc- ture to content, it does not bring (much) semantics or meaning to con- tent. Thus, the Semantic Web requires formal languages with which to make claims about things described in RDF content. These formal lan- guages offer a meta-vocabulary with well-defined semantics that can be used in combination with the RDF data-model to define schemata and ontologies. The core languages offered as part of the current Semantic Web standards are the RDF Schema (RDFS) and Web Ontology Lan- guage (OWL) standards. Querying & Rules: Ultimately, content described in RDF needs to be pro- cessed by querying and rule-based systems that allow for specifying conjunctive conditions and query patterns. The results of conjunctive 1TurtleisitselfinspiredbyNotation3(N3).However,N3goesbeyondRDFandshould notbeconsideredanRDFsyntax.TurtlecanbelooselyspeakingtheintersectionofRDF andN3. Linked Data & the Semantic Web Standards 9 queriesandrulescanbeusedtoextractpertinentelementsofRDFcon- tent, to generate results for a user interface, to infer novel RDF data based on premises formed by existing content, to specify constraints that an RDF dataset should conform to, or to define triggers that per- form actions when the RDF data meets certain conditions. The current querying standard for the Semantic Web is the SPARQL Protocol and RDFQueryLanguage(SPARQL),whichprovidesamature,feature-rich query language for RDF content. The current standard for rules on the Semantic Web is the Rule Interchange Format (RIF), which captures the expressivity of various existing rule-based languages and offers a powerful library of built-in functions. This chapter will primarily focus on the layers and standards enumerated above. This book will primarily focus on the support for Querying in the context of the RDF Data Model layer. AtthetopandsideofthestackinFigure1.1areanumberoflayersdrawn with dashed lines. Although proposals to realize these layers have been made in the research literature, mature standards and tooling have yet to emerge. These are speculative areas of the Semantic Web, and that is reflected in the following discussion: Unifying Logic: Lower down in the stack lie the query languages, rule primi- tivesandontologicalstandardsthatarecompatiblewithRDFdataand that form the core of the Semantic Web stack. The envisaged goal of theUnifying Logiclayerisasaninteroperabilitylayerthatprovidesthe foundation for combining these lower-level technologies into a whole, with a unifying language to engage queries and rules over knowledge represented in RDF and associated ontologies/schemata. Various works in this area have looked at combining rules with querying [47, 48], com- biningontologicalinterpretationswithquerying[35,20],andcombining rules and ontologies [37, 32, 36]. Proof: Given that the Semantic Web would enable software agents to per- form various automated tasks over decentralized sources of structured information,possiblycombiningdatafrommultipleexternalsourcesand applyingvariousreasoningandqueryingprimitivestoachievesomegoal, it is important that the software agent provide some form of proof that can be used by the client to validate the procedure or information used to, e.g., complete the task or derive an answer. Trust: Related to the underlying Proof layer, the Trust layer would be re- quired by clients on the Semantic Web to determine which sources of information should be trusted in a proof, or by clients and servers as an access control mechanism to determine which service providers or other agents on the Web are allowed access to which data, and so forth. To achieve this, the Trust layer would not require an a priori whitelist 10 Linked Data Management: Principles and Techniques or blacklist of agents, but should rather be able to determine trust for agents it has not seen before based on attributes of that agent (e.g., based on a social network, being a governmental body, etc.). Cryptography: This layer lies to the side of the Semantic Web stack, indi- cating that although important, cryptography is somewhat tangential to the core Semantic Web technologies. Obviously, the Semantic Web wouldrequirecryptographictechniquesforverifyingidentityandforal- lowingaccesscontrolmechanisms,andsoforth.However,manyexisting cryptographytechnologiescouldbeborroweddirectlyfromtheWeb,in- cluding digital signatures, public-key encryption/decryption algorithms such as RSA, secure protocols such as HTTP Secure (HTTPS) that use TSL/SSL, and so forth. TheoriginalSemanticWebvision[9]isindeedanambitiousone.Through- out the years, various aspects of the stack have been tackled by a variety of researchgroups,developersandstandardizationbodies.However,muchofthe original vision remains unrealized. On a high-level, we see that lower parts of the Semantic Web stack borrow directly from existing Web technologies, middle parts of the stack have been realized through various standardization efforts, and higher parts of the stack remain largely unrealized. In general, however, the stack is best viewed in a descriptive manner, not a prescriptive manner: it is an illustration, not a specification. Manydevelopmentshavebeeninmadeinthepastfewyearsonthemiddle layers of the stack in terms of the RDF data-model and related standards builtontopforqueryingRDF,representingschemataandontologiesinRDF, and expressing rules that can be executed over RDF data. This book focuses largely on these middle layers, and the remainder of this chapter outlines the coreSemanticWebstandardsthathavebeenproposedintheseareas,starting with the RDF standard. 1.3 Resource Description Framework (RDF) The RDF standard [42] provides the basis for a core agreed-upon data- model on the Semantic Web. Having an agreed-upon data-model is crucial for the interoperability of data produced by different independent publishers across the Web, allowing for content represented in RDF to be generically processedandindexedbyoff-the-shelftoolsnomatterwhatitstopicororigin. Herein, we give a brief walkthrough of the design principles and the fea- tures of RDF. We do not cover all features, but rather focus on core concepts that are important for further reading of this book. Throughout, we will use Turtle’s syntactic conventions for representing RDF terms and RDF data. Linked Data & the Semantic Web Standards 11 These conventions will be introduced in an incremental fashion, but if unfa- miliar with the syntax, the reader may find it worthwhile to look through the examples in the W3C Working Draft for Turtle [5]. 1.3.1 RDF Terms The elemental constituents of the RDF data-model are RDF terms that can be used in reference to resources: anything with identity. The set of RDF termsisbrokendownintothreedisjointsub-sets:URIs (orIRIs),literals and blank nodes.2 URIs serveasglobal(Web-scope)identifiersthatcanbeusedtoidentifyany resource. For example, http://dbpedia.org/resource/Lemon is used to identify the lemon fruit (and plant) in DBpedia [12] (an online RDF database extracted from Wikipedia content). In Turtle, URIs are de- limited with angle-brackets: <http://dbpedia.org/resource/Lemon>. To avoid writing long and repetitive full URI strings, Turtle allows for the use of CURIE-style shortcuts [11] where a re-usable prefix can be defined: @prefix dbr: <http://dbpedia.org/resource/>. There- after, URIs can be abbreviated using prefix:localname shortcuts— e.g., dbr:Lemon—where the local-name is resolved against the in-scope prefix definition to generate the full URI form. Literals are a set of lexical values denoted with inverted commas in Turtle. Literals can be either: Plain Literals which form a set of plain strings, such as "Hello World", potentially with an associated language tag, such as such as "Hello World"@en. Typed Literals which comprise of a lexical string and a datatype, such as "2"^^xsd:int. Datatypes are identified by URIs (such as xsd:int), where RDF borrows many of the datatypes defined for XML Schema that cover numerics, booleans, dates, times, and so forth.Thesedatatypesdefinewhichlexicalformsarevalidforthat datatype (e.g., to state that "p"^^xsd:int is invalid), and ulti- matelyprovideamappingfromvalidlexicalstringstoavaluespace (e.g., from "2"^^xsd:int to the value of the number two). Turtle providesshortcutsforcommondatatypes,wheretheuseofnumbers andbooleanvalueswithoutquotes—e.g.,2,2.4,false—indicatea correspondingdatatypeliteral.Plainliteralswithoutlanguagetags map to the same value as lexically identical xsd:string values. 2Although support for IRIs is featured in more recent RDF-based standards, to avoid confusion, we henceforth stick with the notion of URIs in our discussion and definitions. ThedistinctionbetweenURIsandIRIsisnotimportanttothediscoursepresented.