Re: Choreography and the Semantic Web

Exactly!

In addition, the program will want to speak only to thermometers that 
speak
the dialect(s) of temperature that it understands. Similarly, a programmer
will want to have some clue as to what dialects of temperature are spoken
by the various thermometers so that she can develop the requisite code 
that 
can interact with an appropriate subset.

There's a significant design-time aspect to Web services that plays an
important role in enabling the run-time aspect.

Today's (browser-centric) Web works because what's at the end of an 
embedded
link in an html document is more likely than not going to return 
text/html, or some
other media type, that the user agent can further process (render for 
human consumption). 
The human provides the logic that really processes the information. The 
browser is
mostly concerned with rendering.

If I define a schema for a representation of a resource that contains
links (URIs) that are to be followed for further processing as has been 
suggested,
there can be little gleaned from that URI alone (or from the schema that 
defines
the document containing the URI) as to what manner of resource
I might be expected to find at the end of that URI such that one could 
prepare
the program for what to expect if dereferenced.

Consider the following. The process implied is that you GET a Room 
(somehow)
before you can determine its temperature (also via GET, nice and RESTful):

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault
="qualified" attributeFormDefault="unqualified">
        <xs:element name="Room">
        </xs:element>
        <xs:complexType name="tRoom">
                        <xs:sequence>
                                <xs:element name="Dimensions" type="
tDimensions"/>
                                <xs:element name="Temperature" type="
xs:anyURI"/>
                        </xs:sequence>
        </xs:complexType>
        <xs:complexType name="tDimensions">
                <xs:sequence>
                        <xs:element name="Length" type="xs:integer"/>
                        <xs:element name="Width" type="xs:integer"/>
                </xs:sequence>
        </xs:complexType>
</xs:schema>

What can the developer do with the above? It tells him nothing about what
manner of resource representation it might expect to retrieve from the
URI content of the Temperature element. The documentation provided in the
schema above is a dead end in that regard. What is needed is something 
that
can enlighten the programmer as to what to expect in response to 
retrieving the
representation of the (assumed) temperature resource found at that URI.

Some further qualification of the type of resource to which the link 
refers is 
needed at the very least. 

Cheers,

Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624

David W. Levine wrote on 08/12/2002 02:24:32 PM:

> 
> At 11:01 AM 8/12/2002 -0400, Mark Baker wrote:
> 
> >On Mon, Aug 12, 2002 at 09:45:38AM -0400, Christopher B Ferris wrote:
> > >
> > > Mark,
> > >
> > > And there is much that SOAP/WSDL do that RDF doesn't.
> >
> >Yes, but very little of it is necessary when you don't have a priori
> >knowledge of the type of service you're interacting with, as the Web
> >presumes.
> >
> >SOAP/WSDL, in common use, presupposes that when the code is written,
> >it knows the difference between a thermometer and a television.  REST
> >does not.
> 
> REST, may or may not. Programs and programmers, however do know what 
sort
> of resources they understand, and to a much lesser extent, what sort of 
> resources
> they don't understand. (They have a very precise understanding of things 

> they understand
> and very little understanding of anything they don't understand.)
> 
> Programs don't start invoking services without context, nor without 
goals 
> and specific
> capabilities. At the end of the day, software can only couple up to the 
> services and
> resources it understands. A program attempting to determine the current 
> temperature
> in New York City is not only likely to understand what a thermometer is, 
it 
> is unlikely
> to want to talk to anything that *isn't* a thermometer. Ignoring, for 
the 
> moment, how it
> came to chose a specific URI to invoke, a program trying to interact 
with 
> another chunk
> of code is going to be able to do no more, and no less than what it is 
> programmed to do.
> 
> - David
> 
> 
> > > There is NOTHING that prevents one from using RDF in the context of 
Web
> > > services technologies (e.g. carrying RDF graphs in the SOAP header 
or
> > > body,
> > > extending WSDL with RDF, or even representing a WSDL description 
using
> > > RDF), or not as one sees fit.
> >
> >There's nothing that *prevents* RDF from being used with SOAP/WSDL, but
> >as I said, the earlier form of binding with SOAP/WSDL makes RDF
> >unnecessary (note, this is a *bad* thing 8-).
> >
> >MB
> >--
> >Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> >Ottawa, Ontario, CANADA.               distobj@acm.org
> >http://www.markbaker.ca        http://www.idokorro.com
> 
> David W. Levine
> IBM Thomas J. Watson Research Center
> Autonomic Computing Tooling and Standards
>