WEB SERVICE CAPABILITY META MODEL

Sami Bhiri, Wassim Derguech and Maciej Zaremba

Digital Enterprise Research Institute, National University of Ireland, Galway, Ireland

Keywords:

Capability Modelling, Web Services, Business Process, RDF.

Abstract:

The concept of capability is a cornerstone element in service description. Nevertheless, despite its fundamental

role little effort has been seen to model service capabilities. Current approaches either fail to consider capa-

bilities as feature-based entities and confuse them with annotated invocation interfaces or fail in modelling

capabilities at several abstraction levels and establishing links between them. In particular, they are not able

to model and deal with concrete capabilities (i.e., capabilities that reﬂect real customers’ needs). In this paper,

we propose a conceptual model as an RDF-schema for describing service capabilities. Our model deﬁnes

capabilities as an action verb and a set of attributes and their values. It is also able to deﬁne capabilities at

different levels of abstractions/concreteness and establish links between them. Most importantly, our model

enables describing concrete capabilities which directly correspond to consumer needs. Our meta model is

based on RDF and makes use of Linked Data to deﬁne capability attributes as well as their values.

1 INTRODUCTION

From IT perspective, the concept of service has

evolved from the notion of remote invocation inter-

face (such as WSDL) to a more comprehensive en-

tity. In this paper, we share the same vision of OASIS

Reference Model

and consider a service as an ac-

cess mechanism to a capability. Within this vision the

invocation interface is only one aspect of the whole

service description. Another core aspect of a service,

in which we are interested in this paper, is the notion

of capability which describes what a service can do.

The notion of capability is a fundamental concept

not only for SOA (Service Oriented Architecture) but

also for enterprise information systems. The ARIS

architecture (Scheer and Schneider, 2006) recognizes

the importance of the functional perspective in en-

terprise information systems and considers it as one

of its views. The concept of capability is the glue

point between services and business processes. A ser-

vice gives access to a certain capability which can be

achieved by a business process. Despite its impor-

tance, this concept has not drawn the research com-

munity attention as it deserves. Current approaches

for capability modeling were in fact part of efforts for

describing related concepts such as business process-

OASIS Reference Model for Service Ori-

ented Architecture 1.0, http://www.oasis-

open.org/committees/download.php/19679/soa-rm-cs.pdf

es, service descriptions and search requests.

A capability denotes what an action does either in

terms of world effects or returned information

. In

the literature, we can distinguish three families of ap-

proaches that tackled the problem of capability mod-

elling either directly or indirectly. The ﬁrst family in-

cludes semantic Web services models (WSMO (Ro-

man et al., 2006) and OWL-S (Martin et al., 2007))

which model capabilities as Input, Output, Precon-

ditions and Effects (IOPE paradigm). Modelling ca-

pabilities following the IOPE paradigm does not al-

low to capture different levels of abstractions of capa-

bilities, easily, and consequently cannot capture any

link between them. In particular, these approaches are

not suitable for modelling concrete capabilities espe-

cially when they are highly conﬁgurable. Moreover,

they do not feature in an explicit and easily accessible

way domain-specifc features of the capabilities which

makes their discovery difﬁcult and heavily dependant

on reasoning.

The second family of related efforts concern se-

mantic annotations of invocation/interaction inter-

faces (SA-WSDL and SA-REST) (Kopeck

y et al.,

2007b; Lathem et al., 2007). While these approaches

do not directly target capability modelling, they at-

tempt to provide alternative solutions to top-down se-

mantic approaches (WSMO and OWL-S) by starting

from existing descriptions such as WSDL and an-

notate them with semantic information. These ap-

Bhiri S., Derguech W. and Zaremba M..

WEB SERVICE CAPABILITY META MODEL.

DOI: 10.5220/0003935800470057

In Proceedings of the 8th International Conference on Web Information Systems and Technologies (WEBIST-2012), pages 47-57

ISBN: 978-989-8565-08-2

 2012 SCITEPRESS (Science and Technology Publications, Lda.)

proaches deﬁne a semantic (business) description of

syntactic interaction interfaces.

The third family includes frame-based approaches

for modelling capabilities. Oaks et al., (Oaks et al.,

2003) give a nice overview of related approaches and

propose a model for describing service capabilities

following the same principle. The proposed model

distinguishes in particular the corresponding action

verb and informational attributes (called roles in the

paper (Oaks et al., 2003)) in addition to the classical

IOPE. While this model makes a step beyond the clas-

sical IOPE paradigm, the semantics of capabilities re-

main deﬁned via the IOPE paradigm and therefore has

the same problems as the ﬁrst family of approaches

described above.

In this paper, we propose an alternative approach,

to the classical IOPE paradigm, for modelling capa-

bilities. The semantics of a capability is not captured

at a ﬁne-grain level via preconditions and effects. It is

rather captured at a coarse-grain level via a combina-

tion of (shared meaning of) an action verb, semantic

links to other capabilities (which can be deﬁned in an

ontology) and, particularly, a set of domain-speciﬁc

attributes which reﬂect the business features of the ca-

pability. Interestingly enough, our model enables to

capture capabilities at different levels of abstraction

and establish links between them. Concrete capabil-

ity descriptions are generated dynamically from more

abstract capability descriptions.

The remainder of the paper is organized as fol-

lows. Section 2 motivates our work. Section 3

presents our conceptual model for describing capabil-

ities, introduces our attribute-featured principle and

details the different types of attributes we consider.

It shows also how abstract capabilities can be de-

