Project Document Cover Sheet Project Information Project Acronym WebTracks Project Title Web-scale link tracking for research data and publications Start Date 1 Aug 2010 End Date 30 Nov 2011

jumentousmanlyInternet και Εφαρμογές Web

21 Οκτ 2013 (πριν από 3 χρόνια και 5 μήνες)

90 εμφανίσεις



Project Document Cover Sheet

Project Information

Project Acronym

WebTracks

Project Title

Web
-
scale link tracking for research data and publications

Start Date

1
st

Aug 2010

End Date

30
th

Nov 2011

Lead Institution

University of Southampton

Project Director

Simon Coles

Project Manager &
contact details

Brian Matthews

01235 446648 brian.matthews@stfc.ac.uk

Partner Institutions

STFC

Project Web URL

http://webtracks.jiscinvolve.org/wp/

Programme Name
(and number)

Managing Research Data (Citing,

Linking and Integrating Research Data)

Programme Manager

Simon Hodson



Document Name

Document Title

Webtracks
Deliver
able 2.1:
Architecture

and description of
open source packages for InterCom sender and receiver
services.

Author(s)


Shirley Crompton, Brian Matthews

Date

1
8
/0
4
/201
2

Filename


URL

if document is posted on project web site

Access

X Project and JISC internal

X

General dissemination




Document History

Version

Date

Comments


0.1

08/02/2012

Initial version


Shirley Crompton

1.0

18/04/2012

Final version for release: Brian Matthews










Table of Contents


1

Introduction and General Overview

................................
................................
.......

5

1.1

The Webtracks Project
-

Concept and Objective

................................
............

5

1.1.1

Problem Statement

................................
................................
...................

5

1.1.2

InteRCom

................................
................................
................................
.

6

1.1.3

InteRCom Basic Use Case

................................
................................
.......

7

1.1.4

Objective and Key Features of the Webtracks Application

.....................

7

1.2

Availability of the Source Code

................................
................................
......

8

2

General Architecture Overview

................................
................................
..............

9

2.1

The Sender
................................
................................
................................
.......

9

2.2

The Receiv
er

................................
................................
................................
...

9

2.3

The Ping Messages

................................
................................
........................

10

2.4

UML Diagram

................................
................................
...............................

12

2.5

Sending and Receiving Pings

................................
................................
........

14

2.5.1

Sending Pings (full protocol)

................................
................................
.

14

2.5.2

Sending Pings (post only)

................................
................................
......

14

2.5.3

Receiving Pings

................................
................................
.....................

15

2.5.4

Receiver Events Response Codes

................................
..........................

16

2.6

Implementation Guidelines

................................
................................
...........

16

2.6.1

Implemention of the IntercomApp class

................................
................

17

2.6.2

Implementation of One or More Resource Classes

...............................

17

2.6.3

Implementation of the DataFacade Class

................................
..............

18

3

Terminology Applicable to this Document

................................
..........................

18

Acknowledgements

................................
................................
................................
......

18

References

................................
................................
................................
....................

19





Webtracks Architecture

and Implementation



Editors:


Shirley Crompton
<shirley.crompton@stfc.ac.uk>

Brian Matthews
<brian.matthews@stfc.ac.uk>




© Copyright 201
2

Science and Technology Facilities Co
uncil



_____________________________________________________________________


Abstract


The Webtracks Restlet application
is

a Java
programme

built on the Restlet
Framework
vers.
2.0.8

(1)
.

It

provides a lightweight framework for
data repositories
and

management tools to
implement

the InteRCom
(2)

protocol,

another key pr
oduct
of the Webtracks project

(3)
. InteRCom is
a general pu
rpose application layer
protocol for linking digital data resources of any type

using semantically annotated

links.
Webtracks
has a
resource
-
oriented Restful
architecture

(4)

that

uses
uniform
HTTP
method
s

for manipulating
di
gital objects

exposed
as addressable resources
.

It

leverages
the Linked Data
(5)

principle

of identify
ing

web resource
s

with

cool
(6)

opaque

HTTP
URI
s

which can be de
-
referenced to different representations

of the
resource
s
. This

design

permits webtracks to exploit the emergent Linked Data
infrastructure

as websites increasingly offer
machine
-
readable

