 | Level: Introductory Uche Ogbuji (uche@ogbuji.net), Principal Consultant, Fourthought, Inc.
01 Feb 2002 This article examines ways that SOAP can be used to communicate information in RDF models. It discusses ways of translating the fundamental data in RDF models to the SOAP encoding for PC-like exchange, or for directly passing parts of the model in RDF/XML serialized form.
SOAP is a transport protocol for carrying XML payloads over
lower level Internet protocols. Specifications of the transport prior to
1.2 built in a suggested encoding of XML that is geared towards the
serialization of programming language constructs. Such encodings are the
staple of what is known as remote procedure call (RPC) systems, which
have the common aim of making requests to remote computers look just like
local procedure invokations. Other examples of RPC encodings are External
Data Representation (XDR), from "classic" RPC (and defined in RFC 1014), and
Common Data Representation (CDR) from CORBA. As a result of bundling
an encoding with such relatives, SOAP took on a decidedly
application-programming feel, and its usefulness for general data exchange
seemed suspect.
These early flavors of SOAP generated much controversy. Firstly,
mixing transport and data encoding specifications seems to be a very
messy approach to communications, and seems to fly in the face
of layered protocols that have been the practice in networking for
decades. After all, the specification for HTML mark-up is not embedded
into the HTTP specification. Secondly, choosing an RPC-like encoding for
pre-eminence puts SOAP in an odd spot; it has little more expressive power
than pre-XML RPC mechanisms, yet it is practically guaranteed to be
less efficient because of XML's verbosity and the more generic
architectures of HTTP, SMTP, and the like. It would seem that the only
advantage SOAP brought as a next-generation RPC was to unify the
Microsoft and CORBA camps; this is important, but certainly not what SOAP
appeared to be promising.
One important down-side consequence of SOAP-as-RPC is that such a
system is completely unsuitable for the next-generation-EDI ambitions
of Web services in general. If Web services are to become the new way
businesses communicate over networks, they would seem to need a
transport mechanism that communicates at the level of business
and legal requests, rather than at the level of programming language APIs.
And surely enough, the ebXML initiative, whose ambition is to use
XML to craft a system for international electronic business communication,
originally balked at using SOAP, as did a few other influential organizations.
Things have settled down a bit since then. SOAP 1.2 has somewhat relaxed
the dependence on the special encoding (relegating it to a separate
"adjuncts" section), and most players are now on board
with SOAP, including ebXML. Most SOAP implementations still use the
special SOAP encoding exclusively, but there are signs that this state
of affairs will open up more, with plug-in architectures for wider
choice of encodings, addressing a greater set of communication problems.
One such problem is the exchange of metadata, including metadata that
helps determine the semantics used in other XML documents transmitted using
SOAP.
Resource Description Framework (RDF) is a modeling system with
some facilities for addressing just such metadata exchange. This
article will look at how RDF can be used with SOAP for the encoding of
such metadata, or even at how data instances encoded in RDF can be directly
transmitted without a translation to the SOAP encoding. Familiarity
with SOAP and RDF are required. See Resources for more on these topics.
Also, see the Thinking XML column in the IBM developerWorks XML zone for
on-going discussion of RDF and other XML technologies related to knowledge
management.
The good ship RDF
First of all, I'll show what you can do if you have RDF to ship from one
system to another care of SOAP. I'll take an example from the on-going
issue-tracker project discussed in my Thinking XML column on XML zone (see Resources). Let's say that
we want to exchange details of an issue that has been added to a system to
a remote machine. This might be the basis for a decentralized, distributed
issue tracker. An example of what an issue looks like in RDF serialization
is shown in Listing 1.
<?xml version="1.0"?>
<rdf:RDF xmlns:it="http://rdfinference.org/schemata/issue-tracker/"
xmlns:dc="http://purl.org/dc/elements/1.1#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xml:base="http://rdfinference.org/versa/issues">
<it:issue rdf:ID="0101">
<dc:relation rdf:resource="http://rdfinference.org/versa/0/2"/>
<dc:identifier>0101</dc:identifier>
<dc:creator rdf:resource="mailto:uche.ogbuji@fourthought.com"/>
<dc:date>2002-01-27</dc:date>
<dc:title>Data type conversions</dc:title>
<dc:description>Not all the data type conversions listed make sense.
In particular the question of how to convert numeric types to resources
and vice versa require much thought.</dc:description>
</it:issue>
</rdf:RDF>
|
This is an example issue raised against a Web resource. The issue itself is
identified by the URI http://rdfinference.org/versa/issues#0101.
This is determined by taking the base URI of the document and adding a
fragment as given by the rdf:ID attribute on the typed
node representing the issue. The base URI of the document (or to be precise,
of the document element, and therefore of the typed node element itself)
is given as http://rdfinference.org/versa/issues using an
xml:base attribute. You then make several statements about the
issue itself, most importantly giving the resource to which the issue
refers using the dc:relation metadata tag from Dublin Core.
You also provide an identifier, which is just an abbreviation of the full URI
of the issue for friendly display, the creator of the issue, date submitted,
brief title, and verbose description.
Remember that this is RDF, and thus the XML serialization is not the most
important matter, but rather how this translates to an abstract RDF model.
For instance, Figure 1, generated by Triclops, an RDF visualization tool
that comes with 4Suite 0.12.0 alpha 1 or more recent (warning: this generates a pretty wide image).
You can also generate a similar graph using Dan Brickley's on-line RDF visualizer.
Figure 1: Graph rendition of sample RDF model
Now I'll look at two ways of transmitting this model in a SOAP message;
first of all by translation to the SOAP encoding, and then directly, encoding
in RDF.
Using the SOAP encoding
First of all, you must come up with a method for the transmission. The RDF
you have defined is a bundle of data, and the idea is to pass along this
bundle of data in a message, which you name according to what we expect the
recipient to do with the data. In this case, you are notifying the remote
server that there is a new issue to track. Therefore I have called the
method newIssue. Note that since for now, you are using the
SOAP encoding, you might as well keep your method names suitable for the
programming languages that have SOAP bindings for RPC.
You then have to find a way to transmit the new issue object. You do so
by transmitting the ID of the new object, and its properties.
Basically, you peel off each property of the new issue object and convert
to a message parameter. Because the SOAP encoding is heavy on type
information, you must decorate each parameter with a type (see Listing 2).
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope">
<env:Body>
<itsoap:newIssue
env:encodingStyle="http://www.w3.org/2001/12/soap-encoding"
xmlns:itsoap="http://rdfinference.org/schemata/issue-tracker/soap"
xmlns:it="http://rdfinference.org/schemata/issue-tracker/"
xmlns:dc="http://purl.org/dc/elements/1.1#"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<dc:identifier xsi:type="xs:nonNegativeInteger">0101</dc:identifier>
<dc:relation xsi:type="xs:anyURI">http://rdfinference.org/versa/0/2</dc:relation>
<dc:creator xsi:type="xs:anyURI">mailto:uche.ogbuji@fourthought.com</dc:creator>
<dc:date xsi:type="xs:date">2002-01-27</dc:date>
<dc:title xsi:type="xs:string">Data type conversions</dc:title>
<dc:description xsi:type="xs:string">Not all the data type conversions listed
make sense. In particular the question of how to convert numeric types to
resources and vice versa require much thought.</dc:description>
</itsoap:newIssue >
</env:Body>
</env:Envelope>
|
All values are placed in the contents of elements, as required by the SOAP encoding
rules, this includes values that were marked as resources in the RDF,
and are thus given the data type anyURI. Note that this
allows values that are URI references as well as full URIs (that is, relative
URIs and fragments are allowed). If you say that all such messages will
have this format, you can avoid having to reiterate the data types each time
by defining an XML schema definition for the message element, which
can then be placed in a Web Services Description Language (WSDL)
element or communicated in some other out-of-band manner.
Listings 3 and Listing 4
are fragments (with root elements and namespace declarations elided)
from such schemata (given separately because they would
occupy different target namespaces).
<!-- with target namespace = http://rdfinference.org/schemata/issue-tracker/soap -->
<xsd:element name="newIssue">
<xsd:complexType>
<xsd:all>
<xsd:element ref="dc:identifier"/>
<xsd:element ref="dc:relation"/>
<xsd:element ref="dc:creator"/>
<xsd:element ref="dc:date"/>
<xsd:element ref="dc:title"/>
<xsd:element ref="dc:description"/>
</xsd:all>
</xsd:complexType>
</xsd:element>
|
<!-- with target namespace = http://purl.org/dc/elements/1.1# -->
<xsd:element name="identifier" type="xsd:nonNegativeInteger"/>
<xsd:element name="relation" type="xsd:anyURI"/>
<xsd:element name="creator" type="xsd:anyURI"/>
<xsd:element name="date" type="xsd:string"/>
<xsd:element name="title" type="xsd:string"/>
<xsd:element name="description" type="xsd:string"/>
|
These would allow the SOAP message to be simplified as in Listing 5.
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope">
<env:Body>
<itsoap:newIssue
env:encodingStyle="http://www.w3.org/2001/12/soap-encoding"
xmlns:itsoap="http://rdfinference.org/schemata/issue-tracker/soap"
xmlns:it="http://rdfinference.org/schemata/issue-tracker/"
xmlns:dc="http://purl.org/dc/elements/1.1#"
>
<dc:identifier>0101</dc:identifier>
<dc:relation>http://rdfinference.org/versa/0/2</dc:relation>
<dc:creator>mailto:uche.ogbuji@fourthought.com</dc:creator>
<dc:date>2002-01-27</dc:date>
<dc:title>Data type conversions</dc:title>
<dc:description>Not all the data type conversions listed make sense.
In particular the question of how to convert numeric types to resources
and vice versa require much thought.</dc:description>
</itsoap:newIssue >
</env:Body>
</env:Envelope>
|
Sending raw RDF
As I argued at the beginning of this article, there is no reason you
should have to mutate our SOAP message into RPC form in order to use SOAP.
If you are not locked in by the need for RPC integration into other systems,
you can take the more natural course, the declarative approach
of sending the data and leaving the remote system free to process it
as seen fit. There is no official RDF encoding for SOAP yet, but this
discussion is based on the conventions and prescriptions of RDF and SOAP.
The simplest approach is simply to make the rdf:RDF element the
single top-level element of the SOAP body, as illustrated in Listing 6.
<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope">
<env:Body>
<rdf:RDF env:encodingStyle="http://rdfinference.org/rdfws/soap-encoding"
xmlns:it="http://rdfinference.org/schemata/issue-tracker/"
xmlns:dc="http://purl.org/dc/elements/1.1#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
>
<it:issue rdf:about="http://rdfinference.org/versa/issues#0101">
<dc:relation rdf:resource="http://rdfinference.org/versa/0/2"/>
<dc:identifier>0101</dc:identifier>
<dc:creator rdf:resource="mailto:uche.ogbuji@fourthought.com"/>
<dc:date>2002-01-27</dc:date>
<dc:title>Data type conversions</dc:title>
<dc:description>Not all the data type conversions listed make sense.
In particular the question of how to convert numeric types to resources
and vice versa require much thought.</dc:description>
</it:issue>
</rdf:RDF>
</env:Body>
</env:Envelope>
|
The encoding ID used, http://rdfinference.org/rdfws/soap-encoding is non-normative, and basically codifies the enbedding of RDF/XML directly
into the body of a SOAP message. One key difference between the message form
and the plain form is that rdf:about is used to identify the
issue resource, however, it is not declared in-line using an ID. This is an important
principle for serializing RDF models for SOAP transmission: to avoid in-line
declarations. Given that we could fix the base location for the ID using
xml:base, such a principle might seem unnecessary, but it is
hard to imagine any clear semantics for the life-cycle and ownership of
in-line transmitted resources. Note that they cannot be avoided in all cases.
For instance, anonymous resources (AKA blank nodes) may need to be
transmitted as part of descriptions, and by definition they have no proper
identifier.
Conclusion
There are other approaches and ideas when it comes to how SOAP and RDF can
inter-operate, and indeed it is a topic of constant interest as RDF users
discover Web services and vice versa. References to some of this discussion
are provided in the Resources section. Certainly more generic systems
for serializing XML-based data will only enrich the world Web services.
Resources -
4Suite, a suite of XML and RDF tools co-developed by Uche Ogbuji.
- Dan Brickley's RDF visualizer is handy for generating RDF graphs, if you already have the serialized XML available on the Web.
About the author | 
| |
Uche Ogbuji is a consultant and co-founder of Fourthought Inc., a software vendor and consultancy specializing in XML solutions for enterprise knowledge management applications. Fourthought develops 4Suite, an open source platform for XML middleware. Mr. Ogbuji is a Computer Engineer and writer born in Nigeria, living and working in Boulder, Colorado, USA. You can contact Mr. Ogbuji at uche@ogbuji.net. |
Rate this page
| |