ﬁned while respecting the attribute-featured principle

and serving as declarative speciﬁcations for generat-

ing concrete capabilities. Section 4 shows how we

distinguish different levels of abstractions and shows

the relation that may exist between abstract and con-

crete capabilities and presents semantic links that may

exist between them. Section 5 illustrates the relation

between the customer request and the capability cat-

egories and offers by sketching a matching scenario

between the customer request and the capability cat-

egories. Section 6 discusses some related work and

Section 7 concludes our paper.

2 MOTIVATION

A capability corresponds to what an action (a pro-

gram, a task, a Business Process etc.) does from a

functional perspective. There are different levels of

abstraction/concreteness of capabilitiess. A capability

can be as abstract as a category and denotes a class of

actions, as it can be very concrete and corresponds to

a speciﬁc consumer request. For instance the category

“Shipping” that denotes all functions for shipping is a

capability. “Shipping a package of 10 Kg from Ire-

land to Singapore on the 15

of January 2012 for the

price of 200 Dollars” is also a capability but less ab-

stract than the previous one.

In real world settings it is quite often very hard,

even impossible, to model statically concrete capabil-

ities due to the following reasons:

• Combinatory explosion: at concrete level, one

needs to take care of all possible combinations

which may lead to a combaniatory explosion of

capabilities (services). For example, a shipping

service serves only certain routes (combination of

the source and destination attributes). Deﬁning

statically the corresponding concrete capabilities

means deﬁning a capability for each route.

• Dynamicity: an aspect of a given capability (the

value of an attribute) may depend on a dynamic

variable. For instance, the price of a concrete

shipping capability may depend on the exchange

rate or on the company workload.

• Sensitivity: for business reasons, providers do not

want to reveal the values of certain sensitive at-

tributes as part of the static service description.

They rather require to engage in a certain interac-

tion before revealing the concrete value of a sen-

sitive attribute.

In this paper, we propose a solution to the above

mentioned problems. We propose a conceptual

model, as an RDF-Schema, for describing capabili-

ties. Our meta model deﬁnes capabilities as an ac-

tion verb and a set of domain-speciﬁc attributes. It is

also able to describe capabilities at different levels of

abstractions/concreteness and establish links between

them. Most importantly, our model enables describ-

ing concrete capabilities which are directly consum-

able by and delivered to consumers contrary to cur-

rent meta models which describe the abstractions of

these descriptions. Our model enables taking into ac-

count attributes dynamicity, sensitivity and interde-

pendency. Our model is based on RDF and makes

use of Linked Data to deﬁne capabilities attributes as

well as their values.

Throughout the whole paper, we will consider the

shipping domain for illustrating several parts of our

conceptual model. In such domain, from the ser-

vice consumer perspective, it is much more valuable

to operate on concrete, consumable shipping offers

such “Shipping using FedEx Europe First, price 100

WEBIST2012-8thInternationalConferenceonWebInformationSystemsandTechnologies

EUR, from Germany to Ireland, delivery within 1 day”

rather than to operate on abstract service descriptions

such “FedEx shipping company ships packages up

to 68 Kg, between various source and target desti-

nations”. Current service descriptions require man-

ual work in order to move to the service offer level.

Our conceptual model aims at making this step auto-

mated.

3 CAPABILITY META MODEL

In this Section, we introduce the concept of capability,

then we explain our attribute-featured principle that

we consider for modelling the capability attributes

and we present the possible attribute types covered by

our meta-model.

Deﬁnition 1 introduces the concept of capability

in our meta-model.

Deﬁnition 1. (Capability) A tuple Cap = (Action-

Verb,Attributes) is a capability, where:

• ActionVerb: This concept has been previously in-

troduced by (Oaks et al., 2003) in order to de-

ﬁne, in a natural language, what is the action be-

ing described. Different to (Oaks et al., 2003), we

consider the action verb as a concept from a do-

main related ontology that comes form a shared

aggreeement on its semantics.

• Attributes: Represents a set of pairs (Attribute, At-

tributeValue) that corresponds to the set of char-

acteristics of the capability. An Attribute corre-

sponds to a particular property of the capability

and AttributeValue corresponds either to the value

or the possible values that this Attribute can have.

Figure 1 shows a detailed UML class diagram of

the capability metal model. It depicts the concepts

previously introduced (i.e., Capability, ActionVerb,

Attribute and AttributeValue) as well as other ones

that will be introduced in the rest of this section.

Additionally, in our work, we distinguish between

several abstraction levels of capabilities. As shown

in Figure 1, we consider the relations “specify” and

“extend” to express the relations between capabilities.

These relations will be detailed later in this paper.

In the rest of this section, we will discuss our

attribute-featured principle in Section 3.1 as well as

the possible AttributeValue types in Section 3.2. Sec-

tion 4, will deﬁne the capability abstraction relations.

3.1 Attribute-featured Principle

We have, recently, noticed a wide adoption of the

Linked Data (Bizer et al., 2009; Sheridan and Tenni-

son, 2010) principles, and a growing amount of data

sets speciﬁed in RDF. It is clear that Linked Data pro-

vides the best practices for publishing structured data

on the Web. Linked Data is published using RDF

where URIs are the means for referring various en-

tities on the Web giving the possibility to interlink

them. Currently, organizations are highly interested

in publishing their data in RDF (Lebo and Williams,

2010) as well as various public vocabularies (ontolo-

gies) are being released. Consequently, we have de-

cided to deﬁne our meta model based on RDF and

make use of Linked Data principles in order to deﬁne