RDF representations of
their on
-
line resources via
de
-
referenceable

URI
s and content negotiation
.
In the
academic environment,
the
Cross
-
ref
(7)

and
DOI
(8)

web proxies

are
already
linked
-
data enabled, i.e.

they support content negotiation for
Digital Object Identifier (
DOI
)

names
.

This
facility

simpl
if
ies

the
developers


task to implement
a Webtracks
application

as the delivery of RDF metadata c
ould
be delegated to existing
URI
resources.

In addition, the Restlet framework offers comprehensi
ve support for
various types of presentation and persistence technologies, security protocols and
execution environments
. Thereby
further reduces the efforts

required
to
implement

custom W
ebtracks application
s

that are
compatible with

individual resource
owner
s


data services and business policies.




_____________________________________________________________________


1

Introduction

and General Overview

The Webtracks application is an open source product developed by the Webtracks
project

(3)

to facilitate the adoption of th
e Inter
-
Repository Communication protocol
(InteRCom)
.

This document
begins with a summary of the Webtracks concept and
objective (Section
1.1
), followed by a synopsis of the InteRCom protocol (Section
1.1.2

). Section
2

presents
the Webtracks application

architecture
.




1.1

The
Webtracks
Project
-

C
oncept and Objective

Modern research requires the co
-
ordination of a large number of digital objects and
c
ommunication mechanisms.
A typical research life cycle involves
creating

experimental or observation data

using multiple facilities;

refin
ing

raw

data into
derived data
to test hypothes
e
s
;
communicati
ng

and
presenting the
findings in
various

formats



from emails, blog posts, spreadsheets,
and presentations

to scholarly journal
articles
. Each stage of this process typically involves support systems

each with
independent management
such as

repositories, w
ebsites, and data archi
ves.

This
arrangement
often

leads to information silos

with the original connection between
research objects broken as

the context is lost. Even if the linkage information is
preserved, a
ccess is
often
hindered by

disparate authorization policies, proprietary
application

inter
face
s and
heterogeneous
presentation formats
.



To

maximize the value of
a piece of

scientific
work, the connections

between
its
various output
s need to be exposed as
they

capture the evolution of the research in
context.
The creation of a linked web of
data will accelerate the research process as it
will be possible to
trace the usage
of
on
-
line
digital research objects

and transparently
access

them

on the web
. It

will greatly facilitate the

peer
-
review and impact
assessment
processes;

improv
e the

management and re
-
purposing of
data for further
research.


Webtracks’ objective is to develop an approach and mechanism for constructing and
propagating structured information to describe the linkage between research objects
within

the context of academic

activities.


1.1.1

Problem Statement


Research objects are typically spread across a number of different sources which need
to be linked together. Established techniques such as

OAI
-
P
M
H
(9)

and the Linked
Web of Data provide
frameworks
and tools to publish data for linking.

Other
p
rotocols

and technologies

such as
Storelink

(10)
,
Track
B
ack

(11)
, Salmon

(12)

and
Semantic Pingback

(13)

offer

varying

degree of support for the creation and
notification of

citation.
However, there is a
gap between these offerings
and
scientific research data management that requires
identifying and linking the
appropriate d
igital objects in an
op
en

and
easily accessible

manner

which
:




c
apture
s

the
relationship betwee
n research resources in context
;



supports both forward
and

backward citation;



accept
s arbitrary annotations

for

describ
ing

link
s
;



permit
s

the linking of diverse

types of
digital objects within a discipline
;



has a decentralised model
that does not
rely on

a central registry
;



uses the simple but
universal
HTTP protocol

for notifying and manipulating links
.

1.1.2

InteRCom


InteRCom

is a general purpose application layer protocol for linking digital data
resources of any type.

Its design is strongly influenced by the prior work
s

of
CLADDIER

(14)

and Storelink
(10)
. These pr
ojects
recommended a
flexible

Peer
-
to
-
Peer protocol for the propagation of

both forward and backward citation links
between research objects
. Forward citations

are common

in research data
management, for example, data archives uses forward citations to ke
ep track of who
has been using their data resources.




Figure
1
:
An Example Link Assertion.


InteRCom’s

key feature is
the use of

arbitrary RDF to capture

