Designing Semantic CMS - Part II

Designing
Semantic
CMS – Part II
Semantic CMS Community

Lecturer
Organization

Date of presentation

Co-funded by the
1 Copyright IKS Consortium
European Union

Page:

Part I: Foundations

(1) Introduction of Content Foundations of Semantic
(2)
Management Web Technologies

Part II: Semantic Content Part III: Methodologies
Management

Knowledge Interaction Requirements Engineering
(3) (7)
and Presentation for Semantic CMS

(4) Knowledge Representation
and Reasoning
(8)
Designing
Semantic CMS

Semantifying
(5) Semantic Lifting (9) your CMS

Storing and Accessing Designing Interactive
(6) Semantic Data
(10) Ubiquitous IS

www.iks-project.eu

Page: 3

What is this Lecture about?

 We have seen ... Part III: Methodologies
 ... how requirements for
semantic content management Requirements Engineering
(7)
are defined in a systematic way. for Semantic CMS

 ... a list of industry needs. Designing
(8) Semantic CMS
 What is missing?
Semantifying
 An efficient way to design an (9) your CMS
architecture for a semantic CMS
that meets the defined (10)
Designing Interactive
requirements Ubiquitous IS

www.iks-project.eu Copyright IKS Consortium

Page: 4

How to design a semantic
CMS?

What does the
Conceptual Part 1
architecture of a
Reference IKS Reference
semantic CMS look
Architecture Architecture
like?

Technical
How can a semantic Part 2
Architectural
CMS be realized? REST Architecture
Style


Page: 5

REST Architecture
Gateway,
Origin
Clients Proxy Load
+ Cache Server
Balancer
http
C

http http
C

http C

C

server are easy to replicate – scalable architecture
 Stateless
 Caches are only possible in stateless communication


Page: 6

RESTful Interfaces
 REST is based on uniform interfaces between the
components of the architecture.

 A RESTful interface has to fulfill the following
constraints:
 Identification of resources
 Manipulation of resources through representations
 Self-descriptive messages
 Hypermedia as the engine of application state

Roy Thomas Fielding, Architectural Styles and the Design of Network-based Software
Architectures, PhD Thesis, http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm, 2000

Page: 7

REST Applied to Web
Technologies
 Resource identification by applying REST to
Universal Resource Identifiers (URIs)
 http://upb.de
 Self-descriptive
messages and resource representation
by using HTML, XML and JSON
 Resource manipulation through representations by
applying REST to HTTP
 HTTP POST to http://upb.de/news to create a new posting
 Code-on-demand by using JavaScript
 Include JavaScript in HTML


Page: 8

Resource Oriented
Architecture (ROA)
 One fundamental concept of REST are resources
 Design web applications by focusing on resources and
applying ROA design principles
 A web service is a resource
 Each entity that is part of the web application is a resource
 ROA applied to URI
 Each resource has a stable URI
 Map hierarchies of resources by using sub paths in URIs
 Use URI parameters to specify additional constraints on
the resource, for example:
/path/to/resource?param1=value1&param2=value2

Page: 9

ROA applied to URI
 Bank Bank
 http://www.bank.de/
 All clients of the bank clients *
Client
 http://www.bank.de/clients
 Single client identified by client number accounts *
Account
 http://www.bank.de/clients/815
 All accounts of client 815 balance 1
 http://www.bank.de/clients/815/accounts Balance

 Single account number 4538734 of client 815
 http://www.bank.de/clients/0815/accounts/4538734
 Balance of account 4538734 of client 815
 http://www.bank.de/clients/815/accounts/4538734/balance

Page: 10

REST applied to HTTP
 Meta-data
are stored in the header as HTTP Message

name-value pairs, for example HTTP Header

 Language information Name = Value
 Data format Name = Value
 Cache control
HTTP Body
 User name, security token
 Payload is transported in the HTTP 0101010101010
body, for example
 a SOAP message when using standard
