SPARQL (2)

So far, the previous sections presented more or less ways to describe data and their structure via RDF and ontology languages built on it (ie RDFS & OWL). This part now focuses on the available mechanisms to query these data, or the ontologies and knowledge bases described by these languages.

The Sparql Protocol and RDF Query Language is such a mechanism and in fact a complete, standardized solution to perform the following:

• Query OWL & RDFS as plain RDF.
• Query RDF datasets & their RDF graphs.
• Realize complex joins across databases.
• Explore data by querying known & unknown relationships.

As a query language, SPARQL provides the means to identify triple subsets and extract information as URIs, literals, blank nodes and subgraphs. Although it is based on SQL, it differs in that it matches patterns in graphs, rather than in related databases.

It was standardized in 2008 by W3C and has currently made its next evolutional step in the form of SPARQL 1.1. This current version extends the previous language features and abilities so as to resolve open issues of its predecessor. Among others it adds an update language, clarifies the relationship between queries, provides a vocabulary for describing SPARQL endpoints and offers several new features. Depending on the version, SPARQL is currently supported by almost all known RDF triple stores, most of which also offer associating endpoints where queries may be sent, evaluated and in turn return their results via HTTP.

In general, the use of SPARQL enables the following:

• Fulfills the 3^rd Linked Data principle & provides useful RDF information.
• Offers access towards datasets & their data.
• Enables a manual exploration of datasets & potential consumers to seek for URIs identifying resources of interest.
• Provides the means to identify triple subsets & match patterns in RDF graphs.

As a simple example & referring to the Hellenic Police dataset http://greek-lod.math.auth.gr/police/, such patterns become obvious in scenarios that attempt to identify the following:

• The 1st ten Crime Types of any Status, along with their Total number of crimes,
• Occurring at 05/2010 & under the supervision of ATTICA Police Headquarters.

A simple SPARQL query to retrieve that information with the associating results is shown in the figure below. Analyzing it, a SELECT statement initially defines the result set to be returned, (i.e. distinct values of variables: NAME, TOTAL_CRIMES, DATE, TypeofCrime & STATUS). In turn the WHERE clause defines the various graph patterns, (i.e. subject-predicate-object triples) to be matched in the RDF graph.

Hellenic Police SPARQL Query Sample with returned results

Graphically such a match pattern is represented by the “PATTERN TO MATCH” in the following figure below. The same figure also depicts part of the resulting Hellenic Police RDF graph and with green colour, two of the obtained triple subsets that matched the requested pattern. The latter are also visible in the first two records of the SPARQL results. Last but not least, another rejected triple subset is also highlighted with a red colour.

Identifying matching triple patterns from the Hellenic Police RDF graph

Ontologies & OWL(2)

An ontology, is a formal specification on how to model a domain’s knowledge in a way that the latter can be shared and reused. The term “specification” in this case also includes some representation vocabulary that establishes a common understanding about the domain’s structure of information, among different parties of interest.

Within the domain’s boundaries, such a vocabulary describes all meaningful entities (concepts) and includes information on their behavior (properties & relations) as well as any constraints, or rules on their use. In fact, there is also great need for languages, to construct ontologies, encode knowledge from specific domains and include reasoning to process the latter. As previously mentioned the first attempts based on RDF and RDFS highlighted the need for more expressive languages. As a result, a more focused approach to this requirement came with W3C’s recommendation of OWL.

The Web Ontology Language, or OWL enables greater machine interpretability, allows more precise descriptions, complex class expressions (Intersection, Union, Disjointness, etc) and special property definitions (inverse, symmetric, cardinality restrictions, etc). Another area worth mentioning, where OWL outperforms RDFS is that of built-in powerful properties, such as for instance “owl:sameAs”. The latter allows seemingly different non-information resources to be declared as representing the same thing.

To demonstrate such a point, owl:sameAs can be used to declare http://www.bbc.co.uk/music/artists/83d91898-7763-47d7-b03b-b92132375c47#artist as representing the same thing with http://www.freebase.com/view/en/pink_floyd. Furthermore, compared to RDFS, OWL exhibits additional abilities and offers more elegant solutions to deal with the same issues.

As an example, OWL allows a semantic equivalence declaration within a single RDF statement when at the same time RDFS requires two:

Semantic Equivalence via OWL:

xx:locatedIn               owl:equivalentProperty        yy:isAtLocation.

 