the relationship
between two resources.

A
RDF triple is used to describe a citation
link

(
Figure
1
).
As the Subject and Objects are identified by HTTP URIs,
they are addressable on the
web
.
A

client can
use the uniform HTTP GET method to
obtain a representation of
these resources
without learning any custom API.

In addition,
the link propagator

may use

any vocabular
y

or term to describe the context of a link. Thus, it is possible
to describ
e backward and forward citations through the judicial choice of
link
properties

(
Figure
2
).

Building on this concept,

a

set of semantically

annotated

links

between
data resources forms a graph of citation and provenance that transverses
multiple information spaces

(
Figure
3
).




Figure
2


Examples
of Digital Object Citation Using the Spar
Ontology

(15)
.







Figure
3

Linked Citation Graph of Provenance.


1.1.3

InteRCom

Ba
s
ic
Use Case


Similar to

StoreLink,
InteRCom

is a two stage

protocol

(
Figure
4
)
. Stage 1
(steps 1
-
3)
involves getting
Target metadata and
discovering

its InteRCom
ping
endpoint for
receiving link notification. Stage 2 (step 4) is sending the link to the Target’s recei
ver
using

a

HTTP

Post request which may optionally include

metadata on the Source
object.




Figure
4

A
S
imple
U
se
C
ase
I
llustrating
U
sage of the

InteRCom

2 stage
P
rotocol.


1.1.4

Objective
and Key Features
of the Webtracks Application


The Webtracks application

is an open source application with a BSD license
(16)
. It

provides a template for
research repositories to
fast track
t
heir custom
implementation
of

the InteRCom protocol
,

and
contributes

to a web environment for
the propagation
of

semantically annotated links which c
aptures
research process
es

in context.




The
Webtracks
application
implements

the following key features of the InteRCom
protocol:




Leverages emerging Linked Data environmen
t of identifying and accessing
digital
research

object
s using de
-
referenceable HTTP
-
based
URI
.



Us
es

RDF to describe digital
research

objects and the
ir relationship
s

with each
other
.



Suppo
rts domain agnostic semantic annotation to add context to the link, eg.
Dublin Core
(17)
, SPAR
(15)
.



Permits linkage between any digital research resources, eg. blog posts, data,
publications, exper
iments, etc.



Supports the propagation of
both forward and backward links.

It should be noted
that Webtracks does not assume that the Source resource in
a

link
is
under
Sender’s m
anagement and vice versa. This arrangement permits a forward
citation link
to be propagated by the Object resource in the link.



Uses

a Peer
-
to
-
Peer model
with

each
resource domain (or
info space
)

holding

fragments of RDF graph which can be aggravated to form a
Research
Object

to

describe a particular path

through the linked citation graph. For example, a
Research Object

linking

resources used in the creation of a particular journal
article.



Employs
HTTP
as the basis for message exchange.



Logging of InteRCom events to facilitate event and error tracking.
The two
-
stage
protocol could work or die silently at any point without interfering
with the calling
client’s processing
.



It should be noted that Webtracks is not a complete application on its own. Its
intention is to provide a flexible foundation with
extension points that developers can
complete to achieve the desirable behaviour using the rich features

provided by the
Restlet framework
1
.




1.2

Availability of the Source Code


The Webtracks restlet Core application is available on SourceForge
2

as a open s
ource
Java code.
Further technical information can be obtained with the download bundle
which is available from SourceForge in the form of JavaDoc documentation
; we do
not repeat this technical documentation here for reasons of brevity
.

Also included ar
e
example implementations to include Intercom with the ICAT and ePublications
applications.






1

See:
http://www.restlet.org/about/features

2

https://sourceforge.net/projects/webtracks/


2

General Architecture Overview



Figure
5

InteRCom Model for Link Creation.


The InteRCom

protocol follows the Peer
-
to
-
Peer push notification model. It has
the
notion of a Sender

(Section
2.1
)

and Receiver

(Section
2.2
)
component
s

which are
responsible for posting and receipt of notification
or

ping


(Section
2.3
)

resp
ectively

(
Figure

5
)
.

The remainder of this section presents the main aspects of the Webtracks
architecture.

2.1

The Sender