web services
 a JSON string in case of lightweight
web services

Page: 11

Representation of Resources
 Each resource has its URI
 By accessing the URI the resource can be retrieved in
different representations (formats)
 HTTP uses content negotiation with the accept-*
header for this, for example
GET /clients/0815
Returns a HTML representation of the
Host: bank.de
client 0815. Preferred languages are
Accept: text/html
first German then English.
Accept-Language: de, en

GET /clients/0815 Returns a JSON representation of the
Host: bank.de client 0815. Preferred languages are
Accept: application/json first English then German.
Accept-Language: en, de


Page: 12

HTTP Content Negotiation
 A HTTP Request supports four Accept-* fields
 Accept: List of accepted media types
 Accept-Charset: List of accepted character sets and
character encodings, respectively.
 Accept-Encoding: List of accepted encodings of the
content.
 Accept-Language: List of accepted languages.
 The values are comma separated lists of weighted
properties, for example
 Accept-Language: de, en;q=0.5, fr;q=0.2
 Client accepts German, English, and French with
German weighted as 1, English 0.5, and French 0.2
For further reading have a look at the Internet Engineering Task Force (IETF) Copyright IKS Consortium
www.iks-project.eu
“httpbis” working group page: http://datatracker.ietf.org/wg/httpbis/

Page: 13

