Although RDF is considered the Semantic Web language, it may not be the only one. SOAP serialisation provides several advantages, especially if the Semantic Web is not just about providing meta data for existing web pages, but also about exchange of content that is machine-readable in the rst place. This paper discusses some problems with the RDF syntax and data model. RDF is compared to SOAP, and some SOAP advantages like better integration with existing standards and systems, improved readability, and industry support are pointed out.
What are the consequences if the term Semantic Web" does not just mean HTML with some meta-data, but also content that is machine-readable in the rst place, thus being suitable for applications like software agent communication? Although RDF is suitable for that purpose, its syntax and data model are clearly optimised for annotating existing documents with meta data, describing existing web resources using a machine readable format.
In contrast to HTML, the exibility of XML allows storing all relevant meta data in a machine-readable format in the rst place. With the increasing separation of content and layout into XML and XSLT les, and the dynamic generation of XHTML, the need for a separate meta model may decrease. Naturally, RDF is well suited for annotating the generated HTML with information like PICS, but is content annotation really all the Semantic Web is about?
This article discusses some serious issues concerning the RDF syntax and data model when used as a primary machine readable content format, instead of just adding metadata to existing HTML or XML pages. It presents SOAP serialisation as an alternative. In contrast to 16 , the sug-
The Resource Description Framework RDF 15 was originally designed by the World Wide Web Consortium W3C as a meta-language for annotating existing web pages with additional machine-readable information. A t ypical RDF application is the Platform for Internet Content Selection PICS 6 , that is intended to annotate existing web resources with meta-data about e.g. the suitability of the content for children.
Although RDF was originally designed for annotation of existing web pages only, it is currently widely considered as machine-readable format for the Semantic Web and the DARPA Agent Meta Language DAML.
However, when using RDF as the primary information format, and not just for meta data annotation, some issues arise. These problems are described in detail in the following sections. For an overview of additional general RDF issues and inconsistencies, the reader is referred to 4 and 10 .
The requirement that RDF should be usable for annotating existing pages with meta-data without breaking browser compatibility for the actual content resulted in a syntax that is more complicated than necessary for plain RDF documents. Also, several alternative syntax forms exist. All alternatives are semantically equivalent, but have di erent e ects on the rendering process in the browser that is used to view the document.
The general RDF syntax consists of simple resource descriptions properties" embedded in a description" element. In order to illustrate RDF and SOAP syntax alternatives, a FIPA 2000 Agent Platform description 14 is used as a common example here, where the serialised instances are taken from the Paris Agentcities node ApDescription1 . Although the Paris node Agent Platform Description consists of four small objects only, the corresponding RDF serialisation gure 1 becomes rather verbose.
In the RDF example, the rdf:Description elements are already replaced by their abbreviated form for improved Resource description and type abbreviation: An rdf:Description element m a y be replaced by a n element named like the type of the resource described, also obsoleting a corresponding rdf:type element. In the example, the abbreviated form was already used. All object descriptions in the example could be replaced by the corresponding standard form. For example, The various RDF syntax options lead to two main problems: XSLT and XML Schema compatibility problems and problems with human readability.
The Extensible Stylesheet Language Transformations XSLT were designed with the main goal of separating the content and layout of Web pages. The basic idea is to design the original page using an XML language. The XML content is then converted to a regular" XHTML page by an XSLT template.
The various RDF encoding options described above make development of XSLT templates for RDF di cult: In order to be fully applicable to RDF, XSLT templates would need to de ne a mapping covering all possible syntax alternatives. It would certainly be possible to design relatively simple XSLT templates for one concrete serialised form of RDF. But then the XSLT transformation would become either very fragile, or another processing step converting any RDF le to the form expected by the template would be necessary.
Another problem with RDF is human-readability. While one of the original ideas of XML is to provide some kind of compromise between machine and human-readability, RDF is actually di cult to read for humans. Again, the main reason are the meta language roots of RDF. With the various syntax options, it is even quite di cult to just see if two RDF documents are semantically equivalent. In order to read RDF documents, a human must be familiar with all syntax variants of RDF. When RDF is used to annotate an existing HTML page, the situation becomes even worse since it is often di cult to di erentiate between RDF annotation and actual content. In addition, the verbosity of RDF makes it di cult to read when compared to other XML languages or SOAP.
While it seems relatively simple to x the problems concerning the RDF syntax, this is far more di cult for the RDF data model.
The RDF data model is very simple. It is basically a labelled graph consisting of subject predicate object triples. With the RDF Schema language RDFS 5 , the data model becomes signi cantly more structured. RDFS introduces a type system that can be used to express property constraints. Figure 2 shows the RDFS diagram corresponding to the RDF example. An corresponding Uni ed Modelling Language UML 17 diagram of the ontology is shown in gure 3.
To some extent, RDFS is similar to object oriented structures, except that properties must have globally unique names. The RDFS speci cation claims that the property centric approach makes it "very easy for anyone to say a n ything they want about existing resources, which is one of the architectural principles of the Web". However, deviating from standard" object orientation also raises some interoperability issues with existing system or modelling tools.
Unfortunately, treating properties as rst class members of the data model makes it impossible to map existing object hierarchies or database systems to RDFS automatically, without additional handling of property names to ensure global uniqueness. This is not just a problem with objectoriented systems or relational databases, also knowledge systems like O n tobroker 11 or Prot eg e 12 are seriously affected. When properties have a global domain and range de nition, it is not possible to re ne the de nition in a subclass. It is also not possible for di erent classes to use the same property name with di erent v alue and domain restrictions 19 .
In order to work around this problem, di erent mappings already exist, all having their own advantages and disadvantages, and it is quite simple to invent new ones. Possibilities are:
Facets: Facets were added to RDF by Stefan Decker to simplify RDF compatibility of the Prot eg e system 18 . The idea behind facets is to allow m ultiple ranges and re nements for properties. The mapping problem for other OO systems could be solved by i n troducing conicting properties at a common base class and introducing the actual restrictions later where needed.
Name Concatenation: Stephen Crane eld designed an XSLT template mapping the property names to globally unique names by just concatenating them with the class names 8 . Applied to the UML diagram representing the course sample schema shown in Figure 3, the generated RDF Schema would be identical to Figure 2, except that all property names were concatenated the corresponding domain name. For example, name would be renamed to ApDescription.name.
Other options: It is quite simple to invent other mechanisms to ensure globally unique property names. For example, a dedicated XML namespace could be assigned to each object, preserving the original name but requiring extensive usage of XML namespaces.
The main problem is that there is no intuitive mapping. All mappings have their own advantages and disadvantages, without one being clearly preferable to the others. Moreover, except from the facets solution, which has the disadvantage of extending RDFS, it is not possible to apply the inverse mapping to any RDFS schema without preconditions. The inverse mapping is only possible if the RDFS is already of the right "form". It is not possible to generate compatible RDF among di erent mappings by using the output from one mapping as input for another inverse mapping. So even if all mappings are using RDFS as their target format, that does not help for interoperability at all. Furthermore, this problem does not only a ect connecting existing systems to the Semantic Web, but also ontology design using UML 9 . When using UML in the ontology design process, it becomes necessary to take special care of property names again.
Concatenating a property name with the domain name or a namespaces may also create problems for derived classes inheriting that property. All derived classes are a valid domain for the property, too, but one would need to remember the domain where the property w as de ned for constructing the right name and thus being able to access the property.
Another signi cant di erence between the RDFS data model and standard object oriented systems is that a resource can have more than one type. For example, the Prot eg e system is not able to handle this without workaround. Prot eg e w as designed to allow only one class for each instance because of user interface considerations. Prot eg e solves the problem by i n ternally creating arti cial concepts that are merged from the di erent t ypes of a resource.
Please note that two di erent descriptions of one object can exist without requiring that an object is allowed to have several types. The described object and the descriptions just need to be separate objects.
The RDF data model is a set of subject predicate object statements, where the statements themselves do not have an address. In order to be able to make statements about statements, it is necessary to model the original statement as a resource having a subject, a predicate, an object, and a type.
A potential alternative to RDF may be contained in the Simple Object Access Protocol SOAP 3 speci cation. SOAP is a speci cation covering remote procedure calls over HTTP. It contains an object serialisation format that can be compared to the Resource Description Format RDF to some extent, even if RDF is not just an object serialisation format. Although RDF was already existing when SOAP was being speci ed, RDF was not chosen as the default serialisation format for SOAP. Instead, SOAP introduces a completely new format de ned from scratch.
SOAP is supported by computer industry leaders like Microsoft, IBM and SUN. The simplicity o f S O AP together with the support from the industry suggests that many SOAP-based services will be available in the near future. While industry support is usually not really relevant for research, research in Arti cial Intelligence may take signi cant advantage from the amount of structured data provided by a Semantic Web that is widely accepted and used. SOAP Implementations are available for a wide range of programming languages C++, Java, Perl, Python 2 . In contrast to HTML, SOAP is de ned for direct communication between machines over the Internet, so it may a ect the Semantic Web in many w ays or even become a signi cant part of it. SOAP is suitable for all kinds of automated Internet services like w eather forecasts, tra c services, or logistics coordination. Although SOAP supports alternative content formats, it is likely that most of the content will actually be encoded using SOAP serialisation. Thus, some questions arise: How can SOAP be integrated into the Semantic Web? Can the Semantic Web pro t from SOAP services? In his WWW9 presentation, Henrik Frystyk Nielsen 16 demonstrated how RDF can be encoded utilising the SOAP serialisation syntax. While he states in his presentation that SOAP is not meant to replace RDF, this is clearly one of the possible future scenarios in the areas where Semantic Web" means exchange of information that is machine readable in the rst place.
Although SOAP was originally designed as a remote method invocation protocol running over the Internet, SOAP is not just another Common Object Request Broker Architecture CORBA. SOAP di ers from CORBA in signi cant points:
Human Readability: In contrast to the CORBA Internet Inter ORB Protocol IIOP, SOAP is not a binary format but an XML-based format that is humanreadable. Even if SOAP is mainly intended to be read by machines, human readability i s v ery helpful for debugging purposes and quick implementation.
Simple Installation: While CORBA requires huge software packages and does not provide a commonly accepted bootstrapping mechanism, SOAP is based on HTTP and can be implemented with little e ort on top of existing libraries for XML and HTTP.
Even if SOAP still lacks a reasonable security model, it has the potential to become the connecting point b e t ween Java, Perl and Microsoft's .NET architecture by just o ering a suitable feature set, while still being simple enough to be implemented by a broad range of programmers.
Probably the main reason for SOAP becoming quite popular in the very short time it is available now is its simplicity. The serialised format of the FIPA example encoded in SOAP is shown in Figure 4. The format is much more similar to an XML special purpose format designed by hand" than the RDF serialisation.
The main di erence visible on rst glance is the reduced nesting level of XML elements. In RDF, both objects and properties have their own tags. In SOAP, the nested tags starting a new object are always merged with the property tags if possible. This also has the advantage that navigating through a SOAP serialised document using path expressions becomes very similar to usual path 2 http: www.superopendirectory.com directory 4 standards 23 implementations expressions in object oriented programming or query languages. If the type of a property is not xed, it can be resolved by adding a type attribute e.g. transportProfile xsi:type="ApTransportDescription" . Moving the type information into an attribute maintains the advantage of the reduced nesting level when compared to RDF.
Similar to RDF, SOAP allows alternative syntax forms for embedded and referenced objects, but in contrast to RDF the speci cation contains clear rules when an object is embedded and when it is referenced: Objects may b e e m bedded if there exists only one referenced to them, otherwise they are linked. And in contrast to RDF, SOAP serialisation does not allow additional abbreviated or alternative XML syntaxes. Actually, there is no need for an abbreviated syntax since SOAP serialisation is compact enough in the rst place.
The complete speci cation of SOAP serialisation syntax is given in 3 .
SOAP is based on a simple object oriented data model. The SOAP Data Model consists of structured objects having properties and a type. Thus, the basic building blocks are more complex than plain RDF. However, when compared to RDFS, there is no signi cant di erence. Larger basic building blocks may h a ve advantages e.g. when tracking the source of statements: The source information would be attached to just one object instead of needing rei cation for a lot of RDF statements. Also, when constructing URLs from OIDs, it becomes very simple to make statements about statements, again avoiding explicit rei cation that would be required in RDF.
In contrast to RDF, SOAP does not come along with its own schema language. Instead, XML Schema is used for validation of the syntactical correctness of SOAP serialised objects. While XML Schema does not seem the appropriate level of ontology modelling, SOAP serialisation ts well into UML modelling without the property naming problems of RDF. And when comparing the RDFS and UML diagrams gure 3 and gure 2, UML seems signi cantly more appropriate for modelling ontologies.
As shown in the preceding sections, SOAP has advantages over RDF in several areas. But does that mean that SOAP is su cient to build a Semantic Web"? The Semantic Web is meant to be more than just turning some existing objectoriented systems into SOAP services. How can a collection of SOAP services evolve i n to a Semantic Web? Are there any RDF core features missing in SOAP? Can the advantages of SOAP and RDF be combined to accelerate or simplify the process of building a Semantic Web?
Henrik Frystyk Nielsen 16 suggests to apply SOAP serialisation to the RDF data model to simplify integration of the SOAP RMI protocol with RDF data. Since this would mean yet another alternative syntax, the RDF syntax situation would not be simpli ed, except if the new syntax became the only one. But limiting RDF syntax variants in general would generate problems when using RDF for its original purpose of annotating existing documents. Also, the proposed syntax would not help for a seamless integration of other SOAP-based services since the property mapping problem would persist.
In 2 , Tim Berners-Lee justi es the usage of the propertycentric data model instead of an usual" object-oriented data model by claiming that object-oriented systems generally assume that information about an object is stored inside that object. So, in order to be able to say a n ything about anything, it becomes necessary to store the properties apart from the object.
While for object oriented systems it is true that property information is stored with the objects, this does not mean that objects cannot hold information about other objects. So there is no real requirement that e.g. the PICS rating of an HTML page is a property of that page. It could also be a separate object holding a pointer to the original page. A more complex example could be a car being the primary object and its description stored at an insurance company.
Even if a standard" object-oriented data model is suitable for the Semantic Web, there is still a problem with SOAP. The SOAP speci cation does not specify how to assign URLs to objects. There is also no general mechanism to say something" about a given URL. However, it seems relatively simple to assign URLs to objects built from the service address and a local unique number OID. If an object is intended to describe a resource, it could have an about" property like in the SOAP-encoded RDF syntax proposed by Henrik Frystyk Nielsen 16 .
The SOAP speci cation does not contain any s c hema language, but refers to XML Schema for syntax validation. However, a syntax speci cation language like XML Schema is not really suitable for modelling ontological elements like classes, attributes and associations. Actually, the SOAP speci cation just describes how to get an XML Schema from the data structure and not vice versa.
But even if SOAP does not come along with its own schema language, the SOAP data model ts quite well into UML. Thus, UML tools can be used for modelling, without the limitations shown for the RDF case.
Furthermore, even if SOAP describes instance serialisation only, the UML meta model 17 can still be utilised to serialise UML models using SOAP serialisation syntax. Some UML constructs would require the de nition of a concrete mapping, but there is no general incompatibility i n the data model. Distinction between di erent t ypes of associations in UML could also be utilised to de ne the cases where embedded objects are allowed in SOAP serialisation more clearly.
In his XML2000 keynote, Tim Berners-Lee suggested to use "screen-scraper"-like XSLT templates to convert XML into RDF for the starting century of the a Semantic Web 1 , like shown in gure 5. However, the SOAP serialisation syntax is simple enough to be widely accepted as a general XML modelling convention. So it may be possible to eliminate the need for an additional screen scraping" template in many cases. Also, the compatibility with XSLT allows building HTML or WML transformation templates, just like Another SOAP advantage is that SOAP quite nicely integrates with a lot of existing standards Table 1. This was already discussed for XSLT and UML, but we also have a w ell designed query language for object oriented systems. The Object Query Language OQL 7 , designed by the Object Data Management Group ODMG ts perfectly with SOAP and preserves a high degree of SQL compatibility.
For a real Semantic Web", the upper logical levels are missing from SOAP. But this holds for RDF as well, and looking at existing inference systems, it does not seem more di cult to build them for SOAP than for RDF 13 .
Also, mechanisms for schema translations may become necessary. For example, if a legacy system with a direct SOAP mapping needs to be adapted to a SOAP based standard, or if SOAP based standards for di erent areas need to interoperate. However, this will probably be more simple than general XML-XML translations, where XML-XML translations are possible today using XSLT. Again, the same would be necessary for RDF.
Obviously, w e h a ve t wo formats and data structures that are similar to some extent, and both are relevant for the Semantic Web", especially when the term means something di erent than annotation of existing pages with additional meta data. The main problem is that both approaches are di cult to translate into each other.
In contrast to SOAP, RDF is suitable for in place" annotation of existing web pages. For being able to say anything about anything", RDF uses URLs as global unique identiers.
Although SOAP is not suitable for in place" annotation and would require an extension assigning URLs to objects in order to become really suitable for the Semantic Web, it has several advantages in other areas. SOAP ts quite well into other standards like UML, XSLT and OQL. It provides a clear and simple syntax. The SOAP Serialisation syntax nearly reaches the quality of a hand-made" one. Thus, SOAP serialisation is suitable as content encoding convention in the rst place. So, in contrast to RDF, an extra conversion step can be avoided completely.
The logical level is not yet covered for both approaches, RDF and SOAP.
For the future, it seems to make sense to work on both approaches without dooming the other. Even if looking at SOAP may split the Semantic Web community to some extend, competition may also set free a lot of development energy. P erhaps the logical layer to be built on top of RDF and SOAP may allow for an integration of both approaches at some future point of time.