The Semantic Web as Types, Web Services as Functions:
Ten Points on a Semantic Framework for Web Services
University of Edinburgh
April 29 2005
There has been complaints within Web circles of too many
standards being produced around Web Services and not enough clarity
of vision between them. This is historically an important moment
to examine the foundations of the Semantic Web and Web Services, and build
them upon a common foundation, resulting in standards that are coherent,
modular, and elegant.
We will even argue that XML, long considered an essentially solved problem space
compared to the brave new worlds of the Semantic Web and Web Services, is in
need of some fundamental changes to incorporate developments into Semantic Web and Web
Services. We present a common vision: that Web Services and the Semantic Web are
transforming the Web from a universal information space to a universal
This can be done by using the Semantic Web as a Web-scale typing
language and Web Services as Web-accessible functions. We then have ten
critical points that need to be addressed to bring greater coherency
between the semantics of Web Services, the Semantic Web, and XML.
Point 1: Build Upon a Common Formal Foundation
As discovered by XML by the refounding
of XPath on operational semantics, and by the Semantic Web
by rebuilding RDF upon formal logical semantics, specifications
in natural language are not enough. A common formal semantics should be built
in from the beginning that unifies the Web Services. It should be obvious right now
that the tried-and-tested pi-calculus provides the essence of such a formal semantics for distributed systems such as Web Services.There is some debate in this area about the relative virtues of petri nets, however, pi-calculus still seems to be a better bet.
However, almost all the major
efforts of Web Services lack a formal semantics. BPEL4WS has no
explicit formal semantics (despite being based on XLANG, which was
based on the pi-calculus)
resulting in messy and partial implementations, while OWL-S, despite
roots in OWL, also does not have a formal semantics, although there has
work in this area. One result of this workshop
should be the determination of a common foundation for formal semantics
of Web Services and seeing if that extends to current Web Services
standards and how it relates to the formal semantics of the Semantic
Point 2: Hide Everything from the Users except Functions
As regards semantics, the average user does not care about
concurrency or any other aspect of
the formal semantics. The user also should not have to care at all
about the details of the XML implementation. Yet all too often in
current Web Services, this is impossible, and thus the growing
the simple REST model, which is currently viewed as in competition with
SOAP and the Web Service standardization process. The question should
be at what level should the user be able to access Web Services?
The answer is that an imperative, von Neumann approach to using Web
Services makes no sense on
the Web, which by nature should have no server-side side-effects (REST)
and requires that Web Services must compose easily. What makes sense is
a functional approach to using
and composing Web Services, building upon the lambda-calculus, which can be constructed from the pi-calculus. While this may be viewed as a return to LISP, it is obvious that this level of abstraction
shields the users from the details while allowing easy composition of Web Services.
Point 3: Ontologies as Types
OWL-S and WSMO are moves in the direction of defining an ontology
for Web Services. Since Web Services can be viewed on a certain level
of abstraction as Web-accessible functions, then we are begging the
question of what types of things they can use. Currently, WSDL define Web Services to accept and return the types as defined in XML Schema: Part 2. While xsd
types are a sensible beginning, they are very limited. In particular,
they do not provide a notion of identity, and can be viewed as some
sort of grab-bag of types. What makes more sense is to allow Web
Services to not only return xsd types, but to return data that is typed by a Semantic Web Ontology
in RDF/OWL. This means that we should extend the notion given in OWL-S
that Web Services should be defined by ontologies, but the domain and
range of Web Services should also be capable of being typed by ontologies.
This provides two-leveled typing: the first syntactic level of any
information sent across the Web should be on the XML types, and the
second semantic level should be a binding from the some XML-typed data
to an ontology - and so Web Services can just be viewed from the
perspective of the users as a typed lambda calculus, with Web Services as functions and ontologies as types.
Point 4: Binding Ontologies to XML Typing XML documents as
ontologies is not trivial: despite the vision of Tim Berners-Lee to
layer the Semantic Web on top of XML, they are often viewed as
competing efforts. This ignores two crucial facts: many dislike RDF/XML
as a syntax, and XML has already been widely adopted as a transfer
syntax. However, what XML lacks (despite attempts such as xml:id) is a coherent notion of identity, as any company that has tried to do XML data merger has found. Through techniques such as GRDDL and XML Schema annotations,
it is possible to bind ontologies to XML, and this can easily be
extended to SOAP messages. Binding SOAP to RDF/OWL gives the same
model-theoretic semantics to the data model (XML Infoset) being employed in the messages as it gives to the Web Services themselves.
Point 5: Make XML and SOAP really self-describing
Another problem with using only XML as the base of data transfer between Web Services is that XML is not really self-describing
at this stage in its development. XML data often depends for its
correct interpretation validation with regards to a XML Schema, a
transformation into RDF, a XSLT that allows it to merge with some other
vocabulary, and so on. However, none of this is usually explicitly said
in the XML document itself. Instead of always transferring an XML
document after it has gone through various validations and
transformations, often resulting in an unreadable and complex XML
document; a new XML vocabulary is needed to describe the processes that
are needed to transform arbitrary XML data, and these processes should
be denoted by URIs and available as Web Services.
Point 6: Embed Web Services in the Infoset
This leads to one subtle but important modification of the XML Infoset:
the Infoset is thought of as describing the data model of static data.
However, more and more the actual data should be dynamic and should
describe the processes needed to retrieve data. This results in a
dynamic model of the Infoset, where any aspect of the Infoset can be a
call to a Web Services that in turn returns an Infoset to be merged
with the previous Infoset at the node given a Web Service. This is
clearly related to current theoretical work on Active Data in XML by
Phillipa Gardner. Just as Web Services return and send SOAP/XML data, so should SOAP/XML data contain calls to Web Services.
Point 7: Types We Can Trust
Currently work on trust and policy is of utmost importance to industry. After all, sending valuable business data over
is not the a good technique for keeping one's data secure: for many
cases, keeping valuable business data secure on large local servers
physically near a business makes sense. When sending data, one wants federated
Web Services tied together by trust policies. The obvious place to put
knowledge about trust is the type. Also, the type should be carrying
the proof of how it got its type with it, as in the Stanford proof-carrying code
project. Lastly, as these types can be ontologies, they should also be
able to encode rules to change levels of trust and encode conditions of
trust, and the W3C has begun formalizing this process.
Web Services originally just used
http to pass XML
silently through firewalls detected. With true self-describing SOAP
data typed by ontologies and rules, the reverse will be true: one
should always know exactly when data is being sent, whose sending it, and have a proof the data is correct and to be trusted.
Point 8: Web Service Discovery as Logic Programming
Another question is how to discover Web Services in the global open
world of the Web. The current methodology of UDDI is more or less just
a giant list of Web Services, with almost no order. Having Web Services
themselves typed by ontologies, and having their input and output typed
by ontologies, will improve the situation of finding a particular Web
Service immensely. One concrete technique improving the semantics of
Web Services gives one is the paradigm of back-tracking from logic
programming. In essence, a user can give the program partial
information about the Web Service it wants, such as its input
ontological type and its output ontological type, while remaining
agnostic about the exact Web Service needed (convert Fahrenheit to
Celsius, and just do it via some Web Service somewhere). This would
then invoke a interpreter based on logical programming that would
search the search-space of Web Services (given to it via UDDIs), and
then return the answer to the user as soon as it found a Web Service
that fit the logical constraints given to it.
Point 9: Give Web Services a Programming Language
Using Web Services, especially composing Web Services, is far more
painful now than it should be. The main methods of composing Web
Services, BPEL4WS, has only recently been given an open source
implementation. Also, not having a formal semantics and being very
large, it is unclear if it is suitable for widespread adoption outside
the business community where it is already being used. OWL-S is an
ontology, not a programming language. What Web Services needs is a
Semantic Web-aware programming language for composing Web Services.
This bring us from just possessing type to having a type system that
can specify program behavior. The obvious way to combine the
compositionality of functional programming needed for Web Service
composition with the logical programming needed for Web Service
discovery is a language based on the logical functional programming paradigm as used by the language Curry .
The W3C has taken the lead on development of exemplary technologies
before, and this technology is desperately needed and could demonstrate
the compatibility of the Semantic Web and Web Services in a very
Point 10: Simplification via Abstraction
These points have a unifying theme: use a single formal semantics
(pi-calculus) for implementation, use a single formal semantics for use
(typed lambda calculus), use a single transfer syntax (XML/SOAP) but
make sure it uses a single type system (bind RDF/OWL on top of XML and
Web Services), and make sure the standards themselves properly
decompose on every level (allowing Web Services to be in the Infoset,
building trust not on the XML data by on the ontological type of the
data). Once we have XML as state serialization, the Semantic Web as
types, and the Web Services as functions, we can successfully change
the Web from a universal information space of human-readable documents to the universal computation space needed by Web Services.
 A Calculus of Mobile Processes: R. Milner, J. Parrow, and D. Walker. Information and Computation (100) 1992. http://www.lfcs.inf.ed.ac.uk/reports/89/ECS-LFCS-89-85
 Pi calculus versus Petri nets: Let us eat humble pie rather than further inflate the Pi hype Prof. Van de Aalst. http://is.tm.tue.nl/research/patterns/download/pi-hype.pdf .
 Orchestration of Semantic Web Services for Large-Scale Document Annotation. Barry Norton, Sam Chapman, Fabio Ciravegna. 2nd European Semantic Web Conference (ESWC 2005)http://www.dcs.shef.ac.uk/~barry/#Publications
 The Ties that Bind: XML, the Semantic Web, and Web Servies. Harry Halpin. Young Service-Oriented Researchers Conference 2005.http://www.ibiblio.org/hhalpin/publications.html.
 Data Binding Using W3C XML Schema Annotations: K.
Ari Krupnikov and Henry S. Thompson. XML Conference and Exposition
 Behavioural Equivalences for Dynamic Web Data. P. Gardner and S.Maffeis). IFIP-TCS 2004.
 A Unified Computation Model for
Declarative Programming: Michael Hanus. Joint Conference on
Declarative Programming 1997.
For more information see: http://www.informatik.uni-kiel.de/~mh/FLP