This documents an RDF model for WSDL and discusses some of the architectural aspects of performing the translation.
This is a very rough document and represents consensus from only a few people.
The goal for the model was to represent the data in a WSDL file in a way that would be natural to understand and query in RDF. An RDF model with assertions like
document --hasElement-> WSDL:Definitions,
WSDL:Definitions --hasAttribute-> name is less compelling than one with assertions like
srvc:EndorsementSearch --rdf:type-> wsdl:Definition. To that end, I did more than interpret the DOM tree of the wsdl file, I attempted to suss out the uthor's intent. In the process, I may have grossly misintrepreted the intent. Please correct me if this is so.
This service description is a translitaration of Uche Ogbuji's example service description. The version for this example has the namespaces changed. This file was passed to an RDF parser which had a WSDL grammer stored in a perl data structure. This command:
algae -sClassRDFXML -a" \ (slurp '((../test/snowboard.wsdl)) \ ask '((?p ?s ?o)) collect '())" > snowboard.rdf
generated an RDF file upon which "typical"
(namespace '(rdf http://www.w3.org/1999/02/22-rdf-syntax-ns# wsdl http://schemas.xmlsoap.org/wsdl/ wssoap http://schemas.xmlsoap.org/wsdl/soap/) ask '(http://www.w3.org/2001/03/19-annotated-RDF-WSDL.rdf (rdf:type ?service wsdl:service) (wsdl:hasPort ?service ?port) (wsdl:binding ?port ?binding) (wssoap:style ?binding wssoap:document) (wsdl:name ?binding ?bindingName)) collect '(?port ?bindingName))
service queries could be run. (Note, this is only one query language; others are documented in a a query paper.) A picture of the above graph was generated with the command:
algae -sClassdot -a" \ (slurp '((../test/snowboard.wsdl)) \ ask '((?p ?s ?o)) collect '())" | dot -Tjpeg -o snowboard.jpg
The Calc description advertises three bindins, SOAP, HTTP POST, and HTTP GET (see the RDF description or the graphical representation. Thanks to Martin Gudgin who produced the WSDL in Visual Studio (I think). For a more managable view, see the POST, GET, and SOAP subgraphs.
The basic structure of a service having a port having a binding having a portType seemed to follow from WSDL 1.1. There were several other chioces that were not so clear.
The goal with regard to transport was to see what functionality could be achieved without any knowlegdge of how transport worked. This promotes the notion of orthogonal transports. A model client here would be a device that can locate a service without understanding any of the elements in the transport namespace and pass this data to another agent or dispatch it generically to a user-supplied transport handler.
Again, an agent that peers into the schema only as far as is necessary to pass structure information to the transport handler may look as far as the
xsd elements pass the nested DOM structure on.
WSDL and XML schema both use names within the document in a context-sensitive way. For instance, a port and an operation may both be called "GetEndorsingBoarder" but the service's port parameter specifies the port while the portType's operation parameter sepecifies the operation. RDF takes the web ideal of using URIs as unique identifiers as a given so it was necessary to add type information the the node names. The "GetEndorsingBoarder" operation was resolved against the service namespace concatenated with "absract_" while the port had "port_" added to it.
In general, I believe web architecture is furthured by having named elements treated as XML IDs and hope this restriction is added in later work.
Eric Prud'hommeaux Last modified: Wed Nov 14 18:57:55 EST 2001