This component is responsible for sending citation ‘ping’ messages,
retrieving and
optionally
sending metadata of the resource in the link. The role of the Sender to th
e
link
resources will determine the Sender behaviour
. See
Section
2.5

for
a description
of

the Sender’s behaviour.

In Webtracks, the Sender functionality is supported by the
UserAgent Java class.

The UserAgent Sender can be invoked directly by the
repository host application as long as it is within its classpath o
r it can be wrapped as
a
Restlet

service (see the exemplars in
the Webtracks deliverable 2.2 on
Demonstrators
).

2.2

The Receiver

This component receives citation
RDF
‘ping’ messages, extract
s

and persist
s

the

link
and metadata
triples

(if available)

in
to

its knowledge store.
Unlike the RPC
-
style
approach of exposing a single endpoint to process link creation and update
notifications for the whole repository, Webtracks

follows the REST architecture and
takes a resource
-
oriented
approach

of
exposing data rather than internal algorithms.




Figure
6

A Simple Resource Hierarchy for Digital Research Objects and Citation Links.



Figure
6

gives a model for the resources or
domain
data that the Webtracks REST
web services ex
pose.

In the model, a link is

defined as

the child of a digital research
object
. I
f
citation links data

is exposed

as a subordinate URI resource of the digital
research object, the
‘links’

become addressable and can be assessed and manipulated
directly
on th
e we
b. This design helps both to simplify client interactions with the
application and improves connectivity of citation resources on the web.

For instance,
it would be possible for resource owners to provide hypermedia representations that
contains HTTP

links to the referenced resources; other applications can make
mashups of the links resource and for link propagators to modify a link using the
HTTP uniform interface.


Further details on client interactions are given in the
Webtracks deliverable 2.2 o
n Demonstrators.

2.3

The Ping Message
s

The full InteRCom protocol (Section
1.1.3
) has two independent stages:




get Target metadata
and


discover


the location of the notification receiver



transmission of the citation link.


InteRCom uses

the

HTTP uniform
methods

and messages are communicated in XML
formatted RDF
.
As

a general purpose protocol
, it

permits the
use of arbitrary RDF to
capture the re
lationship between two resources (see Section
1.1.2
)
. It
deliberately
does not constrain the metadata being exchanged

except that it must describe

the
location of the notification receiver.

Thus, any suitable vocabulary such as SPAR
(15)
, Dublin Core
(17)

can be used to annotate citation links and
provide
metadata
ab
out digital research obj
ec
t
s
.
However, using common and well understood
ontologies will help ensure the

correct interpretation and usage of the annotated
information
.





Figure
7

XML RDF Response to

a

G
ET

Metadata Request.




Figure
8

XML RDF Message to Post a Link. This example includes metadata

on the link Source
. A minimal post message contain
s just

the citation link.


Figure
7

and
Figure
8

give two examples of RDF ping messages. Both contain the
InteRCom Ping URL prefixed by the InteRCom

namespace. These examples are in a
human
-
readable format, but any valid machine
-
readable RDF XML can be used.


2.4

UML Diagram



Figure
9

Package and Class Diagram for the Webtracks Application


Figure
9

gives
an

UML package
and

class diagram to illustrate the
W
ebtracks
Restlet
application architecture.
Figure
10

shows
the
main aspects of the application
architecture

and

Table
1

gives a description of each class.





Figure
10

Architecture View of the Webtracks Application.




Package

Class

Description

webtracks

IntercomApp.java

An abstract class which encapsulates the
Restlet application object.

webtracks.resources


BaseResource.java

An abstract class that provides common
methods and attributes to the
resources class

hierarchy


UriResource.java

An abstract class that serves as a method stub
for exposing a digital research object as a
Restlet resource
.


LinksResource.java


An abstract class that serves as a method stub
for exposing the child links (see Section
2.2
)
of a digital research object as a Restlet
resource.

webtracks.objects

ObjectsFaçade.java

A façade that specifies common methods
supported by the domain objects.


BaseObject.java

An abstract class providing common attributes
and methods to the
objects
class hierarchy.


ResourceObj.java

A POJO which encapsulates a digital resource
object.

w
ebtracks.
data

DataFacade.java

An abstract class that specifies common
methods for accessing the data layer.

webtracks.intercom

