building linked data applications

78
Building Linked Data Applications Presented by: Christoph Pinkel

Upload: euclid-project

Post on 08-May-2015

2.603 views

Category:

Technology


0 download

DESCRIPTION

This presentation gives details on technologies and approaches towards exploiting Linked Data by building LD applications. In particular, it gives an overview of popular existing applications and introduces the main technologies that support implementation and development. Furthermore, it illustrates how data exposed through common Web APIs can be integrated with Linked Data in order to create mashups.

TRANSCRIPT

Page 1: Building Linked Data Applications

Building Linked Data Applications

Presented by:Christoph Pinkel

Page 2: Building Linked Data Applications

EUCLID – Building Linked Data applications

2

CH 4

• Our aim: build a music-based portal using Linked Data technologies.

• So far, we have studied different mechanisms to consume Linked Data:• Executing SPARQL queries • Dereferencing URIs• Downloading RDF dumps• Extracting RDFa data

• The output of these mechanisms is displayed to the user by applying visualization techniques.

Motivation: Music!

CH 2

CH 3

CH 1

Page 3: Building Linked Data Applications

3

Motivation: Music!

Visualization Module

Metadata

Streaming providers

Physical Wrapper

Downloads

Dat

a ac

quis

ition

R2R Transf.LD Wrapper

Musical Content

Appl

icati

on

Analysis & Mining Module

LD D

atas

etAc

cess

LD Wrapper

RDF/ XML

Integrated Dataset

Interlinking CleansingVocabulary Mapping

SPARQL Endpoint

Publishing

RDFa

Other contentEUCLID – Building Linked Data applications

Page 4: Building Linked Data Applications

EUCLID – Building Linked Data applications

4

Agenda

1. Characterization of Linked Data applications

2. Linked Data application architecture

3. Linked Data application development frameworks

4. Using Web APIs

Page 5: Building Linked Data Applications

EUCLID – Building Linked Data applications

5

CHARACTERIZATION OF LINKED DATA APPLICATIONS

Page 6: Building Linked Data Applications

EUCLID – Building Linked Data applications 6

LD applications have three main parts:

• Consumes Linked Data: Systems that only consume LD are considered mashups. Consuming LD does not necessarily mean that sources expose RDF-based data. The app may use wrappers to transform the data into Linked Data.

• Manipulates/Produces Linked Data: Performs updates to RDF data and makes the data accessible on the Web of Data.

• Web App/Interface: Often operates on the Web. Allows to easily integrate and export data.

Source: M. Hausenblas. “Linked Data Applications”

Consumes LD

Manipulates& Produces

LDWeb app LD app

Linked Data Application

Page 7: Building Linked Data Applications

EUCLID – Building Linked Data applications

7

According to their usage, the majority of current Linked Data applications corresponds to:

• Generic Linked Data browsers: Dereference URIs to retrieve the resource description. Consume and expose Linked Data.Examples: Sig.ma, Sindice, Marbles, etc.

• Linked Data search engines: Allows the user to submit queries. Consume and republish the retrieved data.Examples: Swoogle, Watson, etc.

• Domain-specific Linked Data applications: Built for specific purposes.Examples: see later.

Source: M. Hausenblas. “Linked Data Applications”

CH 4

Categories of Linked Data Applications

CH 4

Source: M. Martin and S. Auer. “Categorisation of Semantic Web Applications”

Page 8: Building Linked Data Applications

EUCLID – Building Linked Data applications

8

Furthermore, Linked Data applications can be classified according to the following dimensions:

Categories of Linked Data Applications (2)

Source: M. Martin and S. Auer. “Categorisation of Semantic Web Applications”

Dimensions Levels Description

Semantic technology depth

Extrinsic Use of semantics on the surface of the application.

Intrinsic Conventional technologies (e.g., RDBMS) are complemented or replaced with SW equivalents.

Information flow direction

Consuming LD is retrieved from the source or via a wrapper.

Producing Publishes LD (in RDF-based formats).

Semantic richness Shallow Simple taxonomies, use of RDF or RDFS.

Strong High level representation formalisms (OWL variants)

Semantic integration

Isolated Creation of own vocabularies

Integrated Reuse of information at schema or instance level

Page 9: Building Linked Data Applications

EUCLID – Building Linked Data applications

9

Example: Data.gov.uk• Provides a data catalog about UK’s governmental information.

Source: http://data.gov.uk

Page 10: Building Linked Data Applications

