W3C home > Mailing lists > Public > www-rdf-interest@w3.org > March 2001

Re: Toying with an idea: RDF Protocol

From: Ken MacLeod <ken@bitsko.slc.ut.us>
Date: 30 Mar 2001 10:07:24 -0600
To: <www-rdf-interest@w3.org>
Cc: "Henrik Frystyk Nielsen" <frystyk@microsoft.com>
Message-ID: <x5y9tnz1dv.fsf@bitsko.slc.ut.us>
"Henrik Frystyk Nielsen" <frystyk@microsoft.com> writes:

> I see a reference to the SOAP HTTP binding - I might be missing
> something but is there any reason why SOAP [1] could not be used as
> the protocol for carrying RDF data around.

That's entirely possible.  Given the number of SOAP routers that will
likely become available it would make a good carrier of RDF payloads in
many situations.

> - maybe even use the SOAP encoding [2]?

That too, but I envision less likely.  You'll need to convince the RDF
folks that a mapping between RDF and SOAP encoding is suitable first.

Unfortunately, it's the combination of SOAP envelope and SOAP encoding
that really make "just RDF" look so much more appealing.

An RDF "message" has a well defined and simple data model,
*always*[a], whether it's payload information or meta-information
about the payload.  This means that the serialization of RDF is rather

SOAP, on the other hand, has an envelope model where the header can
have arbitrary XML (under sub-elements of <SOAP-ENV:Header>), and the
SOAP encoding model is quite complex in comparison to RDF.

As you note in a later message, the focus is on the XML document.
I'll add that it's the effort necessary to process it.  Beyond that,
the parallels are often very direct.

I think the key distinction is whether one would want to process
messages via the DOM (as most SOAP implementations do) or via an RDF
API, and what effect that has on the message data model and the
architecture that surrounds it.

  -- Ken

> [1] http://www.w3.org/tr/soap/
> [2] http://www.ilrt.bristol.ac.uk/discovery/2000/08/www9-slides/henrik/

[a] Although usage of the model can get heavy into the abstract, at
Received on Friday, 30 March 2001 11:43:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:29 UTC