UserAgent.java

This class supports the Sender operations (see
Section
2.1
).

webtracks.utils

AppProSingleton.java

A Singleton utility to configure the application
and provide runtime access to the
configuration properties.


RdfHelper.java

This helper handles common RDF processing,
including the extraction of RDFa

from HTML
representations.


HttpHelper.java

This helper handles common HTTP
operations.

Webtracks.exceptions.*

ObjectsException
.java

This class encapsulates
W
ebtracks

objects
specific exception.


WebtracksException
.java

This class encapsulates
W
ebtracks application
exceptions.


Table
1

A

Descripton of Webtracks Classes.



In a basic scenario

(see
Figure
4
)
, a
p
ing is triggered by
the repository host application
when a new resource is created within its environment. For example, an Electronic
Lab Notebook


(host

application
)
running a data reduction script using raw data

(
the
link object)

from another repository to create new deriv
ed data (
the
link subject).
The host application
triggers

the Webtracks UserAgent
(Sender)
with the citation:


<Subject>


<Property>


<Object>

DerivedDataURI

cito:usesDataFrom

RawDataURI


The UserAgent sends an HTTP GET request to the

link object (R
awDataURI
)

to
obtain metadata and discover its InteRCom ping endpoint followed by a Post request
to the advertised endpoint.

In both steps, the targets of the HTTP calls are
web
services

identified by
HTTP URIs
which

response to the HTTP uniform interfac
e.
The next section provides further details on the how a citation ping is processed.

2.5

Sending and Receiving Pings

The Webtracks application offers different methods for sending pings and these are
described in Section
s

2.5.1

and
2.5.2
. Methods supported by the Receiver (delegated
to the subor
dinate Links resource) are described in Section
2.5.3
.


2.5.1

Sending Pings

(full protocol)



Table
2

UserAgent

(Sender) Get and Post Scenarios.


InteRCom supports the propagation of both backward and forward citation links.
Thus
, the role of the Sender
relative to

the resources in the citation link
will determine
the
UserAgent

(Sender)

behaviour.

The role is det
ermined by comparing the link
resource URI with the host/authority properties provided in the application
configuration file.

Table
2

shows the

different outcome of the get and post operation
according to the

UserAgent

(Sender)
roles
to

the Link resources
.


2.5.2

Sending Pings (post only)


If the
Link Object
’s InteRCom ping endpo
int is known to the client, the
Webtracks
UserAgent can be used to post a citation link
. The Webtracks UserAgent supports
the
following
post only
scenarios:

Link Source

Link
Object

Outcome

Managed by Sender

Managed by Sender

Persists

citation l
ink to local knowledge store.

Managed by Sender

Third Party

The full

protocol is performed:

1.

HTTP GETs
Object

metadata to discover its
official InteRCom ping endpoint.

2.

Persists Object

metadata to local knowledge store.

3.

Retrieves metadata on local Source.

4.

HTTP POSTs citation link and Source metadata to

Object
.

Third Party

Managed by Sender

1.

HTTP GETs Source metadata.

2.

Persists Source metadata to local knowledge store.

3.

Persists

citation l
ink to local knowledge store.

If the link needs to be propagated to the Source, client
should perform a separate Post (see next section).

Third Party

Third Party

The full protocol is performed:

1.

HTTP GETs

Object

metadata to discover its
official Ping endpoint.

2.

HTTP POSTs citation link to the official InteRCom
ping.


Link Source

Link Target

Outcome

-

Managed by Sender

Persists

citation l
ink to local knowledge
store.

Managed by Sender

Third Party

1.

Persists

citation l
ink to local knowledge store.

2.

Retrieves metadata on local Source.

3.

HTTP POSTs citation link

and Source metadata
to Target
.

Third Party

Third Party

HTTP POSTs citation link to Target.


Table
3

UserAgent (Sender) Post Only Scenarios.

2.5.3

Receiving Pings


As described in Section
2.2
, the Receiver functionality is provided by the subordinate
Links Resource of a digital research object.
The Webtracks application provides an
abstract
LinksResource class

which define
s the f
ollowing methods
:



Method

HTTP Method

ContentType


Description

getLinks

GET

Returns
Application/rdf+xml