EUCLID – Building Linked Data applications

10

Example: Data.gov.uk (3)

Source: http://data.gov.uk/apps

• A catalog of applications is available at the website

Page 11: Building Linked Data Applications

EUCLID – Building Linked Data applications

11

Example: Data.gov• Provides a catalog about US governmental data.

Source: http://catalog.data.gov/dataset

Page 12: Building Linked Data Applications

EUCLID – Building Linked Data applications

12

Example: Data.gov (2)• App developers can build applications on top of Data.gov.uk

data sets available at: https://catalog.data.gov/dataset

• Their platform also provides a set of applications built on top of these data sets

Source: http://www.data.gov/research/page/research-apps

Mobile AppsWeb Apps

Page 13: Building Linked Data Applications

EUCLID – Building Linked Data applications

13

Example: BBC – Dynamic Semantic Publishing• The BBC DSP architecture aims at

automating aggregation and publishing of interrelated content within the BBC portal.

• Journalists are able to semantically annotate content with LD concepts through the Graffiti tool.

• OWLIM triple store is used to keep the RDF data and to perform reasoning over the data.

Source: http://www.bbc.co.uk/blogs/bbcinternet/2012/04/sports_dynamic_semantic.html

Graffiti tool

Page 14: Building Linked Data Applications

EUCLID – Building Linked Data applications

14

Example: ResearchSpace• The ResearchSpace

environment aims at providing a set of RDF data sets and tools to describe concepts and objects related to cultural historical research.

• The tools are highly interactive: allow users to access the data and contribute to the data set by creating RDF annotations.

Geo Mapper

Image Annotation

Source: https://sites.google.com/a/researchspace.org/researchspace/

Page 15: Building Linked Data Applications

EUCLID – Building Linked Data applications

15

Example: ResearchSpace (2)

Source: https://confluence.ontotext.com/display/ResearchSpace/RS+Infrastructure

User Interface

The ResearchSpace infrastructure

Store and serve multiresolution images and titles

RDF data is accessed via SPARQL or Sesame OpenRDF API

Implement GUI requirements

Page 16: Building Linked Data Applications

EUCLID – Building Linked Data applications

16

Example: ResearchSpace CRM Search System

Source: Snapshot from https://www.youtube.com/watch?v=HCnwgq6ebAs

Search by predicates

Faceted search

Page 17: Building Linked Data Applications

EUCLID – Building Linked Data applications

17

Example: Open Pharmacology Space • OPS is a platform that aims at integrating pharmacological

data available in open standards.

• The OPS platform offers an API to access its data.

• The following applications have been built on top of OPS:• Open PHACTS Explorer: Allows browsing the OPS data.• ChemBioNavigator: Visualizes the composition of a molecule group.• PharmaTrek: Allows navigating the content of ChEMBL.

Source: http://www.openphacts.org/open-phacts-discovery-platform

PharmaTrekOpen PHACTS Explorer ChemBioNavigator

Page 18: Building Linked Data Applications

EUCLID – Building Linked Data applications

18

Example: Open Pharmacology Space (2)

Source: Williams A., Harland L., Groth P,. et al.: Open PHACTS: Semantic interoperability for drug discovery. Drug Discovery Today, June 06, 2012

Consumes LD

Produces LD

Semantic technology depth: intrinsic and extrinsic

The OPS platform architecture

Page 19: Building Linked Data Applications

EUCLID – Building Linked Data applications

19

Example: eCloudManagerUse case: data center management• Multitude of managed resources

• Hardware (physical storage, network, computational infrastructure)

• Virtualization capabilities (virtual clusters, live migration)

• Software applications

• Multitude of APIs and data sources

• Tool sprawl!

Source: http://www.fluidops.com/ecloudmanager/

Page 20: Building Linked Data Applications

Example: eCloudManager – Integrated View on the Data Center• Integration of different SW

and HW components, storage systems, compute infrastructures, applications, CRM systems, ticket systems, project catalogs.

• Automatic correlation of data retrieved from various systems.

• Unified view on data and metadata across the border of company units.

• Exploration, analysis, and actions based on the entire data corpus.

Integrated view showing connections between hardware layer, application layer, projects, and customers

Storage Infrastructure

Compute Infrastructure

Applications & Landscapes

Project Data

Source: http://www.fluidops.com/ecloudmanager/

Page 21: Building Linked Data Applications

EUCLID – Building Linked Data applications

21

