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.

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.

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.

The power of RDF as a data expression language is revealed when data from previously separate applications are joined together in a query. For instance, it is trivial to join a service description against an RDF-based access control system or CC/PP-defined document transformation proxies.

pick a grammer

The WSDL grammer uses a data structure to describe what happens when a particular element or unknown element is started or ended, as well as what to do with encountered CDATA. It makes sense to use a standar schema language. This is non-trivial as the same langauge is used to process RDF/XML which has no predictable elements, but instead needs to change production rules for each level of nesting (roughly alternating between typedNode and propertyElt). This may be possible anyways, not sure.

pick a grammer RDF-API language

The WSDL grammer uses an arbitrary (though minimal) language to make RDF database API calls. It may be reasonable to express these calls in a declarative language or ontology, or perhaps pick a more universal procedural language like java byte code.