Gets all the citation links associated with
the parent Resource.

T h e

r e q u e s t U R I
c o n t a i n s

s c o p i n g i n f o r ma t i o n

t h a t

i d e n t i f y t h e p a r e n t
R e s o u r c e.

c r e a t e L i n k s

P OS T

Ac c e p t s

Ap p l i c a t i o n/r d f + x ml

P r o c e s s t h e i n c o mi n g p i n g a n d p e r s i s t s
t h e R DF s t a t e me n t s t o t h e l o c a l
k n o wl e d g e s t o r e.

d e l e t e L i n k

DE L E T E (
X
-
HT T P
-
Me t h o d
-
Ov e r r i d e P OS T
)
*

Ac c e p t s

Ap p l i c a t i o n/r d f + x ml

R e mo v e

a
citation
link specified in the
post RDF.

updateLink

PUT

(
X
-
HTTP
-
Method
-
Override
POST)
*

Accepts

Application/rdf+xml

Update an existing citation link with a
new one as specified in the post RDF.

*
The overrode

Post method is used for these operations. The full resource URI appended with the citation link/s as parameter/s
is likely to

exceed the maximum URI length permitted by most web servers.


Table
4

Receiver Methods.


An implementation is free to realise these methods in line with host
-
specific business
policies. Two exemplars are presented in Section
Error! Reference source not
found.
. Webtracks uses content
negotiation;

a client should set the Acceptable
content
-
type in the request header to
e
nsure that the correct
representation

is
returned
.
This is important as indiv
idual implementation may wish to serve representations

additional to those specified by Webtracks
.








2.5.4

Receiver Events Response Code
s

This section
describes the

HTTP response codes

recommended for use with
Receiver
events
:


202
(“Accepted”
)

T
he
InteRCom
protocol is designed to be
fired

and forgotten

by the Sender
,
the Receiver should return
202 to indicate successful
receipt

of the request
3
.

204

(“
No Content

)

A DELETE or PUT request has been
successful
but

no representation is
being
returned to the client.

400

(
“Bad Request”
)

Use this to indicate
generic
client
-
side error. For example,
the incoming

RDF
is not formatted correctly

or
has missing parameters
.

404 (

Not Found

)

The client requested an URI that does not exist
,

or
,

neither the Source/Object
URIs
of the posted link exist

on the server.

500 (
“Internal Server Error”
)

An application exception has occurred while processing the request.

2.6

Implementation

Guidelines



Figure
11

Webtracks

Extension Points.



Figure

11

illustrates the key extension points in the Webtracks application.

The
application wraps the Restlet framework which
provides various
editions
and plug
-
ins
to support most

network and security
protocols,

technologies and execution
environment
s
.

Building a custom application involves the

main aspects described
below. Detailed information on how to develop a Restlet

application is available from
the Restlet User Guide
(18)
.




3

In this case, t
he request has been received. But it may be subject to repository
-
specific business
policies. ‘202’ is used as you can’t simply just wait for the receiving application to run through as a
huma
n agent may be involved and there may be considerable delay in the process.

2.6.1

Implement
ion of

the IntercomApp class

This class encapsulates the Webtracks Restlet application

object
.
It

can be attached to
one or more
Restlet
Virtual Hosts

which
route calls from Server Connectors to
Restlets.

An Application is
used to manage a portable set of Restlet resources and
provide common services

that
make up an Application’s

operational feature
.

Its
key
components
are described below:



Server and Clien
t Connectors


Declare all connectors
required

by the
A
pplication.
A
C
onnector is a Restlet
software element that manages network communication for a component,
typically by implementing a network protocol (eg. HTTP
, HTTPs, AJP
, SMTP,
FTP, POP, JDBC
).

Restlet offers various
server connectors to suit
most

web
server
platform
s
.

Resources

Attach all Resources

(see Section
2.6.2
)

exposed by the application. A
Resource
is the conceptual mapping to a Representation or set of Representations

and

is

always identified by a URI.


Router

Map URI

routes

and configure the r
outing mode
to the exposed Resources or other
Restlet classes that will handle all requests made to
the

URI
.
Restlet supports

both

cool URIs
(6)

and URI

Templates

(19)
.

Filters

Register

optional

