Linked Data and Service Orientation

8th International Conference on Service Oriented Computing
ICSOC 2010 [http://icsoc10.disi.unitn.it/]
December 7-10, 2010, San Francisco, California

Erik Wilde, UC Berkeley School of Information
December 8, 2010

Creative Commons License [http://creativecommons.org/licenses/by/3.0/]

This work is licensed under a CC
Attribution 3.0 Unported License [http://creativecommons.org/licenses/by/3.0/]

Contents Erik Wilde: Linked Data and Service Orientation

Contents

Erik Wilde: Linked Data and Service Orientation

(2) Abstract

Linked Data has become a popular term and method of how to expose structured data on the Web. There currently are two school of thought when it comes to defining what Linked Data actually is, with one school of thought defining it more narrowly as a set of principles describing of how to publish data based on Semantic Web technologies, whereas the other school more generally defines it as any form of properly linked data that follows the Representational State Transfer (REST) architectural style of the Web. In this paper, we describe and compare these two schools of thoughts with a particular emphasis on how well they support principles of service orientation.



Erik Wilde: Linked Data and Service Orientation

(3) Linked Data?



Erik Wilde: Linked Data and Service Orientation

(4) Data Models and Service Models



Erik Wilde: Linked Data and Service Orientation

(5) What is a Service?



Erik Wilde: Linked Data and Service Orientation

(6) Services and Linked Data



Linked Data Architectures

Outline (Linked Data Architectures)

  1. Linked Data Architectures [10]
    1. Homogeneous Linked Data (HoLD) [2]
    2. Heterogeneous Linked Data (HeLD) [6]
  2. Linked Data Services [7]
Linked Data Architectures Erik Wilde: Linked Data and Service Orientation

(8) Word or Trademark?



Linked Data Architectures Erik Wilde: Linked Data and Service Orientation

(9) Constraint Languages



Homogeneous Linked Data (HoLD)

Outline (Homogeneous Linked Data (HoLD))

  1. Linked Data Architectures [10]
    1. Homogeneous Linked Data (HoLD) [2]
    2. Heterogeneous Linked Data (HeLD) [6]
  2. Linked Data Services [7]
Homogeneous Linked Data (HoLD) Erik Wilde: Linked Data and Service Orientation

(11) Linked Data Datasets September 2010

lod-datasets.png

Homogeneous Linked Data (HoLD) Erik Wilde: Linked Data and Service Orientation

(12) Transforming Datasets

*2RDF Conversion

Heterogeneous Linked Data (HeLD)

Outline (Heterogeneous Linked Data (HeLD))

  1. Linked Data Architectures [10]
    1. Homogeneous Linked Data (HoLD) [2]
    2. Heterogeneous Linked Data (HeLD) [6]
  2. Linked Data Services [7]
Heterogeneous Linked Data (HeLD) Erik Wilde: Linked Data and Service Orientation

(14) Plain Web in Action

  • Representational State Transfer (REST) as the starting point
  • A set of constraints that inform a service architecture
  1. Resource Identification [Resource Identification (1)]
  2. Uniform Interface [Uniform Interface (1)]
  3. Self-Describing Messages [Self-Describing Messages (1)]
  4. Hypermedia Driving Application State [Hypermedia Driving Application State (1)]
  5. Stateless Interactions [Stateless Interactions (1)]


Heterogeneous Linked Data (HeLD) Erik Wilde: Linked Data and Service Orientation

(15) Resource Identification

  • Name everything that you want to talk about
  • Thing in this case should refer to anything
    • products in an online shop
    • categories that are used for grouping products
    • customers that are expected to buy products
    • shopping carts where customers collect products
  • Application state also is represented as a resource
    • next links on multi-page submission processes
    • paged results with URIs identifying following pages


Heterogeneous Linked Data (HeLD) Erik Wilde: Linked Data and Service Orientation

(16) Uniform Interface

  • The same small set of operations applies to everything [Resource Identification (1)]
  • A small set of verbs applied to a large set of nouns
  • Identify operations that are candidates for optimization
    • GET and HEAD are safe operations
    • PUT and DELETE are idempotent operations
    • POST is the catch-all and can have side-effects
  • Build functionality based on useful properties of these operations


Heterogeneous Linked Data (HeLD) Erik Wilde: Linked Data and Service Orientation

(17) Self-Describing Messages

  • Resources are abstract entities (they cannot be used per se)
  • Resources are accessed using resource representations
    • resource representations are sufficient to represent a resource
    • it is communicated which kind of representation is used
    • representation formats can be negotiated between peers
  • Resource representations can be based on different constraints
    • XML and JSON can represent the same model for different users
    • whatever the representation is, it must support links [Hypermedia Driving Application State (1)]


Heterogeneous Linked Data (HeLD) Erik Wilde: Linked Data and Service Orientation

(18) Hypermedia Driving Application State

  • Resource representations [Self-Describing Messages (1)] contain links to identified resources [Resource Identification (1)]
  • Resources and state can be used by navigating links
    • links make interconnected resources navigable
    • without navigation, identifying new resources is service-specific
  • RESTful applications navigate instead of calling
    • representations [Self-Describing Messages (1)] contain information about possible traversals
    • the application navigates to the next resource depending on link semantics
    • navigation can be delegated since all links use identifiers [Resource Identification (1)]


Heterogeneous Linked Data (HeLD) Erik Wilde: Linked Data and Service Orientation

(19) Stateless Interactions

  • This constraint does not say Stateless Applications!
    • for many RESTful applications, state is an essential part
    • the idea of REST is to avoid long-lasting transactions in applications
  • Statelessness means to move state to clients or resources
    • the most important consequence: avoid state in server-side applications
  • Resource state is managed on the server
    • it is the same for every client working with the service
    • when a client changes resource state other clients see this change as well
  • Client state is managed on the client
    • it is specific for a client and thus has to be maintained by each client
    • it may affect access to server resources, but not the resources themselves


Linked Data Services

Outline (Linked Data Services)

  1. Linked Data Architectures [10]
    1. Homogeneous Linked Data (HoLD) [2]
    2. Heterogeneous Linked Data (HeLD) [6]
  2. Linked Data Services [7]
Linked Data Services Erik Wilde: Linked Data and Service Orientation

(21) Linked Data Service Model

  1. Services expose resources and allow interactions
    • interaction interfaces should be uniform (but there can be many)
  2. Interactions use link-friendly representations
    • representations can be negotiated or determined server-side
  3. Links in representations point to potential next interactions
    • links often are not self-describing but identified in some schema
  4. Clients understand representations and links and make choices
    • there can be different levels of understanding
  5. There is no complete picture other than a crawl
    • availability and existence of resources may depend on prior interactions


Linked Data Services Erik Wilde: Linked Data and Service Orientation

(22) Resource Linking Language (ReLL)



Linked Data Services Erik Wilde: Linked Data and Service Orientation

(23) School Description Service (Person List)

  <resource xml:id="peoplelist">
   <name>People List</name>
   <desc>A list of people.</desc>
   <uri match="http://.*?/people/(faculty|students|staff|visitors)" type="regex"/>
   <representation type="xhtml">
    <name>Person List HTML Page</name>
    <link type="listedmember" target="person" minOccurs="0" maxOccurs="1">
     <selector select="//html:div[@class = 'person-col-1']/html:a/@href" type="xpath"/>
     <protocol type="http">
      <request method="get"/>
      <response media="xhtml"/>
     </protocol>
    </link>
   </representation>
  </resource>


Linked Data Services Erik Wilde: Linked Data and Service Orientation

(24) School Description Service (Person)

  <resource xml:id="person">
   <name>Person Page</name>
   <desc>The home page for a person.</desc>
   <uri match="http://.*?/people/(faculty|students|staff|visitors)/[a-zA-Z]+" type="regex"/>
   <representation type="xhtml">
    <name>Person HTML Page</name>
    <link type="website">
     <selector select="//html:td[@class = 'field-field-person-website']/html:div[@class = 'title']/html:a/@href" type="xpath"/>
    </link>
    <link type="personcourse" target="course">
     <selector select="//html:span[@class = 'views-field-title']/html:a/@href" type="xpath"/>
     <protocol type="http">
      <request method="get"/>
      <response media="xhtml"/>
     </protocol>
    </link>
   </representation>
  </resource>


Linked Data Services Erik Wilde: Linked Data and Service Orientation

(25) ISchool People and Courses

ischool-courses.jpg

Linked Data Services Erik Wilde: Linked Data and Service Orientation

(26) Finding Links

HTTP/1.1 200 OK
Link: <http://dret.net/netdret/>; rel="author"; title="Paper Author"
Content-Type: application/pdf
				
[ ... ]


Linked Data Services Erik Wilde: Linked Data and Service Orientation

(27) Services and Innovation



Erik Wilde: Linked Data and Service Orientation

(28) Conclusions



December 8, 2010 8th International Conference on Service Oriented Computing
ICSOC 2010 [http://icsoc10.disi.unitn.it/]
December 7-10, 2010, San Francisco, California