capability attributes as well as their values. Listing 1

shows a fragment of the capability Ontology in RDF

using a human readable N3 notation.

In Listing 1, we deﬁne the concept cap:Capability

as an rdfs:Class. We deﬁne the concept

cap:ActionVerb as a sub class of skos:Concept.

“The skos:Concept class allows to assert that a

resource is a conceptual resource. That is, the

resource is itself a concept.”

. And we deﬁne the

concept cap:AttributeValue as an equivalent class to

owl:Thing because we need it to be the most general

class to allow for the reuse of existing vocabularies

for possible attribute values for example using vcard

open vocabulary for deﬁning addresses.

Listing 1: Capability ontology snippet.

 

1 @ pre f i x r d f : <h t t p : / / www. w3 . o rg / 1 9 9 9 / 0 2 /

2 22− r d f −sy n t a x −ns #>.

3 @ pre f i x owl : < h t t p : / / www. w3 . o r g / 2 0 0 2 / 0 7 / owl

#>.

4 @ pre f i x r d f s : <h t t p : / / www. w3 . o r g / 2 0 0 0 / 0 1 /

5 r d f −sche ma #>.

6 @ pre f i x s k o s : < h t t p : / / www. w3 . o r g / 2 0 0 4 / 0 2 / s k os

7 c o re #>.

8 @ pre f i x ca p : < h t t p : / / . . . / o n t ol o g y / c a p a b i l i t y

#>.

10 ca p : C a p a b i l i t y a r d f s : C l a s s .

12 ca p : Ac t i o n V e r b r d f s : s u bC l as s Of sk o s : Co n ce p t .

14 ca p : A t t r i b u t e V a l u e owl : e q u i v a l e n t C l a s s owl :

Th i ng .

16 ca p : do a r d f : P r o p e r t y ;

17 r d f s : do main ca p : C a p a b i l i t y ;

18 r d f s : r a n g e c ap : A c t i o n V e r b .

20 ca p : a t t r i b u t e a r d f : P r o p e r t y ;

21 r d f s : do main ca p : C a p a b i l i t y ;

22 r d f s : r a n g e c ap : A t t r i b u t e V a l u e .

 

SKOS Core Guide, W3C Working Draft 2 November

2005, http://www.w3.org/TR/2005/WD-swbp-skos-core-

guide-20051102/

WEBSERVICECAPABILITYMETAMODEL

0..1

extends

Capability

0..1

specifies

ActionVerb

Attribute

0..*

AttributeValue

RangeValue

ConstrainedValue

Constrain

-ExprType : string

-ExprValue : string

Expression

DynamicValue

EnumerationValue

ConditionalValue

hasExpression

hasMin

hasMax

constrainedBy

hasElement

hasEvaluator

hasEvaluator hasCondition

Figure 1: Capability UML class diagram.

The property cap:do allows linking a

cap:Capability to its corresponding cap:ActionVerb.

We created the property cap:attribute even though we

are going to redeﬁne it for each created attribute its

corresponding range. This will have the advantage to

create properties where the domain is always set to a

cap:Capability. In other words, all attributes that will

be created as an rdfs:subProperty of cap:attribute

will be interpreted as a property of a capability.

We can deﬁne a domain related ontology in order

to deﬁne a particular capability (i.e., its action verb

and attributes). Taking as example the shipping do-

main, Listing 2 shows a snippet of such ontology. In

order to deﬁne the action verb, we use skos:prefLabel

(Line 6). The rest of the listing illustrates how

two attributes cap:from and cap:pickUpDate are de-

ﬁned in our shipping ontology. Both attributes are

rdfs:subProperty of cap:attribute (Line 8 and 11).

The range of the attribute cap:from is

vcard:VCard to refer to an address. The range

of the attribute cap:pickUpDate is a concept deﬁned

in the same shipping ontology. Other attributes in

subsequent listings are deﬁned similarly.

Listing 2: Shipping domain ontology snippet.

 

1 @ pre f i x v ca rd : < h t t p : / / www. w3 . o r g / 2 0 0 6 / v c a rd

/ n s #>.

2 @ pre f i x ca p : <h t t p : / / . . . / o n t o lo g y /

c a p a b i l i t y #>.

3 @ pre f i x s h i p : <h t t p : / / . . . / o n t o l og y /

s h i p d o m ai n #>.

5 : sh i p m e n t a c a p : A c t i o n V e r b ;

6 s k o s : p r e f L a b e l ‘ ‘ Shi p ’ ’ .

8 s h i p : fr om r d f s : s u b P r o p e r t y ca p : a t t r i b u t e ;

9 r d f s : r a n ge v c a r d : VCard .

11 s h i p : p i ckU p Da t e a r d f s : s u b P r o p e r t y c ap :

a t t r i b u t e ;

12 r d f s : r a n ge s h i p : d a t e .

 

3.2 Attribute Value Types

This section details how the set of attributes of a cer-

tain capability can be deﬁned from a service provider

perspective. As depicted in Figure 1, we consider ﬁve

classes used for describing the values of a capability

WEBIST2012-8thInternationalConferenceonWebInformationSystemsandTechnologies

attributes.

Using these classes separately or in combination,

a capability can specify (i) the possible values at-

tributes can have, (ii) and how to compute their val-

ues. We use a capability, called BlueCap, as an exam-

ple to illustrate the use of these classes. Before detail-

ing these classes, we need to introduce the concepts of

Constraint and Expression which some attribute val-

ues may refer to.

3.2.1 Constraint and Expression