filters to
perform additional pre
-

or post
-
processing on the calls
going through before or after they are actually ha
n
dled by an attached Restlet
.

For example,

Transformer

filter
s are used to map request/response to different
formats.
Authenticator and

Authoriser are

s
pecialised

and

customisable
filter
s

for
authenticat
ing

and authoris
ing

requests. Restlet

supports popular security
protocols such as HTTP Basic and Digest, Amazon S3, OAuth etc.

Verifier

Specify a
n optional

credential Verifier if implementing Security features.

2.6.2

Implement
ation of One or More

Resource
C
lass
es


Resources expose
domain objects to

HTTP requests.

Webtracks provides two abstract
Resource cla
sses which support different parts of the

InteRCom

protoc
ol (see
Figure
4
):




UriResource

:

serves

RDF representation of a digital research object.



LinksResource

:

handles
citation
link update and creation requests.


Both classes
use

Restlet
annotation
s

to mark up a method
to respond to
a
specific
HTTP
operation

and
its supported

request and response media
type
s.

Concrete
subclasses must respect these annotations as they affect method dispatch and the
automatic conve
rsion of
request/response Restlet
representations to Java objects.


A minimal Webtracks implementation should contain a concrete LinksResource
(Receiver, see Section
2.2
) that handles the creation and updates of citation link.
Existing web resources may be used to support the Get metadata operation.
Mechanisms such as server redirect or URI rewrite
may

be
used to hide the
deployment details from the Client
.


2.6.3


Implementation of the DataFacade Class

This is a simple factory that generates data access objects. Implementation
must

realise all the abstract

methods
to support

application
interact
ion
s

with persistent data
and knowledge store
s
.

3

Terminology

Applicable to this Document

Ping

An HTTP Post request send from an InteRCom agent to a server for the purpose of
establishing an explicit relationship between Web resources.


Restlet

In the Restlet

architecture, a Restlet is a dispatcher that provides a context and life
cycle
support. It extends the abstract
Uniform
class

which exposes a uniform
interface as defined by REST.

E v e r y c a l l h a n d l e r s t h a t i s e x p o s e d o v e r t h e
n e t wo r k i s a s u b c l a s s o f R e s
t l e t ( e g. C o n n e c t o r, C l i e n t, S e r v e r, R o u t e r, e t c ) a n d
r e s p e c t s t h i s u n i f o r m i n t e r f a c e. T h i s d e s i g n e n a b l e s R e s t l e t s t o b e c o mb i n e d i n
v e r y s o p h i s t i c a t e d wa y s.


R e s t l e t P r o j e c t

T h e R e s t l e t P r o j e c t

( 1 )

i s a n o p e n s o u r c e p r o j e c t.

It

provides a lightweight but
comprehensive framework for mapping
native
REST concepts to Java classes.


URI

A HTTP
-
based Uniform Resource Identifier that can be de
-
referenced to a digital
representation of a Resource.

URI Template

A URI Template is a
compact sequence of characters for describing a

range of
Uniform Resource Identifiers through variable expansion.


Acknowledgements

The InteRCom protocol is developed as part of the WebTracks Project
[
http://www.jisc.ac.uk/whatwedo/programmes/mrd/clip/webtracks.aspx
] which is
funded by the JISCMRD [
http://www.jisc.ac.uk/whatwedo/programmes/mrd.aspx
]
Programme
.




References

1.
The Restlet Project.

Restlet.
The Restlet Project.
[Online] 2.0.8, Noelios Technologies,
2011. http://www.restlet.org.

2.
STFC E
-
Science Centre.

The Inter
-
repository Communication Protocol.
InteRCom
Specification.
Warrington

: Science and Technology Facilities Council, 2011.

3.
STFC.

Webtracks.
Webtracks.
[Online] JISC, 2011.
http://www.jisc.ac.uk/whatwedo/programmes/mrd/clip/webtracks.aspx.

4.
Ian
Jacobs.

Architecture of the World World Wide, Volume One.
Architecture of the
World World Wide.
[Online] 2001. http://www.w3.org/2001/tag/webarch/.

5.
C. B
izer,
T. Heath, T. Berners
-
Lee

Linked Data
-