ARCHITECTURE OFLINKED DATA APPLICATIONS

Page 22: Building Linked Data Applications

EUCLID – Building Linked Data applications

22

Software Architecture

• Denotes the structures or components of a software system.

• It is comprised of:

• Elements: Includes software (logic) components, databases, web servers, services, legacy systems or other type of components required in the system.

• Relationships between the elements: Mechanisms to communicate the different elements within the architecture.

• Software architecture also refers to a set of practices to use or design a (software) system.

Page 23: Building Linked Data Applications

EUCLID – Building Linked Data applications

23

Multitier Architecture

• Logically separates the components/functions of the system into different tiers, allowing for easy reuse or replace of a particular tier.

• The most common use of the multitier architecture is the three-tier architecture.Presentation tierCorresponds to the user interface. Translates the results into human-readable information.

Logic tierImplements the business logic, analytical computation etc.: performs detailed processing.

Data tierStores the data. This tier is independent from the business logic.

Sales per album of

‘The Beatles’

Search music artist: ‘The Beatles’.Retrieve album information.

Aggregate information per album.

SPARQL query

RDF results

Page 24: Building Linked Data Applications

24

General Architecture of Linked Data Applications

SPARQL EndpointsWeb Data accessed via APIs

Data Tier

RDF/ XML

Integrated Dataset

(Triple Store)

Interlinking CleansingData Access Component

Linked DataEUCLID – Building Linked Data applications

Relational Data

Vocabulary Mapping

Logic Tier

Presentation Tier

Data Integration Component

Republication Republication Component

SPARQL Wr. R2R Transf. LD WrapperPhysical Wrapper

Page 25: Building Linked Data Applications

EUCLID – Building Linked Data applications

25

Architectural Patterns

1. The Crawling Pattern: Crawls or loads data in advance. Data is managed in one triple store, thus it can be accessed efficiently. The disadvantage of this pattern is that the data might not be up to date.

2. The On-The-Fly Dereferencing Pattern: URIs are dereferenced at the moment that the app requires the data. This pattern retrieves up to date data. Performance is affected when the app must dereference many URIs.

3. The (Federated) Query Pattern: Submits complex queries to a fixed set of data sources. Enables applications to work with current data directly retrieved from the sources. Finding optimal query execution plans over a large number of sources is a complex problem.

Data Access

Cache

App

App

Data Access

Data Access

App

Source: T. Heath, C. Bizer. Linked Data: Evolving the Web into a Global Data Space

Page 26: Building Linked Data Applications

EUCLID – Building Linked Data applications

26

Data Layer

Data Access Component• Linked Data applications may implement a Mediator-Wrapper

Architecture to access heterogeneous sources:– Wrappers are built around each data source in order to provide an

unified view of the retrieved data.

• The method to access the data depends on the Linked Data architectural pattern.

• The factors that determine the decision of a pattern are:– Number of data sources to access– Requirement of consuming up-to-date data– Tolerance to high response time– Requirement of discovering new data sources

Page 27: Building Linked Data Applications

EUCLID – Building Linked Data applications

27

Data Layer (2)

Data Access Component (2)• The data access component may be implemented by using

one or a combination of the following tools:Mechanisms Tools (Examples)

Linked Data Crawlers LDspider https://code.google.com/p/ldspider/Slug https://code.google.com/p/slug-semweb-crawler/

Linked Data Client Libraries Semantic Web Client Library http://wifo5-03.informatik.uni-mannheim.de/bizer/ng4j/semwebclient/The Tabulator http://www.w3.org/2005/ajar/tabMoriarty https://code.google.com/p/moriarty/

SPARQL Client Libraries Jena Semantic Web Framework http://jena.apache.org/

Federated SPARQL Engines ANAPSID https://github.com/anapsid/anapsidFedX http://www.fluidops.com/fedx/SPLENDID https://code.google.com/p/rdffederator/

Search Engine APIs Sindice http://sindice.com/developers/apiUberblic http://uberblic.com/

Page 28: Building Linked Data Applications

EUCLID – Building Linked Data applications

28

CH 3

CH 2

Data Layer (3)

Data Integration Component• Consolidates the data retrieved from heterogeneous sources.

• This component may operate at:– Schema level: Performs vocabulary mappings in order to translate

data into a single unified schema. Links correspond to RDFS properties or OWL property and class axioms.

– Instance level: Performs entity resolution via owl:sameAs links. In case the data sources do not provide the links, further tools like Silk or Open Refine can be used to integrate the data.