A constraint enables to specify the possible values an

attribute can have. The class Constraint represents

all constraints. The class Expression enables to spec-

ify expressions among them the value of a given con-

straint. The class Expression has two attributes/prop-

erties, ExprType which speciﬁes the type of the ex-

pression and ExprValue which deﬁnes the expression

itself. The type of the expression, ExprType, indi-

cates how to build the corresponding queries during a

matching process. Currently, the only type of expres-

sion our meta model supports is SPARQL (queries).

Listing 3 shows an example for expressing a con-

straint on the weight of the package. The constraint

PackgConstraint is deﬁned in line 1. This constraint

has an expression of type SPARQL. The value of the

constraint expression (line 6) indicates that the weight

of the package has to be lower than or equal to 50 Kg.

Listing 3: Example of a constraint.

 

1 : P c k g C o n s t r a i n t a ca p :

C o n s t r a i n t ;

2 ca p : h a s E x p r e s s i o n :

P c k C o n s t r a i n t E x p r .

4 : P c k g C o n s t r a i n t E x p r a ca p :

E x p r e s s i o n ;

5 ca p : ex p rT y p e ”SPARQL ” ;

6 ca p : e x p r V a l ue ” ? we i g h t

=< 5 0?

7 && ? we i g h t U n i t =

d b p e di a :KG” .

 

3.2.2 Constrained Value

The class ConstrainedValue enables deﬁning the pos-

sible values an attribute can have by specifying a set

of constraints on its value. As depicted in Figure 1,

a ConstrainedValue is constrained by a set of con-

straints. Listing 4 shows how BlueCap can specify

that it can ship packages of weight under 50 Kg. The

value X, of the attribute Item, is a ConstrainedValue

(lines 1 and 3). X is constrained by the constraint

PckgConstraint (line 6) which is detailed in Listing 3.

Listing 4: Example of a constrained value.

 

1 : Bl ueC ap s h i p : It e m :X .

3 : X a s h i p : Packa ge , ca p :

C o n s t ra i ne d V a l u e ;

4 s h i p : h a s W e i ght [ s h i p : ha s V a l u e ?

w e i g h t ;

5 s h i p : h a s Un i t ?

w e ig h t U ni t ] ;

6 ca p : c o n s t r a i n e d B y :

P a c k g C o n s t r a i n t .

 

3.2.3 Dynamic Value

A DynamicValue deﬁnes how to compute the value

of an attribute which value depends on (i) consumer

provided attributes, (ii) dynamic values, or (iii) hid-

den variables. As shown in Figure 1 a DynamicValue

refers to an expression that deﬁnes how to compute it.

Listing 5 shows an example of how to compute

the shipping price. The value Y, of the attribute price,

is a DynamicValue. It has as evaluator the expression

PriceExpression (lines 6) which is a SPARQL expres-

sion (line 9). Line 10 speciﬁes the formula for com-

puting the price based on the weight of the package.

Listing 5: Example of a dynamic value.

 

1 : Bl ueC ap s h i p : p r i c e :Y.

3 : Y a s h i p : S h i p p i n g P r i c e , c ap :

Dyn ami cValue ;

4 s h i p : h a s V al u e ? p r i c e ;

5 s h i p : h a s Un i t d b p e di a : USD ;

6 ca p : h a s E v a l u a t o r : P r i c e E x p r e s s i o n .

8 : P r i c e E x p r e s s i o n a cap : E xp r es s i o n ;

9 ca p : h a sT y pe ”SPARQL ” ;

10 ca p : e x p r V a l ue ” ? p r i c e : =

11 f n : c e i l i n g ( ? w e i g h t )

∗ 5 .5 + 41 ” .

 

3.2.4 Conditional Value

A ConditionalValue assigns an Attribute Value to the

corresponding attribute if a certain condition holds.

As shown in Figure 1, a ConditionalValue has a con-

dition expressed as a constraint and an element which

corresponds to the corresponding attribute value.

Listing 6 gives an example showing how to spec-

ify a shipping price when the target country is a Eu-

ropean country. The value Y, of the attribute price, is

a ConditionalValue (lines 3). It assigns the Attribute

Value, EuropeanPrice (line 6), when the PriceCon-

dition holds (line 5). PriceCondition is a Constraint

which requires that the target country is in Europe

(Lines 8-12). EuropeanPrice is a DynamicValue (line

WEBSERVICECAPABILITYMETAMODEL

14) and has as evaluation expression PriceExpression

(line 15) which is detailed in Listing 5.

Listing 6: Example of a conditional value.

 

1 : Bl ueC ap s h i p : p r i c e :Y.

3 : Y a s h i p : S h i p p i n g P r i c e , c a p :

C o n d i t i o n a l V a l u e ;

4 s h i p : h a s V al u e ? p r i c e ;

5 ca p : h a s C o n d i t i o n :

P r i c e C o n d i t i o n ;

6 ca p : h a s E l e m e n t : E u r op e a n Pr i c e

8 : P r i c e C o n d i t i o n a cap : C o n s t r a i n t ;

9 c ap : h a s E x p r e s s i o n [ cap : h a sT ype ”

SPARQL” ;

10 ca p : h a s V a l u e ”?

t r g C o u n t r y

11 s k o s : s u b j e c t

d bped i a −

12 c a t : E u r ope a n

c o u n t r i e s ” ] .

14 : E u r o p e an P r i ce a ca p : Dy nam icValue ;

15 ca p : h a s E v a l u a t o r :

P r i c e E x p r e s s i o n .

 

