BUILDING APPS

Building Apps with Linked Data

As with all applications Linked Data applications consist of three main parts:

  • Consumption of Data
  • Analysis of Data
  • User Interface

The only thing that changes in the implementation of the application when we use linked data is the way we retrieve our data. This is done using the SPARQL query language and HTTP requests as described below:

Consume Linked Data using HTTP requests

  • GET request with a query parameter:query : SPARQL query string (url encoded)
  • Use Accept header according to the required results format:
    application/sparql-results+xml (XML)
    application/sparql-results+json (JSON)
    text/tab-separated-values (TSV)
    text/html (HTML table)
    application/json OR application/geojson (GeoJSON)
    application/kml (KML)

The results’ format vary according to the needs of the application. Most developers are familiar with JSON/GeoJSON formats that are fully supported by the tools, so the process of analysis should not change. The final step is the UI design that is not affected by the type of data that are used.

GET DATA


 

WEB SEMANTICS TUTORIAL

The Semantic Web

In the last few years, the Web is moving from a “Web of documents” to a “Web of data”. This is happening because big search engines such as Google are making use of not only the textual information that appears on a Web page (e.g., “James Bond has been played by Sean Connery. Sean Connery comes from Scotland.”) but also the meaning of the terms that constitute this information (e.g., “James Bond”, “Sean Connery”, “Scotland”, “plays”, “comes from”) in order to answer user queries. In the past, if we googled “Sean Connery”, we would get back a list of URLs pointing us to Web pages that contain the string “Sean Connery”. These Web pages would be ordered by their importance using various algorithms such as PageRank that Google employed. Today if google “Sean Connery” (try it!), Google understands that we are looking for information about the person called Sean Connery” and it will also give us a window where structured data about this person appear (his name, his occupation, his age, his Wikipedia entry, his date of birth, pictures of him, etc.). Thus, search engines like Google have started understanding the “meaning” or the “semantics” of the natural language text that appears on Web pages.

The technologies that have allowed search engines to improve in this exciting way have been under development since around 2000 under the terms “Semantic Web” and “Linked Data”. On this page, you can read the influential paper “The Semantic Web” that kick-started this research area and was co-authored by the inventor of the Web and Turing Award Winner Sir Tim-Berners Lee. Europe has been a major player in this area with many scientists from Universities, Research Institutes and Companies contributing the the Semantic Web and Linked Data.

 

Semantic Web and Linked Data are based on the following technologies:
• URIs as a way to name entities, relationships etc. in the world.
• HTTP as the protocol to access information about these entities etc.
• RDF as the data model for representing information about the world.
• SPARQL as the query language for querying this information

 

MORE

 


 

DEMO APPLICATION

This is a demo application that uses the new tools and utilises the power of linked data to illustrate the connection between the land cover and Leaf Area Index values for Paris.

 

Datasets:

  • Corine Land Cover
  • Leaf Area Index
  • Global Administrative Geography

 

SPARQL Queries:

  • Administrative divisions of Paris

PREFIX gadm:<http://geo.linkedopendata.gr/gadm/ontology#>
PREFIX geo:<http://www.opengis.net/ont/geosparql#>
PREFIX rdf:<http://www.w3.org/TR/rdf-schema/>

SELECT ?name ?w2
WHERE {
?adm a <http://geo.linkedopendata.gr/gadm/AdministrativeUnit> .
?adm gadm:hasName ?name .
?adm gadm:belongsToAdm2 ?adm2 .
?adm2 gadm:hasName “Paris”^^<http://www.w3.org/2001/XMLSchema#string> .
?adm geo:hasGeometry ?geo2 .
?geo2 geo:asWKT ?w2 .
}

  • Leaf Area Index values for Paris

PREFIX lai:<http://geo.linkedopendata.gr/lai/ontology/>
PREFIX corine:<http://geo.linkedopendata.gr/corine/ontology#>
PREFIX gadm:<http://geo.linkedopendata.gr/gadm/ontology#>
PREFIX geo:<http://www.opengis.net/ont/geosparql#>
PREFIX rdf:<http://www.w3.org/TR/rdf-schema/>
PREFIX geof:<http://www.opengis.net/def/function/geosparql/>

SELECT DISTINCT ?w ?name ?lai ?t
WHERE {
?s lai:lai ?lai .
?s geo:hasGeometry ?geo .
?s lai:observationTime ?t .
?geo geo:asWKT ?w .

?adm <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://geo.linkedopendata.gr/gadm/AdministrativeUnit> .
?adm gadm:hasName ?name .
?adm gadm:belongsToAdm2 ?adm2 .
?adm2 gadm:hasName “Paris”^^<http://www.w3.org/2001/XMLSchema#string> .
?adm geo:hasGeometry ?geo2 .
?geo2 geo:asWKT ?w2 .

?c corine:hasLandUse ?l .
?c geo:hasGeometry ?geo3 .
?geo3 geo:asWKT ?w3 .

FILTER (geof:sfIntersects(?w,?w2)) .
FILTER (geof:sfIntersects(?w,?w3)) .
}

  • Instances of each Corine Land Cover category for the area of Paris

PREFIX lai:<http://geo.linkedopendata.gr/lai/ontology/>
PREFIX corine:<http://geo.linkedopendata.gr/corine/ontology#>
PREFIX gadm:<http://geo.linkedopendata.gr/gadm/ontology#>
PREFIX geo:<http://www.opengis.net/ont/geosparql#>
PREFIX rdf:<http://www.w3.org/TR/rdf-schema/>
PREFIX geof:<http://www.opengis.net/def/function/geosparql/>
PREFIX strdf:<http://strdf.di.uoa.gr/ontology#>

SELECT DISTINCT ?l (strdf:union(?w3) as ?geo) (count(?c) as ?instances)
WHERE {
?adm <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://geo.linkedopendata.gr/gadm/AdministrativeUnit> .
?adm gadm:hasName ?name .
?adm gadm:belongsToAdm2 ?adm2 .
?adm2 gadm:hasName “Paris”^^<http://www.w3.org/2001/XMLSchema#string> .
?adm geo:hasGeometry ?geo2 .
?geo2 geo:asWKT ?w2 .
?c corine:hasLandUse ?l .
?c geo:hasGeometry ?geo3 .
?geo3 geo:asWKT ?w3 .
FILTER (geof:sfIntersects(?w2,?w3))
}
GROUP BY ?l

 

Each of the presented queries can be posed to the SPARQL endpoints with a simple GET request and retrieve the results in the KML format using the application/kml Accept Header.

 

Then we can display the KML files on a map as shown in the figure below:

 

Need some inspiration? Here are some examples that show what’s already possible.