Semantic Equivalence via RDFS: 

xx:locatedIn                rdfs:subPropertyOf                 yy:isAtLocation.

yy:isAtLocation           rdfs:subPropertyOf                 xx:locatedIn.

To improve upon OWL as an ontology language, OWL2 came out as a revised version that would also provide a solid platform for future development. In brief, OWL 2 extends its predecessor with a new set of user requested features and improvements. Among other things, it overcomes certain limitations to model complex domains, introduces extended datatypes support, additional property constructors, simple meta-modeling and extended annotations.

RDFS

RDF Schema (RDFS) is yet another W3C specification that introduces the necessary basic elements to define lightweight ontologies. Among others, it allows RDF data to be annotated with semantic metadata, provides the means to describe groups of related resources and reveals the relationships among them. In particular, RDFS extends RDF by additionally allowing the definition of classes, properties as well as the combination of data that use different RDF encodings. Focusing on that last part, RDFS allows the use of data across different schemas without the need of their prior conversion to match a certain schema.

To illustrate this point, two sources of information about Aristotle University include semantically related concepts (uniquely named location properties) captured by different, local schemas. In particular, the “locatedIn” and “isAtLocation” properties associated with the University’s location. As shown below, RDFS allows the declaration of semantic equivalence among them and renders the need to make any property name changes unnecessary:

xx:locatedIn rdfs:subPropertyOf yy:isAtLocation.

yy:isAtLocation rdfs:subPropertyOf xx:locatedIn.

In that way, it is possible to perform queries on either dataset with a location property belonging to only one of them and still obtain the results from both datasets. Nevertheless, although in the right direction, RDFS exhibits limited expressiveness and not quite the rich semantics that are required. It was this fact that led to the creation of more complete ontology languages, to cater for all these issues and still ensure compatibility with XML or RDF.

RDF: The Divide & Conquer Approach

RDF stands for Resource Description Framework and besides being a simple, yet well defined standard it is currently also one of the essential building blocks of the Semantic Web. It was introduced in 1999 as a W3C Recommendation to cater for the descriptive needs of resources on the Web. Overall, it is a data model to represent and exchange information about the latter as well as enable the deduction of logical inferences from that information. To assist in that last part, RDF serves as the foundation for higher level languages, (e.g. RDFS & OWL) that define ontologies, encode knowledge from specific domains and include reasoning to process that knowledge.

As stated by its name, it is a common model or base, (Framework) on which to make statements, (Description) about resources and properties, (Resource) identified on the Web via URIs. The use of the latter ensures naming and consistency and is considered one of RDF’s known strengths. Other strong points include the fact that it allows data to be combined, exposed and shared across different applications or merged even if different schemas are involved.

It thus comes as no surprise that RDF is considered a most promising candidate for the sparse and heterogeneous data found on today’s Web. As a matter of fact, considering that the Web is nowadays a global medium for exchanging multiple types of data, (unstructured, semi-structured & structured) which are also related to multiple domains of interest, (government, business, social, etc) this heterogeneity poses a significant barrier when attempting to discover, combine and consume information.

RDF manages to overcome this matter at least to some extent and serves as the foundation towards a Web of easily identifiable and exploitable content for all types of agents, whether these involve humans or not. To expand more on this subject, until recently the vast amounts of information and knowledge available on the Web were exclusively consumable by humans since HTML was not designed to present information to agents other than the latter. Lately, RDF makes it possible to additionally include information in forms not solely intended for human consumption, but for automated agents as well. It accomplishes that by storing information in machine consumable statements, known as RDF triples that consist of a subject, a predicate and an object.

This “Divide & Conquer” approach allows RDF to divide large amounts of raw data into discrete, machine consumable parts, so as to conquer the knowledge behind them or of their combinations. As an example of an RDF triple, the subject “Aristotle University” has a property related to its location, locatedIn, which is described by the object “Thessaloniki”.

RDF triple examples

Any collection of similar RDF triples forms what is known as an RDF graph, which comprises of nodes and directed arcs that connect these nodes. The nodes correspond to objects or subjects of each one of these graph’s triples and the directed arcs to the predicates of the latter.

Returning to the components of an RDF triple, each one may be a resource on the Web, accessible via a URI and only in the case of the object component there is an additional option of a literal value, (i.e. string, number or date). This option represents in fact one of the two existing types of RDF triples, namely the Literal Triple.