4 DIFFERENT LEVELS OF

ABSTRACTIONS

In our meta model the semantic of a capability derives

not only from the Action Verb concept but also from

its relations (semantic links) with other capabilities.

These relations are established based on capabilities

attributes for some, and on their attribute values for

others.

As mentioned above, capabilities can be deﬁned

at several abstraction levels. A capability that is pro-

posed to an end user is actually the least abstract (i.e.,

a concrete) capability that we call Capability Offer.

In contrast, each abstract capability is called Capabil-

ity Category. Navigation between different abstrac-

tion levels is made through semantic links between

the various capabilities.

In this paper, we present three special relations:

variantOf, specifies and extends, which enable

deﬁning a hierarchy of capabilities in a given domain,

from the most general and abstract one to the most

concrete ones. Deﬁnitions 2, 3 and 4 deﬁne respec-

tively the relations variantOf, specify and extend.

Please note:

• For abbreviation purposes and by misnomer we

say that a certain capability cap has an attribute

at.

• We refer to the attribute at of cap by cap.at.

• We refer to the set of attributes of cap by

cap.attributes.

• We say that two capabilities cap

and cap

(or

more) share the same attribute at if both of them

have the attribute at (but possibly with a different

value).

Deﬁnition 2. (variantOf) this relation holds between

two resources (A capability is itself a resource.).

It uniﬁes, in fact, the two properties rdf:type and

rdfs:subClassOf

. A resource r

variantOf a re-

source r

if r

is an instance (rdf:type) or a subclass

(rdfs:subClassOf ) of r

Deﬁnition 3. (speciﬁes) Given two capabilities cap

and cap

, cap

specifies cap

if (i) all the attributes

of cap

are also attributes of cap

(In other terms

cap

inherits all the attributes deﬁned in cap

), (ii) for

every shared attribute at, the value of cap

.at is either

equal to or variantOf the value of cap

.at, and (iii)

there exists at least one shared attribute at’ such that

the value of cap

.at

variantOf cap

.at

Deﬁnition 4. (extends) Given two capabilitites cap

and cap

, cap

extends cap

if (i) cap

has all the

attributes of cap

and has additional attributes, and

(ii) for every shared attribute at, the value of cap

.at

is equal to the value of cap

.at.

The relations specifies, extends enable deﬁn-

ing a hierarchy of capabilities. In Figure 2, we show

an example of a hierarchy of capability descriptions.

As a root of this hierarchy, we deﬁne Capability A. It

represents an abstract capability description for ship-

ping goods from any source and destination at an in-

ternational scale. This capability can be extended ei-

ther to Capability B or Capability C. Both extend the

initial capability by 1 or 2 attributes. As an exam-

ple of speciﬁcation relation between capabilities, we

refer to the link between Capability D and Capability

B. Capability D speciﬁes Capability B as it becomes a

European shipping capability instead of International.

It is also quite clear that Capability E extends Capa-

bility D.

Similar to domain ontologies which deﬁne shared

concepts and shared attributes/properties, top level ca-

pability in a given domain can also be deﬁned as an

ontology where an agreement about their meaning is

reached and shared. Like any other ontology con-

cepts, this capability top level layer can be reused to

deﬁne other capabilities.

While this coarse-grain semantics is adequate for

conducting discovery, it is insufﬁcient when auto-

We consider instantiation a special kind of sub class-

ing where the instance is in fact no more than a sub class

(subset) with only one element.

WEBIST2012-8thInternationalConferenceonWebInformationSystemsandTechnologies

Capability B

(e.g., an International

shipping service for

packages and documents)

Action Verb = “ship”

From = International

To = International

MaxWeight = “68 Kg”

Capability A

(e.g., an International

shipping service)

Action verb = “ship”

From = International

To = International

Capability C

(e.g., an International

heavyweight and freight

shipping service)

Action Verb = “ship”

From = International

To = International

MaxWeight = “1 t”

MinWeight = “68 Kg”

Capability D

(e.g., a European shipping

service for packages and

documents)

Action Verb = “ship”

From = Europe

To = Europe

MaxWeight = “68 Kg”

Capability E

(e.g., a European shipping

service for packages and

docs with pick up option)

Action Verb = “ship”

From = Europe

To = Europe

MaxWeight = “68 Kg”

PickUpDate = Date

Figure 2: Example of shipping capabilitities hierarchy.

mated chaining is required such as in composition

and planning scenarios. By coarse grain semantics we

mean deﬁning shared agreement on coarse grain enti-

ties such as capability in our case. Automated chain-

ing requires ﬁner-grained semantics. For that pur-

pose, we consider two additional attributes cap:before

and cap:after. That we are not discussing in detail in

this paper. But simply put, taken together these two

attributes capture the change to the state of the world

that the corresponding action performs.

5 CUSTOMER REQUEST,

CAPABILITY CATEGORY AND

CAPABILITY OFFER

An important concept, complementary to the concept

of capability in many scenarios, is the concept of Con-

sumer Request which speciﬁes what the client wants

to achieve. This concept deserves a conceptual model

for its own. In the following, we need to refer to some

parts of the customer request, in an informal way, to

show the interplay between it and capabilities. But we

do not elaborate beyond that informal description.

In order to illustrate the relation between capabil-

ity category, offer and customer request, we give an

overview of the matching process between a customer

request and a capability category. The purpose is not

to cover in detail the matching or discovery phase.

Let’s consider for our case a shipping company

called Blue that has a special shipping offer called

BlueOffer. Listing 7 illustrates how we can deﬁne