HTTP Media Types
 text/* for text data, e.g. html
 image/* for image data, e.g. gif
 video/* for video files, e.g. mpeg
 audio/* for audio files, e.g. mp3
 application/* for not interpreted binary data, e.g. xml, json
 application/vnd.* for vendor specific formats, e.g. ms-excel
 application/x-* for non-standard files, e.g. latex
 application/x-pkcs* for (public key) cryptographic files
 multipart/* for data in multiple parts, e.g. form-data
 message/* for messages, e.g. e-mail format rfc-822
 model/* for data with multidimensional structure, e.g. vrml


Page: 14

Manipulation of Resources via
HTTP
 Use HTTP methods to access and manipulate
resources.
 Standard web services only use HTTP POST and GET
to send SOAP messages, but there is more
 OPTIONS – to request information about the communication
options available to a given URI
 HEAD – is identical to GET but the server must not return a
message-body in the response
 PUT – to store the enclosed resource under the request URI
 DELETE – to delete the resource identified by the request URI
 TRACE – to see what is being received at the other end of the
request chain and use that e.g. for testing

Page: 15

Example REST Call
HTTP Operation Resource identified by URI
 Request
POST http://www.bank.de/clients/815/accounts/4538734/balance

HTTP-Header:
Accept: application/json Format
HTTP-Body: {
“amount” : -100 Parameter
}

 Response
HTTP-Header:
Format
Content-type: application/json
HTTP-Body: {
“balance” : -500 Return
} value

Page: 16

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

Idempotent HTTP Methods
 Idempotence:
The side-effects of N > 0 identical requests is the same
as for a single request.
 Idempotent HTTP methods are
 GET, HEAD, PUT, DELETE
 Methods that must not have any side effects, and so are
inherently idempotent
 OPTIONS and TRACE
 Note, a sequence of requests may not be idempotent
even if all used methods in that sequence are
idempotent

Page: 17

Download at http://curl.haxx.se/

REST from the Command Line
 cURL tool available for all major platforms
 On Windows you may need Microsoft Visual C++ 2010
Redistributable Package
 cURL is a command line tool for transferring data with
URL syntax
 Examples:
 GET a resource
curl http://host.de/path/to/resource
 GET resource as XML
curl –H "Accept: application/xml" http://host.de/resource
 POST to a resource
curl -d "name=Smith" http://host.de/resource

Page: 18


HTTP OPTIONS
no side-effects
 Reponses are not cacheable
 Example: Check OPTIONS of http://apache.org

curl –i –X OPTIONS http://apache.org
HTTP/1.1 200 OK
Date: Thu, 10 Nov 2011 12:50:12 GMT
Server: Apache/2.3.15-dev (Unix) Supported
Allow: GET,HEAD,POST,OPTIONS,TRACE HTTP methods
Cache-Control: max-age=3600
Expires: Thu, 10 Nov 2011 13:50:12 GMT
Content-Length: 0
Content-Type: text/html; charset=utf-8


Page: 19


HTTP GET
idempotent
 Retrieve whatever information (in the form of an entity)
is identified by the request URI.
 If the URI refers to a data-producing process
(service), the returned information is the produced data
(not the service).
 Cacheable
 Possibility of conditional GET by header
 If-Modified-Since, If-Unmodified-Since, If-
Match, …
curl -i -H "If-Modified-Since: Thu, 10 Nov 2011 14:30:00 GMT"
http://apache.org website if modified since November
 Example: Get
HTTP/1.1 304 - 2:30 pm
10, 2011 Not Modified

Page: 20


HTTP HEAD
idempotent
 The HEAD method is identical to GET except that the server
MUST NOT return a message-body in the response.
 Often used for testing hypertext links for
validity, accessibility, and recent modification.
curl -i –X HEAD http://www.uni-paderborn.de
HTTP/1.1 200 OK
Server: Apache
Set-Cookie: fe_typo_user=cdb2bbfa6be0c06c41c2d050d2492bb4;

curl -i –X HEAD http://google.de
HTTP/1.1 301 Moved Permanently
Location: http://www.google.de/
Expires: Sat, 10 Dec 2011 15:07:42 GMT
Cache-Control: public, max-age=2592000
Copyright IKS Consortium
Server: gws
www.iks-project.eu

Page: 21


HTTP PUT
idempotent

 Use PUT to create a resource at a given URI
 The PUT method requests that the enclosed entity be
stored under the supplied Request-URI.
 Different meaning of URI in POST and PUT
 POST: URI identifies resource to handle the request
 PUT: URI identifies entity enclosed with the request
 Return codes:
 New resource created (201 Created)
 Existing resource modified (200 OK or 204 No Content)
 Request applied to different URI than specified by the
Request-URI (301 Moved Permanently)

Page: 22


HTTP POST
 Accept an entity as a new subordinate of the resource
identified by the URI. Use to cover the following functions:
 Annotation of existing resources
 Posting a message to a bulletin board, newsgroup, mailing
list, or similar group of articles
 Providing a block of data, such as the result of submitting a
form, to a data-handling process
 Extending a database through an append operation.
 Example to post a message with topic “Test” and text “Hello
World”: URL encoded string
curl -d "topic=Test&text=Hello%20World"
http://some.host.com/messages

Page: 23


HTTP DELETE
idempotent
 The DELETE method requests that the origin server
delete the resource identified by the Request-URI.
 Deletion can mean to move the resource to
inaccessible location.
 Responses are not cacheable. Return codes
 Delete successful (200 OK)
 Delete accepted but not enacted yet (202 Accepted)
 Delete enacted but no entity in response (204 No Content)
curl -i –X DELETE http://google.de
HTTP/1.1 405 Method Not Allowed
Server: GFE/2.0


Page: 24


HTTP TRACE
no side-effects

 The TRACE method is used to invoke a
remote, application-layer loop-back of the request
message.
 A TRACE request MUST NOT include an entity.
 The final recipient is either the origin server or the first
proxy or gateway
 TRACE allows the client to see what is being received
at the other end of the request chain and use that data
for testing or diagnostic information.
 For security reasons most web servers don‟t allow this.


Page: 25

Mismatches between REST
and HTTP
 Cookies
 Back-button confusion if application state is stored in cookie.
 Allow data to be passed without sufficiently identifying its
semantics. Becoming a concern for both security and privacy.
 Possibility to track users as they browse between sites.
 Mandatory Extensions
 HTTP header field names can be extended at will, but only when
the information they contain is not required for proper
understanding of the message.
 By extending the header with mandatory fields that need to be
interpreted to understand the message – the REST concept is
broken.


Page: 26

Source and further reading: http://www.w3.org/Submission/wadl/

Describing REST Interfaces
 WADL – Web Application Description Language
 GET http://www.bank.de/application.wadl
<?xml version="1.0" encoding="UTF-8"?>
<application xmlns="http://wadl.dev.java.net/2009/02">
<resources base="http://www.bank.de/">
Resource
<resource path="/clients/{cid}">
Parameter <param name="cid" style="template" type="xsd:int" />
<method name="GET">
<response> Parameter type
Operation <representation mediaType="application/xml"/>
<representation mediaType="application/json"/>
</response>
</method> Supported response formats
</resource>
</resources>
</application>

Page: 27

Source and further reading: https://dev.twitter.com/docs/api

REST API Example: Twitter
 Twitter REST API for getting followers
 GET followers/ids
 Returns an array of numeric IDs for every user following
the specified user.
 Resource URL
http://api.twitter.com/1/followers/ids.format
Format: Should use
HTTP content
Server Resource Format negotiation instead.

 Parameters:
 user_id, screen_name, cursor, stringify_ids


Page: 28

REST API Example: Twitter II
Request:
GET http://api.twitter.com/1/followers/ids.json?screen_name=fctwitt
Response:
{ To get information about user 143206502 use:
"previous_cursor": 0, GET
"ids": [ /users/lookup.json?user_id=143206502
143206502,
143201767,
777925
],
Note:
"previous_cursor_str": "0",
The service needs authentication
"next_cursor": 0,
that is not part of this example. For
"next_cursor_str": "0"
more information see Twitter API
} doc and the OAuth protocol.

Page: 29

Hands-On JAX-RS Source: http://jcp.org/en/jsr/summary?id=311

RESTful Services in Java
 Java API
defined by JSR 311 called
JAX-RS: The Java API for RESTful Web Services
 Stable version 1.0
 Version 2.0 in progress (started Jan 2011)
 Implementations
 Jersey - http://jersey.java.net/
 Apache Wink - http://incubator.apache.org/wink/
 JBoss Resteasy - http://www.jboss.org/resteasy
 Download example Jersey demo webapp from
 http://jersey.java.net/nonav/documentation/latest/getting-
started.html

Page: 30

Jersey JAX-RS Preparations
 Download and install Eclipse
 http://www.eclipse.org
 Download and install Apache Maven
 http://maven.apache.org/
 Download hello world web app
 https://maven.java.net/service/local/artifact/maven/redirect?r=releases&g=com.sun.jersey.samples&a=hello
world-webapp&v=1.10&c=project&e=zip

 Unzip web app. In web app directory do:
 Create Eclipse project by executing
$ mvn eclipse:eclipse
 Compile and run webb app by
$ mvn clean package jetty:run

Page: 31

Jersey JAX-RS: Step 1
 Create a class that extends Application
javax.ws.rs.core.Application
@ApplicationPath("/")
public class MyApplication extends Application {
Must return the resource classes of the application.
@Override
public Set<Class<?>> getClasses() {
Create a set of resource classes.
final Set<Class<?>> classes = new HashSet<Class<?>>();

classes.add(HelloWorldResource.class); Add resource class.

return classes; Return resource classes.
}
}


Page: 32

 Create HelloWorldResource class
Request URI path of this resource.
Class is a Plain-Old-Java-Object (POJO)
@Path("/helloworld")
public class HelloWorldResource {
HTTP method. Could also be @POST, @DELETE, etc.
@GET
@Produces("text/plain") Format (media type) of
public String getHelloWorldMessage() { data sent in response.
Any method name.
return "Hello World";
}
} Return the plain text as a String.


Page: 33

 Test HelloWorld RESTful Service

Host:Port Webapp name Resource path

curl -i http://localhost:8080/helloworld-webapp/helloworld

HTTP/1.1 200 OK HTTP response code.
Content-Type: text/plain
The content format.
Transfer-Encoding: chunked
Server: Jetty(6.1.24)

Hello World The content.


Page: 34

Jersey JAX-RS: Another
response code
 Change the response code from 200 OK to 500 Internal
Server Error
@Path("/helloworld")

@GET javax.ws.rs.core.Response
@Produces("text/plain")
public Response getHelloWorldMessage() { Set response code.
// Some error
return Response.status(Status.INTERNAL_SERVER_ERROR)
.entity("Ups.")
.build(); Set entity (content) sent
} with the response.
} HTTP/1.1 500 Internal Server Error
Content-Type: text/plain
Service response.
Ups.

Page: 35

Jersey JAX-RS: Return HTML
 Return HTML instead of plain text. Note: Instead of generating
@Path("/helloworld") HTML code like this, modern
public class HelloWorldResource { web frameworks use a
template engine.
@GET Produces “text/html”
@Produces(MediaType.TEXT_HTML)
public Response getHelloWorldMessage() {
StringBuilder html = new StringBuilder(); Create HTML
html.append("<html><body>"); document.
html.append("<h1>Hello World!</h1>");
html.append("</body></html>");

return Response.ok(html.toString()).build();
}
} Return OK with HTML as content.

Page: 36

Jersey JAX-RS: Test HTML
Service
 via cURL
curl –i http://localhost:8080/helloworld-webapp/helloworld
HTTP/1.1 200 OK
Content-Type: text/html

<html><body><h1>Hello World!</h1></body></html>

 via Web Browser


Page: 37

Jersey JAX-RS: Use Path
Parameters
 Return HTML instead of plain text.
Path parameter „msg‟.
@Path("/hello/{msg}")
„msg‟ is mapped from the
URI @Path placeholder.
@GET
@Produces(MediaType.TEXT_HTML)
public Response getHelloMessage(@PathParam("msg") String msg) {
StringBuilder html = new StringBuilder();
html.append("<html><body>"); Insert message.
html.append("<h1>Hello ").append(msg).append("</h1>");
html.append("</body></html>");

return Response.ok(html.toString()).build();
}
} Return OK with HTML as content.

Page: 38

Jersey JAX-RS: Test Path
Parameter
 http://localhost:8080/helloworld-webapp/hello/Uni

 http://localhost:8080/helloworld-
webapp/hello/Paderborn


Page: 39

Jersey JAX-RS: Return JSON
Object
 Return data about a person in JSON format.
Resource URI is now a person‟s name.
@Path("/person/{name}")
public class PersonResource {

@GET Produces “application/json”
@Produces(MediaType.APPLICATION_JSON)
public Response getPerson(String name) throws JSONException {
JSONObject jo = new JSONObject();
jo.put("name", name); Create and return the
jo.put("age", 44); JSON object.
jo.put("height", 1.85);
return Response.ok(jo).build();
}
} HTTP/1.1 200 OK
Response with
name = john
{"name":"john","age":44,"height":1.85}

Page: 40

RESTful Service and Client
Client  Clients retrieve data via
HTTP requests to
User Interface
RESTful services.
 Clients are web enabled
JavaScript devices like web
browsers, smartphones, t
ablets, …
HTML,
HTTP
XML,  Requests are often
Request
JSON performed in the
background.
RESTful Service
 Often JavaScript is used
Server at client-side.

Page: 41

What is JavaScript?
 Official name is ECMAScript
according to the ECMA-262 standard.
 JavaScript refers to the language implementation of ECMA-262 by
Netscape and the Mozilla Foundation.
 It was designed to add interactivity to HTML pages.
 JavaScript is a loosely typed scripting language (a scripting
language is a lightweight programming language).
 JavaScript is an interpreted language (means that scripts are
directly executed without compilation).
 Client-side JavaScript is usually embedded directly into HTML
pages and interpreted by the browser.

Further reading: http://www.ecma-international.org/publications/standards/


Page: 42

JavaScript is NOT…
 JavaScript is not Java!
Java and JavaScript are two completely different languages in both
concept and design!
 JavaScript is not simple!
“JavaScript is a full-featured programming language, as complex
as any and more complex than some.
Using JavaScript for nontrivial tasks may be frustrating without a
solid understanding of the language.”
 JavaScript is not object-oriented!
JavaScript is an object-based language, i.e. it does not support
capabilities of classification, inheritance, encapsulation and
information hiding.
Source: David Flanagan,
JavaScript – The Definitive Guide. O‟Reilly, 2006

Page: 43

JavaScript for typical tasks
 JavaScript gives web engineers a programming tool to
create interactive web sites.
 JavaScript can react to user events
 <div onclick="doSomething();">…</div>
 JavaScript has access to the browser via client
objects, e.g.
 document: content of current HTML document
 navigator: information about used web browser
 JavaScript can add dynamic content to an HTML page:
var h1Element = document.createElement("h1"); Create Elements
var headText = document.createTextNode("Hello");
h1Element.appendChild(headText); Append Elements
Document.appendChild(h1Element);

Page: 44

JavaScript
Short Overview
 Compute table of factorials:
HTML code
<body>
<h2>Table of Factorials</h2>
Embedded JavaScript in HTML page
<script type="text/javascript">

var fact=1; New variable: No static type declaration!

for (i=1; i < 10; i++) { Start loop from 1 to 10

fact = fact*i; Compute and assign next value

document.write(i + "! = " + fact + "<br>");
}
</script> Dynamically write content to HTML page.
</body>www.iks-project.eu

Page: 45

Source and further reading: http://jquery.com/

JavaScript and jQuery
 jQuery is a fast and concise JavaScript Library for
HTML document traversing, event
handling, animating, and interactions.
 Add jQuery to the page:

<html> jQuery is defined and included here
<head> as a separate JavaScript file.
<title>Demo</title>
<script src="jquery.js" type="text/javascript"></script>
</head>
<body>
…
</body>
</html>


Page: 46

Call RESTful Web Service with
jQuery
Perform HTTP REST call using
<script type="text/javascript"> jQuery‟s ajax() operation.
function getData() {
jQuery.ajax({
Specify type, resource URI, and format of REST service.
type: "GET",
url: "http://localhost:8080/helloworld-webapp/person/jim",
dataType: "json",

success: function(data, textStatus, jqXHR) {
alert(data.name + " is + " data.age + " years old.");
},
On success show person‟s data received in JSON format.
error: function(jqXHR, textStatus, errorThrown) {
alert("Ups.");
} On error show a message.
});
}
</script>
www.iks-project.eu

Page: 47

REST for Interactive Web
Applications

Message box with data retrieved
from the server. No page reload!
Click

 RESTful services are a key technology for dynamic and
interactive web applications.

Page: 48

REST and AJAX
Client Browser  Asynchronous
JavaScript
User Interface And XML (or JSON, …)
JavaScript
Call HTML, CSS  AJAX engine processes

JavaScript
HTTP requests
AJAX Engine asynchronously to the
user interface.
HTTP HTML,
Request XML,  RESTful services on the
JSON server
 AJAX is not bound to
RESTful Service
XML – may also be
Server JSON, HTML, Text, …

Page: 49

Lessons Learned ...
 Now you should know ...
 ... the architectural requirements for a semantic CMS.
 ... the integration concept of two loosely coupled columns.
 ... the components of the reference architecture
 ... how the reference architecture model can used to build
a semantic CMS from scratch and how an extended
system can be extended


Designing Semantic CMS - Part II

Recommandé

Recommandé

Contenu connexe

Similaire à Designing Semantic CMS - Part II

Similaire à Designing Semantic CMS - Part II (20)

Designing Semantic CMS - Part II