As an example, all triples on the graph of the following figure, besides the one whose subject and object are in red color, are of that Literal type. For instance, the triple that states the establishment year of Aristotle University as being 1925 is a Literal type one, while the one that states Aristotle University as located in the city of Thessaloniki is of type RDF Link. Although both share the same subject of a URI identifying the non-information resource of Aristotle University, their objects are different. In the first case the object is the number 1925, while in the second a URI, (http://dbpedia.org/resource/Thessaloniki) identifies the city of Thessaloniki as a concept, (i.e. another concept related to that of the subject).

The following Figure and Table below represent an RDF graph with its associating triples and the parts these consist of. Based on them, it becomes obvious that Literal triples describe the properties of resources, and RDF Link ones the relationship among them.

RDF Graph: A collection of triples

As far as the predicate component is concerned, it is always identified by a URI and indicates the type of relationship between the other two components. What is more, such predicate URIs originate from RDF vocabularies (either well known or custom ones) which are oriented towards representing information in specific domains.

In the end, the process of outputting these or the triples of any RDF graph into a single file is called serialization and allows a graph to be published on the Web. This can be done in advance, (static datasets) or dynamically, (dynamic ones) and always according to some predefined syntax, (serialization format). There are currently, various RDF serialization formats, standardized or not by W3C and with associated advantages or disadvantages. Some of the most popular ones are RDF/XML, N-triples, Turtle, RDFa and RDF/JSON.

As previously demonstrated, a way to visualize collections of RDF triples is as RDF graphs. That is why RDF is known to define graph databases, the type on which the Semantic Web is being built upon. Compared to other data models, (i.e. Tree of Hierarchical DBs, or Tabular of Relational DBs) RDF’s model differs in many ways.

Comparison of Hierarchical, Relational & Graph Databases

Even so, although RDF defines data structures for the Semantic Web it fails to describe the semantics or meaning behind the data. In other words, it makes statements about “things”, (encoding of info) but does not provide the meaning behind them. More specifically, it only manages to assign properties to these things and relate the latter.

To improve upon RDF’s semantic limitations, RDF Schema, [42] was built on top of it to provide the syntax that would enable an improved encoding of RDF data with semantic metadata. As a result RDFS takes it a step further, additionally describing these properties and identifying the resources on which they can be applied.

URI / IRI, (Linked Data Technology Stack)

On the bottom layer of the Semantic Web stack, the URI and IRI components serve the decentralized nature of the Semantic Web by providing the foundations and a way to uniquely identify Web resources. Although both offer resource identification schemes, IRI extends URI with Unicode support so as to overcome known internationalization issues as described in the following paragraphs.

Uniform Resource Identifier,(URI)

 As far as URI is concerned, it stands for Uniform Resource Identifier and provides the means to uniquely address and distribute resources over the Web. In contrast to the classic “Web of documents” where URIs primarily identified and linked web documents, today’s “Web of Data”, additionally introduces real world entities and abstract concepts to also share data about them. Within that context, there is a need for URIs to serve both categories of resources and thus to distinguish information resources, (documents, media files, etc) from non-information resources, (e.g. ideas, real world things, etc). This however until now necessitates a strict use of the HTTP URI scheme.

Besides unique identification and clear distinction among all resource types, (information & non-information ones) the latter ensures provision of relevant content, (i.e. serve humans and/or machines with appropriate descriptions of the identified resources) over the Web and the ability to indicate representation type and alternative formats preference.

This is possible mainly because the HTTP protocol enables simple yet powerful representation retrieval and content negotiation mechanisms. While the first enables users to dereference a URI and perform an HTTP-based lookup for associated content, the second mechanism allows users to additionally specify the representation to be returned, (HTML, RDF/XML, etc) assuming availability at that URI.

For instance, considering the Attica region as a resource on the Web, then a URI of http://greek-lod.math.auth.gr/police/page/regions/2 identifies a webpage that provides information about that region and falls in the first category of resources, namely information resources. On the other hand, http://greeklod.math.auth.gr/police/resource/regions/2  belongs in the non-information type because it represents the region itself as a real world entity.

As far as the first mechanism is concerned, it is known as URI dereferencing and applies in both categories of resources (information & non-information). When dereferencing URIs that identify information resources, a newly generated HTML representation together with a “200 OK” HTTP response code, are returned back from the server.

However in the case of non-information resources, these reside in the real world and outside the Web’s information space. As a result they cannot be transmitted using the HTTP protocol and thus dereferencing cannot take place directly. Instead, when dereferencing URIs that identify non-information resources, representations of distinct information resources, (identified by distinct URIs) that convey information about the latter are provided.

There are currently two approaches available to choose from to achieve this, namely Hash URIs and 303 redirects. Focusing onto 303 redirects, by dereferencing the URI of http://greek-lod.math.auth.gr/police/resource/regions/2 (Attica Region identified as non-information resource) instead of returning directly an HTML representation the server now responds with an HTTP “303 See Other” code. Besides the code, the response also includes a distinct URI of an information resource that describes the Attica Region as a non-information resource. Depending on what the appropriate resource representation (HTML, RDF/XML, etc.) is each time, a different URI is returned concerning that concept. The representation itself depends on content negotiation and the client preference. As far as the HTTP content negotiation mechanism is concerned and in relation to the same example, as soon as the client receives the 303 redirect response it may negotiate with the server about the desired representation (e.g. HTML or RDF/XML) within an accept Header.

URI Dereferencing & Content Negotiation Mechanism

For instance, referring to the Hellenic Police data source, it holds the non-information resource identified via http://greek-lod.math.auth.gr/police/resource/regions/2 , (Attica Region) and provides http://greek-lod.math.auth.gr/police/data/regions/2 as an RDF/XML representation, or http://greek-lod.math.auth.gr/police/page/regions/2 as an HTML one.

Hellenic Police URIs for non-information resource of Attica Region

Thus the Hellenic Police data source serves in parallel three URIs for the non-information resource of Attica region. The first URI identifies that region as a non-information resource while the other two are distinct URIs identifying information resources with RDF/XML and HTML representations that describe Attica region.

Nevertheless and although the Web is so far designed around resources addressed by it, URI is currently exhibiting an inability to adequately cater for resources that involve non-Latin and special language characters. Consisting of a limited sequence of characters that originate from a subset of the US-ASCII and according to its rfc, it percent-encodes such resources. This results into long, often unreadable representations and poses a serious obstacle in the overall internationalization of Linked Open Data.

Greek characters ΑΠΘ are % encoded into an unreadable URI representation.

Keeping also in mind that as the Web grows continuously, so does the need to identify and exploit resources in languages based on characters other than Latin, such a realization renders the adoption of a richer character set imperative and this is where IRI comes into play.

Internationalized Resource Identifier (IRI)

IRI stands for Internationalized Resource Identifier and extends the syntax of URI with characters from the universal character set. In doing so, IRI overcomes URI’s limitations and allows for true internationalized Web addressing. In a sense, it removes the need for percent encoding and leads to meaningful, human consumable representations. Coming back to the previous example of ΑΠΘ Greek characters, these now appear as should, assuming IRI is used instead of URI.

Greek characters ΑΠΘ represented correctly via IRI mechanism.

However IRI is not yet fully supported by all current Linked Data tool implementations. As a result, when facing similar issues with URI in resource naming and in SPARQL queries, custom solutions maybe employed instead as discussed on http://journal.webscience.org/466/.

Semantic Web Technology Stack(s)

Clearly the intention for the Semantic Web is not to replace but rather to overlay the preceding web generations so as to supplement and enhance them. To render this feasible the latest web architecture is continuously evolving around a stack of already proven and emerging technological components. As far as already existing components are concerned, these are fundamental web technologies, borrowed from previous web versions that together form the Linked Data Technology Stack.

Semantic Web Technology Stack, [1] & Linked Data Technology Stack

[1] http://bnode.org/blog/2009/07/08/the-semantic-web-not-a-piece-of-cake

Web (R)evolution

The Web is constantly evolving and has nowadays grown into a mature self organizing system. It imitates a living organism that feeds upon information, adapts and evolves as humans and their needs evolve themselves. In its transition from a “Web of Documents” to a “Web of Linked Data” it has changed itself and our society in so many ways that it comes as no surprise it marked a major turning point in world history. In a sense, it redefined the way in which people connect, communicate and exchange knowledge.

Although it is not possible to predict in detail what its next evolutionary step is going to be, it is beneficial to look back and identify its historical curve up to this point. In this way and by observing how this event began and progressed through the last thirty years, one could shape the right expectations about its future behavior. The following sections divide web’s history up to this point into three distinct generations.

Web 1.0: The Web of Documents or Read Web

The birth of the World Wide Web took place on 1989, when Tim Berners-Lee, envisioned a global information space, where people and machines could equally exchange and exploit information rich in semantic value. Nonetheless, in its early steps the web comprised mostly of interlinked hypertext documents, (hence the Web of Documents) with the machines being merely the presenters of the latter. In fact it resembled more of a global file system, (of documents & their untyped hyperlinks being the primary objects) rather than the intended information space. A major factor that greatly influenced this matter was the absence of proper technological means, (e.g. untyped hyperlinks fail to disclose semantic relationships) to fully support the envisioned concept at that time.

This fact alone restricted the machines into simply presenting the documents and left humans to deal with their interpretation and connection. As if this was not enough, content contribution and interconnection were at least in the beginning, a privilege of a few independent web masters. Users had in their majority no actual saying but instead, their role was more of a passive consumer one, (hence the read only part). Within that context, the only available option was to acquire information from infrequently updated, static web pages of limited user interaction, (email, forums, search of info, etc).

Given these facts, it becomes obvious that despite its immediate success, Web 1.0 fell short of expectations in addressing the original vision of Tim Berners-Lee. The main reason was perhaps the early inability of humans to foresee the informational value in data contributions and of the machines to comprehend the meaning behind them. Overall, one may state that the first generation was more tailored towards passive, human consumers of information that were forced to fill in the semantic gaps themselves.

Web 2.0: The Social or Read/Write Web

Building on top of its predecessor and upon the realization that the web should be a living social creation, Web 2.0 emerged in an attempt to resolve open issues of the previous generation. Known also as the “Social Web”, this read/write, second version focused more into empowering its everyday users to create, control and share content of their own effortlessly, (multimedia, blogs, wikis, social networks, etc). In effect the aim was to overcome the limited user interaction issue of Web 1.0 and to offer a complementary, “Content Producer” role to its users. As a result Web 2.0 got quickly flooded with user generated content and that further led to an explosive growth of social networking. This new “Social Web” was all about participation, collaboration and forming communities for richer benefits and enhanced user interaction.

Nevertheless, although Web 2.0 was a giant leap forward and pointed in the right direction, it did not offer ways to administer this plethora of information, especially now that all users were at the same time potential content contributors. Thus while web content was as before comprehensible by humans, its sudden abundance rendered proper information management no longer possible without the active involvement of the machines. As soon as data contributions exceeded the consumption capabilities of human users and the informational needs of the latter increased in complexity, it became imperative to assign demanding processing and reasoning tasks to software agents and entities other than humans. Yet meaning was as in Web 1.0, still beyond their grasp especially with content that lacked some means (e.g. “semantic” and/or other structure) to reveal hidden informational parts and their relationships.

Thus, although Web 2.0 marked a transition from a “Web of Documents” to a “Web of People”, it only enabled full participation for its human users and did not manage to actively involve the machines. The latter were still unable to comprehend the meaning behind data and that is why the next evolutional step was undertaken, in the form of a “Web of Data”.

Web 3.0: The Semantic Web, (Web of Data)

The Semantic Web is all about enabling meaning hidden in the vast amounts of data on the web to become effortlessly and readily exploitable. As previously mentioned, the term exploitable in this case is not limited strictly to human consumption, but aims to gradually include any entity connected on the web. Thus, while Web 2.0 supported only collaboration between humans and the reasoning was done by the latter, this latest generation endeavours to take this a step further. It actually promotes the collaboration of “connected entities” on the web by empowering them to make meaningful content contributions, grasp the meaning behind them and collectively reason, all on the user’s behalf. Based on a, currently evolving web architecture, this generation seeks to enable entities to discover and access the “right” parts of information each time, preferably the ones of interest and being related in some way. New associations may then be made based on these relations and their significance so as to uncover even more relevant information across data sources.

This further sets the basis for rich information mashups, more fine-grained queries and at the end of the day, services that meet complex informational needs in a seamless way. In fact, it describes a transition from a “Web of People” sharing information to a “Web of Knowledge”, generated on human demand and served by the machines.

Whatever the name is, whether Semantic Web, or Web of Data, or even Web of Knowledge, the next generation is characterized by an ongoing effort to provide the kind of web architecture that supports the previously mentioned goals.  Thus said, the latest web architecture is continuously evolving around a stack of already proven and emerging technological components, the “Semantic Web Stack”.