the capability BlueOffer according to our capability

model. BlueOffer consists of offering: “a shipping

service from Ireland to Singapore of a package of 10

Kilograms. The shipping will cost 200 USD and the

package will be delivered the earliest on the 12th of

December 2011.”

The description of concrete capabilities such as

BlueOffer (See Listing 7) depends on the correspond-

ing customer request. More speciﬁcally the values

of certain attributes are in fact deﬁned in the cus-

tomer request. For instance the values of the attributes

ship:from and ship:to of the capability BlueOffer (de-

scribed in Listing 7) are speciﬁed in the given cus-

tomer request.

Before going into detail about the matching phase

(See Section 5.2), we need to introduce the attribute

types based on who is providing the value of that at-

tribute in Section 5.1.

Listing 7: BlueOffer capability description snippet.

 

1 : b l u e O f f e r a ca p : C a p a b i l i t y ;

3 ca p : do [ a c ap : A c t i o n V e rb ;

4 s k o s : p r e f L a b e l ‘ ‘ Shi p ’ ’ ] ;

6 s h i p : fr om [ a s h i p : S o u r c e Ad d re s s ;

7 v c a r d : a d d r e s s d b p e d ia :

I r e l a n d ] ;

9 s h i p : t o [ a s h i p : T a r g e t A d d re s s ;

10 v c a r d : a d d r e s s d b p e d ia :

S i n g a p o re ] ;

12 s h i p : i te m [ a s h i p : P a c k ag e ;

13 s h i p : ha s W e igh t [ s h i p :

h a s V a l u e 1 0;

14 s h i p : h a sU n i t d b pe di a :

Ki l o gra m ] ] ;

16 s h i p : p r i c e [ a s h i p : S h i p p i n g P r i c e ;

17 s h i p : h a s Va l u e 20 0 ;

18 s h i p : h a s Un i t d b p e di a :

USD ] ;

20 s h i p : d e l i v e r y D a t e [ a s h i p :

S h i p p i n gD e l i v e r y D a t e ;

21 s h i p : e a r l i e s t

‘ ‘2011 −12 −13 ’ ’

22 ˆ ˆ xs d : d a t e ] .

 

WEBSERVICECAPABILITYMETAMODEL

5.1 Attribute Types

We distinguish three types of attributes depending on

the source of their values. In general, three sources

are involved in a scenario of capability consumption.

These sources are the consumer who has a request and

is looking for a (concrete) capability to achieve, (ii)

the provider who provides capabilities for achieving

consumer requests and (iii) the interaction context.

The values of a concrete capability attributes are

provided/computed by one of these players. Accord-

ing to who provides the value of an attribute, we dis-

tinguish three subclasses of attributes namely Co, Pro

and Co&Pro attributes. It is important to emphasize

that this classiﬁcation is based on which role provides

the value of the corresponding attribute:

• Consumer or Context (Co) attributes are attributes

which values are speciﬁed by the consumer or

provided by the interaction context. For instance

the attributes ship:to and ship:from in the BlueOf-

fer capability are Co attributes.

• Provider (Pro) attributes are attributes which val-

ues are speciﬁed or computed by the capability

provider. For instance the attribute ship:Price in

the BlueOffer capability is a Pro attribute.

• Consumer then Provider (Co&Pro) attributes are

attributes which values are ﬁrstly speciﬁed by the

consumer but may be changed by the provider.

For instance, the attribute ship:DeliveryDate is

a Co&Pro attribute; the consumer can select

his preferred delivery date and the provider can

change it if some of his working constraints do

not ﬁt the exact proposed date.

5.2 Matching

By analogy to Object Oriented Programming, a capa-

bility category can bee seen as a class and capabil-

ity offers as objects. Similar to objects, which are

instantiated from classes, capability offers are gen-

erated from capability categories. Certain capability

categories are, declarative speciﬁcations for generat-

ing capability offers for particular consumer requests.

If possible, a capability offer is dynamically generated

from a capability category for a particular consumer

request. We say that a particular capability offer is

variant of the capability category it derives from.

Figure 3 gives an overview of the matching pro-

cess and shows which artifact is used in each step.

The matching phase has as input the customer request

and a capability category and as output the customer

offers variant that matches the request.

As shown in Figure 3, a consumer request speci-

ﬁes (i) the values of Co attributes, (ii) hard constraints

on some Pro and Co&Pro attributes, and (iii) prefer-

ences on Co, Pro and Co&Pro attributes. A capabil-

ity category speciﬁes (i) the possible values Co and

Co&Pro attributes can have while considering their

interdependencies, and (ii) the values or how to com-

pute the values of Pro and Co&Pro attributes.

The matching process consists of:

• The First Step checks whether the capability cat-

egory supports the values of the Co and Co&Pro

attributes speciﬁed in the customer request. If the

answer is negative then there is no capability of-

fer variant of the given category that matches the

customer request. If the answer is positive, the

process moves to the following step.

• The Second Step consists of generating the ca-

pability offers that correspond to the customer re-

quest. A capability category and its offers have

the same attributes but with different values for

some of them. The generated capability offers

will be constructed as follows. The value of Co at-

tributes will be those speciﬁed by the customer re-

quest. The value of the Pro and Co&Pro attributes

will be speciﬁed or computed as described in the

capability category.

• The Third Step consists of checking which of

the generated offers satisfy the hard constraints

speciﬁed by the customer. Those capability offers

which do, will be maintained as candidates. The

matching phase should be followed by a ranking

