Tuesday, November 15, 2005
Center of Excellence Proposal
à
Article in Datawarehouse.com on Semantic Technology
Roadmap à
Previous
comments on web service
execution
environment and ontology à [199]
The work by the WSMO (Web
Services Modeling Ontology) community à [201]
http://www.wsmo.org/2004/d2/v1.0/
We classify non functional properties in two categories: core properties
and web service specific properties.
The core properties can be used for all the modeling elements of WSMO.
They consist of the Dublin Core Metadata Element Set [Weibel
et al., 1998] plus the version element. We do not
enforce restrictions on the range value type (and this also omit the range
restriction in the following listings) but in some cases provide additional
recommendations. In case that no WSMO recommendation is given, the Dublin Core
rules apply as a default:
|
Listing 1. Non functional
properties (core properties) definition |
entity nonFunctionalProperties dc:title dc:creator dc:subject dc:description dc:publisher dc:contributor dc:date dc:type dc:format dc:identifier dc:source dc:language dc:relation dc:coverage dc:rights version |
Title
A name given to an element. Typically, dc:title will be a name by which the element is
formally known.
Creator
An entity primarily responsible for creating the content of the element.
Examples of dc:creator include a person, an organization, or a
service. The Dublin Core specification recommends, that typically, the name of
a dc:creator should be used to indicate the entity.
WSMO Recommendation: In order to point unambiguously to a specific
resource we recommend the use an instance of foaf:Agent as value type [Brickley
& Miller, 2004].
Subject
A topic of the content of the element. Typically, dc:subject will be expressed as keywords, key phrases
or classification codes that describe a topic of the element. Recommended best
practice is to select a value from a controlled vocabulary or formal
classification scheme.
Description
An account of the content of the element. Examples of dc:description include, but are not limited to: an
abstract, table of contents, reference to a graphical representation of content
or a free-text account of the content.
Publisher
An entity responsible for making the element available. Examples of dc:publisher include a person, an organization, or a
service. The Dublin Core specification recommends, that typically, the name of
a dc:publisher should be used to indicate the entity.
WSMO Recommendation: In order to point unambiguously to a specific
resource we recommend the use an instance of foaf:Agent as value type [Brickley
& Miller, 2004].
Contributor
An entity responsible for making contributions to the content of the
element. Examples of dc:contributor include a person, an organization, or a
service. The Dublin Core specification recommends, that typically, the name of
a dc:contributor should be used to indicate the entity.
WSMO Recommendation: In order to point unambiguously to a specific
resource we recommend the use an instance of foaf:Agent as value type [Brickley
& Miller, 2004].
Date
A date of an event in the life cycle of the element. Typically, dc:date will be associated with the creation or availability
of the element.
WSMO Recommendation: We recommend to use the an encoding defined in the
ISO Standard 8601:2000 [ISO8601, 2004] for date and time notation.
A short introduction on the standard can be found here.
This standard is also used by the the XML Schema Definition (YYYY-MM-DD) [Biron
& Malhotra, 2001] and thus one is automatically compliant with
XML Schema too.
Type
The nature or genre of the content of the element. The dc:type includes terms describing general
categories, functions, genres, or aggregation levels for content.
WSMO Recommendation: We recommend to use an URI encoding to point to the
namespace or document describing the type, e.g. for a domain ontology expressed
in WSMO, one would use: http://www.wsmo.org/2004/d2/#ontologies.
Format
A physical or digital manifestation of the element. Typically, dc:format may include the media-type or dimensions of
the element. Format may be used to identify the software, hardware, or other
equipment needed to display or operate the element. Examples of dimensions
include size and duration.
WSMO Recommendation: We recommend to use types defined in the list of
Internet Media Types [IANA,
2002] by the IANA (Internet Assigned Numbers Authority)
Identifier
An unambiguous reference to the element within a given context.
Recommended best practice is to identify the element by means of a string or
number conforming to a formal identification system. In Dublin Core formal
identification systems include but are not limited to the Uniform element
Identifier (URI) (including the Uniform element Locator (URL)), the Digital
Object Identifier (DOI) and the International Standard Book Number (ISBN).
WSMO Recommendation: We recommend to use URIs as Identifier, depending
on the particular syntax the identity information of an element might already
be given, however it might be repeated in dc:identifier in order to allow Dublin Core meta data
aware applications the processing of that information.
Source
A reference to an element from which the present element is derived. The
present element may be derived from the dc:source element in whole or in part. Recommended
best practice is to identify the referenced element by means of a string or
number conforming to a formal identification system.
WSMO Recommendation: We recommend to use URIs as Identifier where
possible.
Language
A language of the intellectual content of the element.
WSMO Recommendation: We recommend to use the language tags defined in
the ISO Standard 639 [ISO639, 1988], e.g. "en-GB", in
addition the logical language used to express the content should be mentioned,
for example this can be OWL.
Relation
A reference to a related element. Recommended best practice is to
identify the referenced element by means of a string or number conforming to a
formal identification system.
WSMO Recommendation: We recommend to use URIs as Identifier where
possible. In particular, this property can be used to define namespaces that
can be used in all child elements of the element to which this non functional
property is assigned to.
Coverage
The extent or scope of the content of the element. Typically, dc:coverage will include spatial location (a place name
or geographic coordinates), temporal period (a period label, date, or date
range) or jurisdiction (such as a named administrative entity).
WSMO Recommendation: For more complex applications, consideration should
be given to using an encoding scheme that supports appropriate specification of
information, such as DCMI Period, DCMI
Box or DCMI Point.
Rights
Information about rights held in and over the element. Typically, dc:rights will contain a rights management statement
for the element, or reference a service providing such information. Rights
information often encompasses Intellectual Property Rights (IPR), Copyright,
and various Property Rights. If the Rights element is absent, no assumptions
may be made about any rights held in or over the element.
Version
As many properties of an element might change in time, an identifier of
the element at a certain moment in time is needed.
WSMO Recommendation: If applicable we recommend to use the revision
numbers of a version control system. Such a system can be for example CVS
(Concurrent Version System), that automatically keeps track of the different
revisions of a document, an example CVS version Tag looks like:
"$Revision: 1.13 $".
Besides the core properties described in the previous section, the web
service specific non functional properties also include properties related to
the quality aspect of a web service (QoS):
|
Listing 2. Non functional
properties definition for web services |
entity wsNonFunctionalProperties subEntityOf nonFunctionalProperties accuracy financial networkRelatedQoS performance reliability robustness scalability security transactional trust |
Accuracy
It represents the error rate generated by the web service. It can be
measured by the numbers of errors generated in a certain time interval.
Financial
It represents the cost-related and charging-related properties of a web
service [O`Sullivan et al., 2002]. This property is
a complex property, which includes charging styles (e.g. per request or
delivery, per unit of measure or granularity etc.), aspects of settlement like
the settlement model (transactional vs. rental) and a settlement contract,
payment obligations and payment instruments.
Network-related
QoS
They represent the QoS mechanisms operating in the transport network
which are independent of the web services. They can be measured by network
delay, delay variation and/or message loss.
Performance
It represents how fast a service request can be completed. According to [Rajesh
& Arulazi, 2003] performance can be measured in terms of
throughput, latency, execution time, and transaction time. The response time of
a service can also be a measure of the performance. High quality web services
should provide higher throughput, lower latency, lower execution time, faster
transaction time and faster response time.
Reliability
It represents the ability of a web service to perform its functions (to
maintain its service quality). It can be measured by the number of failures of
the service in a certain time internal.
Robustness
It represents the ability of the service to function correctly in the
presence of incomplete or invalid inputs. It can be measured by the number of
incomplete or invalid inputs for which the service still function correctly.
Scalability
It represents the ability of the service to process more requests in a
certain time interval. It can be measured by the number of solved requests in a
certain time interval.
Security
It represents the ability of a service to provide authentication
(entities - users or other services - who can access service and data should be
authenticated), authorization (entities should be authorized so that they only
can access the protected services), confidentiality (data should be treated
properly so that only authorized entities can access or modify the data),
traceability/auditability (it should be possible to trace the history of a
service when a request was serviced), data encryption (data should be
encrypted), and non-repudiation (an entity cannot deny requesting a service or
data after the fact).
Transactional
It represents the transactional properties of the web service.
Trust
It represents the trust worthiness of the service.