The Semantic Web as Types, Web Services as Functions:

Ten Points on a Semantic Framework for Web Services

Harry Halpin

University of Edinburgh

April 29 2005

Introduction

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 computation space. 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[1].There is some debate in this area about the relative virtues of petri nets, however, pi-calculus still seems to be a better bet.[2] 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 having its roots in OWL, also does not have a formal semantics, although there has been work in this area[3]. 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 Web.

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 popularity of 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[4].

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[5], 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[6]. 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 http:// 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 [7]. 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 concrete manner.

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.

References:

[1] 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

[2] 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 .

[3] 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

[4] 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.

[5] Data Binding Using W3C XML Schema Annotations: K. Ari Krupnikov and Henry S. Thompson. XML Conference and Exposition 2001. http://www.idealliance.org/papers/xml2001/papers/html/06-03-04.html

[6] Behavioural Equivalences for Dynamic Web Data. P. Gardner and S.Maffeis). IFIP-TCS 2004. www.doc.ic.ac.uk/~maffeis/xdpi04.pdf

[7] A Unified Computation Model for Declarative Programming: Michael Hanus. Joint Conference on Declarative Programming 1997. http://www.informatik.uni-kiel.de/~mh/publications/papers/AGP97.html. For more information see: http://www.informatik.uni-kiel.de/~mh/FLP