phase where the capability offer candidates will

be ranked based on the consumer preferences.

6 RELATED WORK

Even though the concept of capability has a central

role in enterprise information systems, it has not got

much attention and few works have been interested in

modelling capabilities as such.

The Semantic Web uses ontologies and languages

allowing several ways to describe web services.

For example WSDL-S

and its successor SA-WSDL

(Kopeck

y et al., 2007b; Lathem et al., 2007) use

ontologies to enrich WSDL description and XML

Schema of Web services with semantic annotations.

Such techniques consider a capability as an invocation

interface. However, as explained in this paper a capa-

bility is not an interface. It is an entity featured via a

set of attributes. We believe that our vision and un-

derstanding of capability is more accurate. The back-

ground of the genesis of SOA, which is distributed

method invocation, has inﬂuenced these techniques.

http://www.w3.org/Submission/WSDL-S.

WEBIST2012-8thInternationalConferenceonWebInformationSystemsandTechnologies

As shown in Fig. 1, a consumer request specifies (i) the values of Co attributes, (ii)

hard constraints on some Pro and CoPro attributes, and (iii) preferences on Co, Pro

and CoPro attributes. A BF category specifies (i) the possible values Co and CoPro

attributes can have while taking into account interdependencies between attributes,

and (ii) the values or how to compute the values of Pro and CoPro attributes.

The matching process consists of the following three steps. The first step checks

whether the BF category supports the values of the Co and CoPro attributes specified

in the CR. If the answer is negative then there is no BF offers variant of the given

category that matches the CR. If the answer is positive, the process moves to the

following step.

The second step consists of generating the BF offer(s) that correspond to the CR.

A BF category and its offers have the same attributes but with different values for

some of them. The generated BF offers will be constructed as follows. The value of

Co attributes will be those specified by the CR. The value of the Pro and CoPro

attributes will be specified or computed as described in the BF category.

The third step consists of checking which of the generated offer(s) satisfy the hard

constraints specified by the CR. Those BF offers which do will be maintained as

candidates. The matching phase should be followed by a ranking phase where the BF

offer candidates will be ranked based on the consumer preferences.

Consumer Request

Values of

attributes

Hard

Constraints

Preferences

BF Category

Possible Values

of Co and CoPro

attributes

Values or how to compute

the values of Pro and CoPro

attributes

1. Does the BF category support the input

values requested by the consumer?

2. Generate the BF offer(s) that corresponds to the consumer

request

3. Does the generated BF offer satisfy the hard

constraints specified by the consumer request?

There is

no match

Yes

There is

no match

BF Offer(s)

That matches the CR

BF offer

Control flow

Data flow

Fig. 1. Overview of the matching process of a CR and BF

Figure 3: Overview of the matching process of a customer request and a capability.

In a more reﬁned fashion, languages such as

OWL-S (Martin et al., 2007), WSMO (Roman et al.,

2006), SWSO

, provide a semantic description of

Web services. However, these approaches do not go

beyond the classical Input, Output, Precondition and

Effect paradigm to deﬁne services capabilities. They

do not feature the business aspects of a capability.

In addition, they describe capabilities at an abstract

level. They are not able to model concrete capabil-

ities that correspond to speciﬁc needs of consumers.

However, what clients are interested in are concrete

capabilities. The matching of consumer requests has

to be against concrete capabilities.

Oaks et al., (Oaks et al., 2003) propose a model

for describing service capabilities going one step bey-

inf the IOPE paradigm by distinguishing in particular

the corresponding action verb and informational at-

tributes (called roles in the paper (Oaks et al., 2003)).

However, the semantics of capabilities remain deﬁned

via the IOPE paraddigm and therefore has the same

problems of the previously described approaches.

The notion of (service) offer is currently not ad-

dressed in service description languages such as Uni-

versal Service Description Language(USDL

). Ser-

vice descriptions have a varying level of concreteness

http://www.w3.org/Submission/SWSF-SWSO

www.internet-of-services.de

depending on the stage of a matchmaking and con-

ﬁguration. This notion is currently missing from the

USDL. Introducing different levels of concreteness in

USDL Functional Module should make USDL appli-

cable for describing highly conﬁgurable services.

Other related works worth mentioning are

(Kopeck

y et al., 2007a; Vitvar et al., 2007; Zaremba

et al., 2006). These works have identiﬁed the gap

between current modeling techniques and real world

requirements and initiated the discussions about ab-

stract services and concrete offers descriptions. Sim-

ilar to all related work, the concept of capability was

not tackled as ﬁrst-class entity. The focus was rather

on the service model. In addition, (Vitvar et al., 2007)

and (Zaremba et al., 2006) rely on and extend the In-

put, Output, Precondition and Effect paradigm with-

out making explicit and clear the business features of

services functionalities. They also do not explicitly

distinguish between abstract services and service of-

fer, nor do they deﬁne the links between them.

7 CONCLUSIONS

In this paper, we presented an original meta model for

describing Capabilities which presents several advan-

tages.

WEBSERVICECAPABILITYMETAMODEL

First, contrary to the Input, Output, Precondition

and Effect paradigm it features the business and func-

tional characteristics which consumers are mostly in-

terested in and which are speciﬁed in their requests.

Second, our meta model can deal with capabilities

at different abstraction levels in a uniform way. In ad-

dition, it establishes relations between Capabilities at

different abstraction levels. In particular, it provides

the required declarative speciﬁcation to dynamically

generate concrete Capabilities from abstract ones.

Furthermore, our meta model deﬁnes semantic