The Story So Far.
International
Journal on Semantic Web and Information Systems, 2009, Vol. 4, pp. 1
-
22.

6.
Leo Sauermann, Richard Cyganiak, Danny Ayers, Max Volkel.

Cool URIs for the
Semantic Web.
W3C.
[Online] 2008.

http://www.w3.org/Provider/Style/URI.

7.
Geoffrey Bilder
.

Content Negotiation for CrossRef DOIs.
Cross Ref.
[Online] 19 April
2o11.
http://www.crossref.org/CrossTech/2011/04/content_negotiation_for_crossr.html.

8.
The International DOI Foundation.

DOI Sys
tem and Linked Data.
DOI System.
[Online] 20 April 2011. http://www.doi.org/news/DOINewsApr11.html#2.

9.
Open Archives Initiative.

Open Archives Initiative Protocol for Metadata Harvesting.
Open Archives Initiative .
[Online] 2011.
http://www.openarchives.org/pmh/.

10.
BM Matthews, A Duncan, CM Jones,
C Neylon,

S Coles, M Borkum,
P Hunter
.

A Protocol for Exchanging Scientific Citations.
Fifth IEEE International Conference
on e
-
Science, 2009. e
-
science. pp. 171
-
177.

11.
Sixapart.com.

TrackBack Technical Specification.
Trackback.
[Online] 2011.
http://www.sixapart.com/pronet/docs/trackback_spec.

12.
John
Panzer.

Salmon Protocol.
Salmon.
[Online] 2011. http://www.salmon
-
protocol.org.

13.
Sebastian
Tramp.

Semantic Pingback.
Semantic Ping
back Project.
[Online] August
2011. http://aksw.org/Projects/SemanticPingBack.

14.
BM Matthews, K Portwin, CM Jones, B

Lawrence.

Recommendations for
Data/Publication Linkage, CLADDIER Project Report III.
BADC.
[Online] Nov 2007.
http://claddier.badc.ac.uk/
trac/attachment/wiki/WikiStart/Report_III_Recommendatio
nsForDataLinking
-
final.doc.

15.
David
Shotton.

Introducing the Semantic Publishing and Referencing (SPAR)
Ontologies.
SPAR.
[Online] August 2011.
http://opencitations.wordpress.com/2010/10/14/introduci
ng
-
the
-
semantic
-
publishing
-
and
-
referencing
-
spar
-
ontologies/.

16. BSD License.
Open Source Initiative .
[Online] 2012.
http://www.opensource.org/licenses/BSD
-
3
-
Clause.

17. Dublin Core Metadata Specifications.
Dublic Core Metadata Initiative.
[Online] 2011.
http://dublincore.org/specifications/.

18.
Jerome Louvel
.

Restlet Framework
-

User Guide
-

Version 2.1.
[Online] 2011.
http://wiki.restlet.org/books/restlet_framework_
-
_user_guide_
-
_version_21
--
20110802
-
113922/publications/html
-
chunked/output/index.html.

1
9.
J. Gregorio, R. Fielding, M. Hadley, M. Nottingham, D. Orchard.

URI Template.
Network Working Group Internet
-
Draft.
[Online] 2008. http://tools.ietf.org/html/draft
-
gregorio
-
uritemplate
-
08.

20.
ST
FC E
-
Science Cent
r
e
.

ePublication Archive.
ePublication Archive.
[Online]
http://epubs.stfc
.ac.uk/.

21.
Freemarker Project.

FreeMarker.
http://freemarker.sourceforge.net/.
[Online]
http://freemarker.sourceforge.net/.

22.
IFLA Study Group.

Functional Requrieemnts for Bibliographic Records.
Internati
onal Federation of Library Associations .
[Online] 1998.
http://www.ifla.org/en/publications/functional
-
requirements
-
for
-
bibliographic
-
records.

23.
B. Matthews, S. Sufi, D. Flannery, L. Lerusse, T. Griffin, M. Gleaves, K. Kleese.
Using a Core Scientific Me
tadata Model in Large
-
Scale Facilities.

s.l.

: IDCC, 2009.
5th International Digital Curation Conference.





Appendix 1:
Example PUT Request RDF


The Put request RDF uses the Dublin Core Terms ‘replaces’ to identify the new and
superseded citation link
s.