Interlinking CleansingData Access Component

Vocabulary Mapping

Data Integration Component

Page 29: Building Linked Data Applications

EUCLID – Building Linked Data applications

29

Data Layer (4)

Integrated Dataset• The dataset resulting of integrated and consolidated data can

be cached in a RDF store.

• There are many solutions to deploy triple/RDF stores, e.g.:• OWLIM (http://www.ontotext.com/owlim)

• Jena TDB (http://jena.apache.org/documentation/tdb/)

• Cumulus RDF (https://code.google.com/p/cumulusrdf/)

• AllegroGraph (http://www.franz.com/agraph/allegrograph/)

• Virtuoso Universal Server (http://virtuoso.openlinksw.com/)

• RDF3x (https://code.google.com/p/rdf3x/)

Integrated Dataset

Republication Republication Component

Page 30: Building Linked Data Applications

EUCLID – Building Linked Data applications

30

Data Layer (5)

Republication Component• Exposes as Linked Data portions

• There are different solutions to make the data accessible:• Via SPARQL endpoints (e.g., Sesame OpenRDF SPARQL Endpoint, …)• Via APIs (e.g., Linked Data API)• As RDF dumps• With the built-in means of your framework/CMS (e.g., Drupal,

Information Workbench, …)

Dat

a La

yer

Integrated Dataset

Republication Republication Component

Page 31: Building Linked Data Applications

EUCLID – Building Linked Data applications

31

CH 4

Application and Presentation Layers

• The logic layer implements sophisticated processing according to the functionalities of the application. This layer may include data mining components as well as reasoners that are not integrated in the data layer.

• The presentation layer displays the information to the user in various formats, including text, diagrams or other type of visualization techniques.

Logic Layer

Presentation Layer

Page 32: Building Linked Data Applications

EUCLID – Building Linked Data applications

32

LINKED DATA APPLICATION DEVELOPMENT FRAMEWORKSInformation Workbench

Page 33: Building Linked Data Applications

EUCLID – Building Linked Data applications

33

Information Workbench

• Platform for development of linked data applications

Semantic Web Data

Semantics- & Linked Data-based Integration of Enterprise and Open Data Sources

Intelligent Data Access and Analytics• Visual exploration• Semantic search• Dashboarding and reporting

Collaboration and Knowledge Management Platform • Wiki-based curation & authoring of

data • Collaborative workflows

Source: http://www.fluidops.com/information-workbench/

Page 34: Building Linked Data Applications

EUCLID – Building Linked Data applications

34

Data storage and management platform

Reusable UI and data integration components

Customized application solutions

External resources to reuse data and create mashups

Information Workbench (2)

Page 35: Building Linked Data Applications

• Open Source, written in Java

• Layered architecture for semantic data management

• Easy to plug in new data management components on demand

• Most of the existing triple stores support Sesame API

Sesame Access API

SAIL API

Stable (yet extensilble) APIs for data access, manipulation, ...

SAIL 1 (e.g. Query Optimization Layer)

SAIL 2 (e.g. Distributed Query Execution Layer)

DB1 DB2 DB3

Stackable architecure of custom data management components

Easy integration by implementing a generic API

EUCLID – Building Linked Data applications

Data Storage & Access

Data Management based on Sesame framework

35

Page 36: Building Linked Data Applications

EUCLID – Building Linked Data applications

36

Back-End Configuration Options

Sesame native store ……

Sesame Sail API

OWLIM SYSTAPbigdata AllegroGraph

Local repository

Sesame Sail API

Sesame HTTP Server

Sesame remote

repository client API

Remote Sesamerepository

Sesame SPARQL

repository client API

SPARQL endpoint

Arbitrary SPARQL endpoint

• Back-end data store is specified via the IWB configuration properties

• Both local and remote data access are possibleSee http://iwb.fluidops.com/resource/Help:RepositoryConfiguration

Page 37: Building Linked Data Applications

EUCLID – Building Linked Data applications

37

Data Integration: Data Provider ConceptData providers support the periodic extraction & integration from external data sources into a central repository

• Lifting from arbitrary data formats to RDF (e.g., relational, XML, CSV)

• Parametrizable (e.g. connection information, refresh interval, ..)

• Built-in UI for instantiating providers• Intuitive interfaces and APIs for

writing own, custom providers

Connect to data source

Convert data into RDF

Extract data from source

Groovy Script

RDFR2RML

XML2RDF

SPARQL

Examples:

Store RDF in repository

Page 38: Building Linked Data Applications

Data Warehousing vs. Federation Warehousing• Data is copied from the source

into the warehouse• Query runs in the warehouse• Supported in IWB using data

providers

Federation• Data remains in federated DB• Query is pushed down to

federated DB• Supported in IWB using

SPARQL federation

DB DB

Warehouse

Query

Load

DB DB

Federation

Query

Query

EUCLID – Building Linked Data applications 38

Page 39: Building Linked Data Applications

Virtualized Data Integration with FedX

Application Layer

Virtualization Layer

Data Layer

Data Source Data Source Data Source

SPARQLEndpoint

SPARQLEndpoint

SPARQLEndpoint Metadata

Registry

Information Workbench:Integration of Virtualized Data Sources as a Service

Semantic WikiCollaboration

Reporting & AnalyticsVisual Exploration

Transparent & On-DemandIntegration of Data Sources

Data RegistriesCKAN, data.gov, etc.

+ Enterprise Data

EUCLID – Building Linked Data applications

See http://iwb.fluidops.com/resource/Help:FedX

See http://www.fluidops.com/fedx/

39

Page 40: Building Linked Data Applications

EUCLID – Building Linked Data applications

40

Customizable User Interface

Demo available at http://musicbrainz.fluidops.net

Main view area

Wiki page management

View selection toolbar

Current resource

Navigation shortcuts

Page 41: Building Linked Data Applications

User Interface Concept: One Page URI

Resource page

Graph

Resource page

Resource page

Resource page

EUCLID – Building Linked Data applications 41

Page 42: Building Linked Data Applications

EUCLID – Building Linked Data applications

42

Template:…

Data Driven UI: Ontology as “Structural Backbone”

Resource page

RDF DataGraph

Ontology(RDFS/OWL)

UI templates

Template:mo:MusicArtistResource page

Page 43: Building Linked Data Applications

Different Views on Every Resource

Wiki View

Table View

Graph View

Pivot View

EUCLID – Building Linked Data applications 43

Page 44: Building Linked Data Applications

CH 4

Analytics and ReportingVisualization and Exploration

Mashups with Social MediaAuthoring and Content Creation

Widgets are not static and can be integrated into the UI using a Wiki-style syntax.

EUCLID – Building Linked Data applications 44

Widget-Based User Interface

Page 45: Building Linked Data Applications

Example: Add Widgets to Wiki

• {{#widget: BarChart |• query ='SELECT distinct (COUNT(?Release) AS ?COUNT) ?label WHERE { • ?? foaf:made ?Release .• ?Release rdf:type mo:Release .• ?Release dc:title ?label .• }• GROUP BY ?label• ORDER BY DESC(?COUNT)• LIMIT 10• '• | input = 'label'• | output = 'COUNT'• }}

SPARQL

queries

Example: Show top 10 released records for an artist

EUCLID – Building Linked Data applications 45

Page 46: Building Linked Data Applications

Music Example

Page of a class: • Shows an overview of MusicArtist instances

EUCLID – Building Linked Data applications 46

See http://musicbrainz.fluidops.net/resource/mo:MusicArtist

Page 47: Building Linked Data Applications

EUCLID – Building Linked Data applications

47

Music Example (2)

Page of a class template: • Defines a layout for displaying each resource of the class • Uses semantic wiki syntax

See http://musicbrainz.fluidops.net/resource/Template:mo:MusicArtist

Page 48: Building Linked Data Applications

EUCLID – Building Linked Data applications

48

Music Example (3)

Page of a class instance: • Displays the data about the resource according to the class

template

See http://musicbrainz.fluidops.net/resource/?uri=http%3A%2F%2Fmusicbrainz.org%2Fartist%2Fb10bbbfc-cf9e-42e0-be17-e2c3e1d2600d%23_

Page 49: Building Linked Data Applications

Mashups with external sources

• Relevant information and UI elements from external sources can be incorporated in the wiki view

• IWB contains multiple mashup widgets for popular social media sources– Twitter– Youtube– Facebook– New York Times news– LinkedIn– …

{{#widget: Youtube| searchString = $SELECT ?x WHERE { ?? foaf:name ?x . }$| asynch = 'true’ }}

Template instantiation?? = http://musicbrainz.org/artist/a3cb23fc-acd3-4ce0-8f36-1e5aa6a18432%23_?x = „U2“

EUCLID – Building Linked Data applications 49

Page 50: Building Linked Data Applications

Triple Editor

Table View

• Edit structured data associated with a resource• Make change, add and remove triples

EUCLID – Building Linked Data applications 50

Page 51: Building Linked Data Applications

Ontology-Based Data Input

Triple Editor takes into account the ontology definition:• Autosuggestion tool considers the domains and ranges of the

properties

Example: properties available for the class mo:MusicGroup are suggested automatically

EUCLID – Building Linked Data applications 51

Page 52: Building Linked Data Applications

Validation of User Input

Validation uses property definitions in the ontology:

• The property myIntegerProperty has an associated rdfs:range definition.

• This ensures that all objects must be of XML schema type xsd:integer.

EUCLID – Building Linked Data applications 52

Page 53: Building Linked Data Applications

Further Information

• Information Workbench product page• http://www.fluidops.com/information-workbench/

• Demo system• http://musicbrainz.fluidops.net/

• Download a free Community Edition version• http://www.fluidops.com/information-workbench/iwb-download/

• Online documentation• http://help.fluidops.com/help/topic/iwb.help-2.5/help.html

EUCLID – Building Linked Data applications 53

Page 54: Building Linked Data Applications

EUCLID – Building Linked Data applications

54

LINKED DATA APPLICATION DEVELOPMENT FRAMEWORKSCalimachus, lmf & Synth

Page 55: Building Linked Data Applications

EUCLID – Building Linked Data applications

55

Callimachus

• Scalable platform for creating and running data-driven websites.

• Can be deployed on a server, allowing users to develop their pages and applications via a Web browser.

• Resources can be created via the user interface to build an application.

Source: http://callimachusproject.org

Page 56: Building Linked Data Applications

EUCLID – Building Linked Data applications

56

Linked Media Framework (lmf)

• Offers advanced services for linked media management, built on top of:• Apache Marmotta (Linked Data platform)• Apache Stanbol (extraction and enhancement framework)• Apache Solr (indexation)

• Typical use cases include:

Source: https://code.google.com/p/lmf/

Publishing legacy data as Linked Data

Building semantic search over data

Using a SKOS thesaurus for information extraction

Page 57: Building Linked Data Applications

EUCLID – Building Linked Data applications

57

Synth

• Development environment implemented with Ruby on Rails.

• Allows for building applications following the Semantic Hypermedia Design Method (SHDM).

Source: http://www.tecweb.inf.puc-rio.br/synth

• Provides a set of modules that receive models and produce the hypermedia app described in the model:• Domain• Navigation• Behavior• Interface

Page 58: Building Linked Data Applications

EUCLID – Building Linked Data applications

58

USING WEB APIS

Page 59: Building Linked Data Applications

EUCLID – Building Linked Data applications

59

Underlying Technology Basics

HTTP Overview• HTTP, by which all documents on the WWW are served, is a

client server protocol

• Every interaction is based on:

Request

Response

Page 60: Building Linked Data Applications

EUCLID – Building Linked Data applications

60

Underlying Technology Basics (2)

HTTP Request•Method• GET (retrieve entity identified by URI)• PUT (store entity under the given URI)• POST(submit the information as a new subordinate of the

resource URI)• DELETE (delete entity identified by URI)• Additionally HEAD, TRACE, CONNECT, OPTIONS, PATCH

•URI•Header•[optional] Body (with POST, PUT)

Request

Page 61: Building Linked Data Applications

EUCLID – Building Linked Data applications

61

Underlying Technology Basics (3)

HTTP Response• Response Code (Integer)

• 1xx: Provisional response, contains the Status-Line and optional headers

• 2xx: Indicates that the applications request was successfully received, understood, and accepted.

• 3xx: Further action needs to be taken by the user agent in order to fulfill the request.

• 4xx: The applications request was erroneous.• 5xx: The server has erred or is incapable of performing the request.

• Header• [optional] Body

Response

Source: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

Page 62: Building Linked Data Applications

EUCLID – Building Linked Data applications

62

Underlying Technology Basics (4)

HTTP Request – Response Pattern

• A Client can submit a request• Response from the server

HTTP GEThttp://en.wikipedia.org/wiki/Beatles

Client Web Server

200 (OK)

[HTML Page about the Beatles]

Page 63: Building Linked Data Applications

EUCLID – Building Linked Data applications

63

Underlying Technology Basics (5)

HTTP Conneg & Linked Data URI Lookup• A foundational issue in Linked Data was the distinction of URIs

for real-world objects versus documents (e.g., RDF) that might describe them.

• This can be handled in the HTTP Header together with content negotiation (conneg):

HTTP GEThttp://dbpedia.org/resource/The_BeatlesAccept: text/html

Client Web Server

303 (see other)http://dbpedia.org/page/The_Beatles

Page 64: Building Linked Data Applications

EUCLID – Building Linked Data applications

64

Underlying Technology Basics (6)

HTTP Conneg & Linked Data URI Lookup• A foundational issue in Linked Data was the distinction of URIs

for real-world objects versus documents (e.g., RDF) that might describe them.

• This can be handled in the HTTP Header together with content negotiation (conneg):

HTTP GEThttp://dbpedia.org/resource/The_BeatlesAccept: text/turtle

Client Web Server

303 (see other)http://dbpedia.org/data/beatles.n3

Page 65: Building Linked Data Applications

EUCLID – Building Linked Data applications

65

Underlying Technology Basics (6)

HTTP Conneg & Linked Data URI Lookup• A foundational issue in Linked Data was the distinction of URIs

for real-world objects versus documents (e.g., RDF) that might describe them.

• This can be handled in the HTTP Header together with content negotiation (conneg):

HTTP GEThttp://dbpedia.org/data/beatles.n3Accept: text/turtle

Client Web Server

200 (OK)

[RDF data about the Beatles]

Page 66: Building Linked Data Applications

EUCLID – Building Linked Data applications

66

Web APIs

MotivationThe Web has more to offer than just the retrieval of static data:• Data is often dynamically created as a result of some

calculation carried out over input data (e.g., weather information).

• Data can change frequently (e.g., moving objects).• Service endpoints, forms and APIs are used to trigger

functionalities in the Web and the real world and provide access to dynamic and static data sources.

• Web APIs provide a programming interface exposed on the Web to allow apps to make use of these functionalities.

Page 67: Building Linked Data Applications

EUCLID – Building Linked Data applications

67Source: http://programmableweb.com

Web APIs (2)

Motivation• The number of Web APIs is significantly increasing• An important role on the Web plays Representational State

Transfer (REST)• Architectural style for client–server interaction• Focused on the Web architecture

• ProgrammableWeb is a general directory for Web APIs:• Allows providers to

register their API• Allows application

developers to search for APIs

Page 68: Building Linked Data Applications

EUCLID – Building Linked Data applications

68

Richardson Maturity Model forREST Services

Level 2: HTTP Verbs

Level 3: HATEOASEach layer builds on the concepts and technologies of the layers below

Source: Richardson, L. & Ruby, S.; RESTful Web Services O'Reilly, 2007.

Level 1: Resources and URIs

Page 69: Building Linked Data Applications

EUCLID – Building Linked Data applications

69

Level 1: Thinking in Resources

• Resources rather than service endpoints:• A resource is anything with which a client is able to interact • Real world resources (e.g., car, movie, person…) are projected onto the

Web by making the information associated with it accessible on the Web

• Identifier• URI uniquely identify (many-to-one) a resource on the Web• For addressing and manipulation

• Different representations for one resource are possible

MovieResource

http://rest-music.org/artist/beatles

http://rest-music.org/artist/the_beatles

Service boundaryJSON Representation

RDF/N3 Representation

XML RepresentationSource: Webber, J.; Parastatidis, S. & Robinson, I. S.; REST in Practice - Hypermedia and Systems Architecture. O'Reilly, 2010.

Page 70: Building Linked Data Applications

EUCLID – Building Linked Data applications

70

Level 2: The Web as a Platform

Uniform interface for interaction • HTTP Verbs as methods to act on resources:

• Response Codes to coordinate the interactions (e.g., 200 OK, 201 CREATED, 303 SEE OTHER, 404 NOT FOUND)

HTTP Verb

Effect Characteristic

GET retrieve the representation of a resource identified with a URI

safe, idempotent

PUT create or overwrite a resource identified by a client-generated URI

idempotent

POST create a resource identified by a server-generated URI

DELETE delete a resource (or its representation) identified with a URI

idempotent

OPTIONS request for information about the available communication options

safe, idempotent

Page 71: Building Linked Data Applications

EUCLID – Building Linked Data applications

71

Level 2: The Web as a Platform (2)

Characteristics of HTTP Verbs• Safe: Guaranties not to change the resource on the server

• Example: Retrieving the representation of a resource does not change it

• Idempotent: The effect of several identical requests with an idempotent HTTP Verb is the same as for a single request• Example: Once a resource is deleted, deleting it again does not change

anything

Name: The BeatlesGenre: RockOrigin: Liverpool…

GET /artist/beatles

DELETE /artist/beatles

200 OK

DELETE /artist/beatles

404 not found

Name: The BeatlesGenre: RockOrigin: Liverpool…

Page 72: Building Linked Data Applications

EUCLID – Building Linked Data applications

72

Level 3: The Hypermedia ConstraintHATEOAS = Hypermedia As The Engine Of Application State

• Include links in the resource representationsto other relevant resources

Source: Fielding, R. T.; Architectural styles and the design of network-based software architectures, University of California, Irvine, 2000.

http://service.org/music/order

HTTP POST Response

dbp:Revolver a dbp:Album;mus:upc “094638241720”.

mus:001 a mus:Order.mus:001 db:content dbp:Revolver.mus:001 mus:price “10€”.mus:001 mus:status “awaiting payment”mus:001 mus:pay mus:001_pay.

Page 73: Building Linked Data Applications

EUCLID – Building Linked Data applications

73

Example: Freebase API

Freebase API• To retrieve RDF Freebase offers a specific API• No content negotiation• Allows applications to retrieve a subgraph of data connected

to a specific Freebase object • The URI is the concatenation of the RDF service URL and the Freebase

identifier

https://www.googleapis.com/freebase/v1/rdf/<id>

Source: https://developers.google.com/freebase/

Page 74: Building Linked Data Applications

EUCLID – Building Linked Data applications

74

Example: Freebase API (2)

Freebase API• Example:

• Every Freebase fact is mapped to a triple• Slashes in the ID are replaced by dots • Some facts are mapped to RDF Schema (e.g., /type/object/name rdfs:label)

• The response contains the first 100 values for each predicate

GET https://www.googleapis.com/freebase/v1/rdf/m/07c0j

Source: https://developers.google.com/freebase/

@prefix ns: <http://rdf.freebase.com/ns/>.

ns:m.07c0jns:award.award_nominee.award_nominations ns:m.0jwnvw4;ns:base.websites.website.website <http://www.thebeatles.com>;

Page 75: Building Linked Data Applications

EUCLID – Building Linked Data applications

75

Well-Known Non-RDF Web APIs

• TwitterProvides access to timelines, tweets, direct messages between users, followers, users, places, … See http://dev.twitter.com

• LastFMProvides access to music-related resources: albums, artists, groups, events, venues, … See http://dev.twitter.com

• FoursquareCheck in at their current location, create tips and lists, access recommendations, … See http://developer.foursquare.com

• …

Page 76: Building Linked Data Applications

EUCLID – Building Linked Data applications

76

• Linked Data applications• LD application = Consumes LD + Manipulates/Produces LD + Web app• Can be categorized according the following dimensions:

• Semantic technology depth• Information flow direction• Semantic richness• Semantic integration

• Architecture of Linked Data applications• Multitier combined with a wrapper-mediator architecture• Architectural patterns to consume LD: Crawling, on-the-fly

dereferencing, (federated) query pattern.• Main components: Triple store, logic components, UI components,

data access & integration component, republishing component

Summary

Page 77: Building Linked Data Applications

EUCLID – Building Linked Data applications

77

• Linked Data application development frameworks: Information Workbench• Data storage: Provides warehousing and federation capabilities• Data integration: Performed by Data Providers, e.g., OpenRefine• Data-driven, widget-based user interface, automatically generated by

executing SPARQL queries• User input validation via comparison against the underlying ontology

• Web APIs• Basic concepts: Request and Response• Request methods: GET, PUT, POST, DELETE (+ HEAD, TRACE, CONNECT, OPTIONS)

• Response codes: 1xx provisional, 2xx success, 3xx further action required, 4xx client error, 5xx server error

• Richardson Maturity Model for REST services: Level 1 – Resources and URIs, Level 2 – HTTP verbs, Level 3 – HATEOAS

Summary (2)

Page 78: Building Linked Data Applications

EUCLID – Building Linked Data applications

78

For exercises, quiz and further material visit our website:

@euclid_project euclidproject euclidproject

http://www.euclid-project.eu

Other channels:

eBook Course