links between Capabilities. By using these relations

Capability owners can rapidly and easily deﬁne new

Capabilities by reusing previous deﬁnitions. In ad-

dition, these relations deﬁne a cloud of Capabilities

where navigation techniques can be developed as an

alternative to goal based discovery techniques.

A cloud of capabilities description can be easily

queried using SPARQL. Actually, we use RDF as a

lightweight language for describing and linking capa-

bilities descriptions whereas we can use SPARQL for

advanced querying including the usage of SPARQL

as a rule language (Axel Polleres, 2007).

Finally, since our meta model is RDF based it

can be easily extended, while preserving the attribute-

featured principle, by considering other types of at-

tributes (such as optional and mandatory attributes)

and other types of attribute values.

We did not give much attention in this paper to

the concept of Action Verb. We do not want to tight

the use of this concept to a simple verb. It can be an

expression describing the actual service action. It is

also possible to enrich this concept by other related

terms such as synonyms. Natural Language Process-

ing (Sugumaran and Storey, 2003) can be applied to-

gether with WordNet verb synsets for generating pos-

sible synonyms to enrich the action verb concept of

the capability description.

It is possible to use concepts from a domain re-

lated ontology/taxonomy or a categorization schema

like NAICS

or UNSPSC

for this Action Verb in or-

der to be more compliant to the domain vocabulary.

Otherwise, as it has been stated by (Oaks et al.,

2003), we can use the MIT Process Handbook (Mal-

one et al., 2003) for determining the action verb of a

service capability. A capability can be matched to a

particular process in the process handbook. We can

also use the meronymy and the hyponymy relations

described in that process handbook for creating the

hierarchy of capabilities.

North American Industry Classiﬁcation System,

http://www.census.gov/eos/www/naics/

United Nations Standard Products and Services Code,

http://www.unspsc.org/

As part of our future work, we plan to:

• investigate other relations that might be useful for

creating the capabilities hierachy/cloud. The pos-

sible other relations under deﬁnition are: share,

shareSame, shareDifferent, differMore and differ-

Less. Some of these relations do not bring much

information on themselves. They are used in fact

to compute other relations.

• explore what we call extended relations in con-

trast to basic relations that we are currently con-

siderering. Basic relations are coarse-grain rela-

tions/links while extended relations are more ﬁne-

grained. An extended relation speciﬁes which at-

tribute the basic relation, it derives from.

• provide an automation support for maintaining the

capabilities hierarchy. We aim to provide an au-

tomation support to add or remove any capability

from the hierarchy/cloud.

ACKNOWLEDGEMENTS

This work is funded by the Lion II project supported

by Science Foundation Ireland under grant number

08/CE/I1380.

REFERENCES

Axel Polleres (2007). From SPARQL to rules (and back).

In WWW 2007, Banff, Alberta, Canada. ACM.

Bizer, C., Heath, T., and Berners-Lee, T. (2009). Linked

Data - The Story So Far. IJSWIS, 5(3).

Kopeck

y, J., Simperl, E. P. B., and Fensel, D. (2007a). Se-

mantic Web Service Offer Discovery. In SMRR, vol-

ume 243 of CEUR Workshop Proceedings.

Kopeck

y, J., Vitvar, T., Bournez, C., and Farrell, J. (2007b).

Sawsdl: Semantic annotations for wsdl and xml

schema. IEEE Internet Computing, 11(6).

Lathem, J., Gomadam, K., and Sheth, A. P. (2007). Sa-rest

and (s)mashups : Adding semantics to restful services.

In ICSC. IEEE Computer Society.

Lebo, T. and Williams, G. T. (2010). Converting govern-

mental datasets into linked data. In I-SEMANTICS.

ACM.

Malone, T. W., Crowston, K., and Herman, G. A., editors

(2003). Organizing Business Knowledge: The MIT

Process Handbook. The MIT Press, 1st edition.

Martin, D., Paolucci, M., and Wagner, M. (2007). Bringing

semantic annotations to web services: Owl-s from the

sawsdl perspective. In ISWC/ASWC, volume 4825 of

LNCS. Springer.

Oaks, P., ter Hofstede, A. H. M., and Edmond, D. (2003).

Capabilities: Describing What Services Can Do. In

ICSOC, volume 2910 of LNCS. Springer.

WEBIST2012-8thInternationalConferenceonWebInformationSystemsandTechnologies

Roman, D., de Bruijn, J., Mocan, A., Lausen, H.,

Domingue, J., Bussler, C., and Fensel, D. (2006).

Www: Wsmo, wsml, and wsmx in a nutshell. In

ASWC, volume 4185 of LNCS. Springer.

Scheer, A.-W. and Schneider, K. (2006). ARIS Architec-

ture of Integrated Information Systems. Bernus Peter

Mertins Kai Schmidt Gunter.

Sheridan, J. and Tennison, J. (2010). Linking UK Govern-

ment Data. In LDOW 2010.

Sugumaran, V. and Storey, V. C. (2003). A semantic-

based Approach to Component Retrieval. SIGMIS

Database, 34.

Vitvar, T., Zaremba, M., and Moran, M. (2007). Dy-

namic Service Discovery Through Meta-interactions

with Service Providers. In ESWC, volume 4519 of

LNCS. Springer.

Zaremba, M., Vitvar, T., Moran, M., and Haselwanter, T.

(2006). WSMX Discovery for the SWS Challenge. In

ISWC, Athens, Georgia, USA.

WEBSERVICECAPABILITYMETAMODEL