Copyright © 2005 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
Web Services Description Language (WSDL) provides a model and an XML format for describing Web services. This document describes a representation of that model in the Resource Description Language (RDF) and in the Web Ontology Language (OWL), and a mapping procedure for transforming particular WSDL descriptions into their RDF form.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is a W3C First Public Working Draft, produced by the Web Services Description Working Group, as part of the W3C Web Services Activity.
The final disposition of this deliverable is currently under discussion. The Web Services Description Working Group charter puts this deliverable on the Recommendation track, but the Working Group has concerns about its ability to deliver on this goal. Primary among those concerns are:
If the Working Group is unable to satisfactorily address these concerns, it may pursue alternate dispositions of this material, such as transferring this deliverable to a Working Group more representative of the customers of this work, or publishing it as a Working Group Note rather than a Recommendation.
The Working Group therefore calls for communities relying on this deliverable to identify themselves and provide requirements and feedback on mechanisms to promote wider member and public investment in, and review of, this work. This feedback, as well as technical comments on the document, are invited and are to be sent to the public public-ws-desc-comments@w3.org mailing list (public archive).
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document has been produced under the 24 January 2002 Current Patent Practice as amended by the W3C Patent Policy Transition Procedure. Patent disclosures relevant to this specification may be found on the Working Group's patent disclosure page. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) with respect to this specification should disclose the information in accordance with section 6 of the W3C Patent Policy.
1. Introduction
1.1 Organization of this specification
2. WSDL Ontology
2.1 Core WSDL Components
2.1.1 Description component
2.1.2 Interface classes
2.1.3 Binding classes
2.1.4 Service classes
2.2 Handling Features, Properties and Generic Extensions
2.2.1 Features and properties
2.2.2 Generic extensions
2.3 Message Exchange Patterns
2.4 Predefined Extensions
2.5 Operation Styles
2.6 SOAP Binding
2.7 HTTP Binding
3. Differences from the WSDL Component Model
3.1 Component naming
3.2 Documents, imports and includes
3.3 Component references
3.4 Representing properties with classes
Web Services Description Language is defined in XML, because XML is the standard format for exchange of structured information. The use of XML brings great interoperability in for WSDL generators and parsers, and the use of XML Schema makes the structure of WSDL well constrained, yet extensible. On the other hand, XML vocabularies in general don't have clear composition rules, so combining for example the WSDL description of a Web service, the service's policies and other information (presumably expressed in XML) can be done in many significantly different ways (e.g. extending WSDL, extending the policy language, creating a special XML container for all the information etc.), and little interoperability can be expected when such combined documents are used.
For example, a policy can be combined with WSDL by adding the policy elements in WSDL service element. Equally, a WSDL description can be combined with a policy by adding the WSDL description as part of the policy. While the result should be similar (WSDL combined with policy is the same as policy combined with WSDL, right?), they are in fact very different for the processing software, and a policy in WSDL cannot easily be used by software that doesn't know WSDL.
In contrast, the Semantic web requires knowledge from many different sources to be easily combined so that unexpected data connections can be used. For this purpose there is the Resource Description Framework (RDF), whose graph structure together with the use of URIs for identifying nodes makes it very easy for different documents to be brought together. If a WSDL document describes about a Web service, a policy document attaches constraints to the service and a general description specifies the author of the service, all this information can be merged and the resulting document will contain all the three kinds of information assigned to the single service.
The main objective of this specification is to present a standard RDF vocabulary equivalent to WSDL 2, so that all WSDL 2 documents can be transformed into RDF and merged with other Semantic Web data.
Note: the readers of this document are expected to have understanding of the WSDL language and the WSDL component model; this document is not a standalone specification of the WSDL ontology, independent of WSDL specification. Further, the readers are expected to have good knowledge of RDF and at least basic knowledge of OWL.
This specification is split into five main parts — three sections and two appendices:
This section describes the OWL ontology for WSDL, comparing it to the WSDL component model defined in WSDL2 Core. While the text in this section may imply how the components might be mapped to their RDF representation, such implications are not intended to be normative; for the formal normative mappings, see Appendix B.
This section may also briefly touch on some differences between the OWL ontology and the component model, but for the full account and rationalization of these differences see section 3.
The ontological equivalents for the core WSDL components defined in WSDL2 Core are described in section 2.1. All these components are extensible, so section 2.2 describes how features, properties and extensions are mapped to RDF. The following sections, from 2.3 to 2.7, describe the ontological equivalents for the various adjuncts specified in WSDL2 Adjuncts.
All the main components of WSDL are represented as classes in the WSDL
ontology: Description
, Interface
,
Binding
and Service
, as described in the following
subsections. This means that every interface, binding and service described
by WSDL will be mapped to a single instance in the RDF representation, linked
from the instance mapped from the top-level description component.
All the components in WSDL can contain documentation. Such documentation
consists of human-readable text and machine-processible elements and
attributes, but it isn't modeled in more detail in WSDL 2. Therefore in the
RDF mapping we represent documentation as XML literals, which should consist
of the wsdl:documentation
element and all its children. The
literal is attached to the appropriate component in the RDF representation
using the property documentation
.
The top-level WSDL component — description — is mapped to a
single instance of the class Description
, which uses the
properties interface
, binding
, service
,
typeDefinition
and elementDeclaration
to point to its
contents, i.e. all the interfaces, bindings, services, type definitions and
element declarations present (or included or imported) in this description.
Note that a mapping of a single WSDL document (together with any imports or
includes) will always result in a single instance of the
Description
class. However, there can be multiple individuals of
the class Description
in a knowledge base that contains the
information from multiple WSDL documents. The core WSDL specification does not
consider the case of combining multiple independent WSDL documents and that it
doesn't mandate that independent documents describe consistently components
with the same name. This is, however, an assumption when combining multiple
WSDL documents in the RDF representation.
All WSDL interfaces are represented in RDF as instances of the
Interface
class. WSDL interfaces can extend other interfaces,
which is indicated by the property extensionOf
. Interfaces may
have operations and faults, represented as instances of
InterfaceOperation
and InterfaceFault
classes and
each pointed to with the properties interfaceOperation
and
interfaceFault
, respectively.
There are a number of properties applicable to
InterfaceOperation
instances:
messageExchangePattern
property points to an instance of
the class MessageExchangePattern
and thus indicates the
message exchange pattern (MEP) used by this operation; there can be only one
MEP on one operationoperationStyle
property points to an instance of the class
OperationStyle
and indicates that the operation adheres to the
given style; there can be multiple operation styles on a single
operationinterfaceMessageReference
and
interfaceFaultReference
properties point to instances of
InterfaceMessageReference
and
InterfaceFaultReference
classes respectively, which are
described later.Interface faults, in turn, only contain a single pointer to an element
declaration, represented by the property elementDeclaration
and
pointing to a QName
instance.
Interface message references and interface fault references can indicate
their direction — input message references and input fault references
all belong to the class InputMessage
and output message
references and output fault references all belong to the class
OutputMessage
. Further, both message references and fault
references indicate the appropriate message labels (instances of
MessageLabel
, representing particular messages in the
operation's MEP) using the property messageLabel
. (In section 2.3 we describe how message exchange patterns are
modeled in our RDF mapping.)
Furthermore, interface message references point to element declarations
using the property elementDeclaration
and they specify their
message content model with the property messageContentModel
,
indicating one of the four possible instances of the class
MessageContentModel
. Interface fault references, on the other
hand, refer to their interface faults directly using the property
interfaceFault
.
WSDL bindings are represented in RDF as instances of the class
Binding
. To indicate a particular interface for which binding
information is specified with this WSDL binding, the particular
Interface
instance is pointed to using the property
interface
. Binding types (for example SOAP binding or HTTP
binding, as specified in WSDL2 adjuncts) are themselves
classes in RDF, so a binding type is indicated by belonging to the
appropriate class (using the property rdf:type
).
As the structure of bindings follows the structure of interfaces, we
represent binding operations and faults using the classes
BindingOperation
and BindingFault
respectively. The
parent binding points to them using the similarly named properties
bindingOperation
and bindingFault
. Binding
operations further contain message and fault references, represented as
instances of the classes BindingMessageReference
and
BindingFaultReference
, and pointed to by the properties
bindingMessageReference
and
bindingFaultReference
.
Within this structure, each component points to the appropriate component
from the interface structure, i.e. binding operations point to interface
operations, binding faults respectively point to interface faults and binding
message and fault references point to interface message and fault references.
To provide these pointers, we reuse the same properties that are used within
the interface structure, i.e. interfaceOperation
,
interfaceFault
, interfaceMessageReference
and
interfaceFaultReference
.
Finally, each component is supposed to contain extensions that provide the actual binding information. For the description of handling such extensions see section 2.2 and for the specific bindings included in WSDL 2 specification, see sections 2.6 and 2.7.
WSDL services are represented in RDF as instances of the class
Service
. Each instance must point to a single interface; for
this purpose we reuse the property interface
. Also, each service
has one or more endpoints, to which it points using the property
endpoint
.
Endpoints are represented as instances of the class Endpoint
,
with two notable properties: mandatory single binding
points to
the binding used by this endpoint, and optional single address
points to the network resource which actually offers the service.
In order to enable evolution and reusability of the language, WSDL 2 allows extensions on all components. In fact, there are multiple types of extensibility in WSDL 2: extension points, abstract features and properties, and generic XML-based extensions.
Extension points are those places in WSDL where a number of options is defined by the WSDL 2 specification, but the list is open. For example, interface operations follow message exchange patterns (MEPs), and while WSDL 2 provides a list of eight MEPs, new ones can be specified by WSDL 2 users. Similarly, WSDL 2 specifies two bindings (SOAP and HTTP), but more bindings are expected to be specified in the future, either by the WS-Description Working Group or by any interested third parties. Often, extension points use URIs to refer to the various options, but often the extensions introduce data that needs to be modeled in the RDF representation of WSDL 2, in which case it is the responsibility of the extension designers to describe their mappings to RDF.
Features and properties represent abstract pieces of functionality and their run-time parameters. Mostly, features and properties simply use URIs to identify their semantics, and this easily translates into RDF, as described below in section 2.2.1.
Apart from the envisioned extensibility points and the abstract functionality extensibility using features, WSDL 2 allows the XML WSDL documents to contain any "foreign" elements and attributes, so that unexpected extensions, even ones that change the core WSDL semantics, can also be realized. Mapping such extensions to RDF is described in section 2.2.2.
Every feature component is mapped to RDF as an instance of the class
Feature
. This instance is identified by the feature's IRI, i.e.
the value of the {ref} property of the feature component.
Features can be required or optional. In RDF, this is indicated by the
property that points from the feature's parent component to the feature
— it is either the requiresFeature
or the
offersFeature
property.
Property components in WSDL 2 serve to specify or constrain the value that
a property can have at run time. As one of the few naming differences between
the RDF representation and the WSDL 2 component model, the property
components are represented as instances of the class
PropertyValue
, pointed to from the property's parent component
using the propertyValue
RDF property.
Every PropertyValue
instance points to the actual property
whose value it specifies, using the RDF property named property
.
PropertyValue
instances also either specify the actual value of
the property (using the RDF property propertyActualValue
) or
they constrain the possible values of the property using a type definition
identified by its QName
(referenced from the
PropertyValue
instance by the RDF property
propertyValueType
).
The actual meaning of general extensions is, by definition, unknown to the WSDL specification, and it is equally unknown to the RDF mapping. Therefore every extension should specify how it is mapped to RDF. For example, the SOAP and HTTP bindings in WSDL 2 add many properties to the core binding components and this document defines how these particular properties are expressed in RDF. The mapping of extensions to RDF therefore depends on the understanding of those extensions. This section describes how unknown extensions are handled when mapping a WSDL document into RDF.
In WSDL 2, extensions can be marked as mandatory (or required). Such extensions may alter the semantics of the extended components in ways that invalidate the existing semantics. Since the RDF representation of WSDL intends to represent the semantics of the WSDL data, components with unknown required extensions must be mapped to RDF according to the rules of the extension, not according to the rules specified in this document. This is to avoid confusing processors that don't understand a mandatory extension — RDF encourages the principle of ignoring the unknown parts of an RDF graph (partial understanding) and there is no agreed mechanism of marking some parts as mandatory, therefore if we decided to map the known WSDL according to our rules and add the mandatory unknown extensions in the graph, they could be ignored by some RDF processors, violating their mandatoriness.
Finally unknown optional extensions (not mandatory) can be represented in
the RDF representation using the properties extensionElement
and
extensionAttribute
. Extension elements are represented as XML
literals containing the whole extension XML elements (and should also include
all the in-scope namespaces and the XML base); extension attributes are
represented as instances of the class ExtensionAttribute
, which
in turn have a name (property attributeName
pointing to a
QName
) and a value (property rdf:value
pointing to
a literal containing the attribute value).
Such representation of unknown optional extensions is not intended to be used by processors that understand those extensions; instead such processors should reinterpret the XML literals and map them into the appropriate RDF extensions of the rest of the RDF representation.
WSDL 2 defines an extensible set of message exchange patterns (MEPs). There are 8 predefined MEPs, each following one of the three predefined fault propagation rules. Every WSDL MEP defines a set of message labels by which message references in operations can position themselves within the pattern.
In the RDF representation of WSDL, message exchange patterns are
represented as instances of the class MessageExchangePattern
.
The three predefined fault propagation rules are disjoint subclasses of that
class, named NoFaults
, FaultReplacesMessage
and
MessageTriggersFault
.
All MEPs are identified by IRIs, and the RDF ontology for WSDL only puts
the MEPs in the correct classes; for example
http://www.w3.org/2005/08/wsdl/in-only
is an instance of the
class NoFaults
. The message labels, however, are plain string
names, and the RDF ontology for WSDL gives each of them an IRI formed by the
MEP IRI, the hash sign '#' and the actual message label, and these IRIs are
referenced from the MEPs with the property definesMessageLabel
.
Any newly created MEPs should also provide URIs for the message labels, as
the RDF mapping depends on being able to identify the message labels on
interface message references.
WSDL 2 Adjuncts contain a single predefined extension, called Operation Safety, which adds a property to interface operation components to indicate whether an interface operation is known to be safe in terms of Web Architecture.
In the RDF representation of WSDL, we introduce the class
SafeInteraction
— any InterfaceOperation
instance that is also a SafeInteraction
is asserted to be
safe.
WSDL 2 predefines 3 operation styles — RPC style, IRI style and
Multipart style. These styles are identified with their IRIs, which the RDF
ontology makes instances of the class OperationStyle
.
The RPC style additionally introduces the property {rpc signature}, which
is represented in RDF using the property signature
, whose value
is a literal whose datatype is the signature type defined by WSDL 2. The
signature
property can be attached to interface operations
following the RPC style to indicate the parameter order for the
operation.
WSDL bindings that bind to SOAP are identified (using the property
rdf:type
) as instances of the class
http://www.w3.org/2005/08/wsdl/soap
. Every such binding must
indicate the SOAP version that it uses, this is done with the property
version
(with a value "1.2", for example, meaning SOAP version
1.2). Every binding also must specify with the property protocol
the underlying protocol that is uses.
Each SOAP binding operation must specify the SOAP message exchange pattern
it uses — the appropriate URI from the SOAP specification is pointed to
using the property soapMEP
. The ontology also introduces the
class SOAPMessageExchangePattern
that contains all the SOAP
MEPs.
SOAP binding operations can also specify the value of the action parameter
(known as SOAP action) for the initial message, using the
property action
.
Binding faults in the SOAP binding can specify two properties —
fault code and fault subcodes. Both fault code and subcodes are QNames, and
they are pointed to using the properties faultCode
and
faultSubcode
. The latter is repeated for each subcode that the
binding fault specifies.
At any level within a SOAP binding, components can declare the use of a
SOAP module. Required modules are pointed to using the property
requiresSOAPModule
and optional modules are pointed to using the
property offersSOAPModule
— both of these properties point
directly from the parent component to the SOAP module, as identified by its
URI (parameter {ref} in the SOAP Modules component (todo ref)).
Message references and faults in SOAP bindings can further declare that
they include specific SOAP headers. To do this, the property
header
can point to an instance of the class
SOAPHeader
, which then uses the property
elementDeclaration
to specify the exact element that represents
the header. Instances of SOAPHeader
can also belong to the class
MustUnderstandSOAPHeader
, which means that this SOAP header will
be marked as mandatory (mustUnderstand="true") in the message.
Apart from these SOAP-binding-specific properties, the SOAP binding reuses underlying protocol properties, for example some HTTP binding properties when the underlying protocol is HTTP. The following section describes the HTTP binding properties.
WSDL bindings that bind to HTTP are identified as instances of the class
http://www.w3.org/2005/08/wsdl/http
. The HTTP bindings that make
use of HTTP cookies are further identified as instances of the class
HTTPBindingWithCookies
. Every HTTP binding must specify the HTTP
version in use, which is done with the property version
(in a
different namespace from the property version
in the SOAP
binding), for example HTTP/1.1 is specified with the value "1.1".
HTTP binding operations can specify a number of HTTP parameters:
operation-specific location, HTTP method, input and output and fault
serialization, and query parameter separator. These parameters are
represented in RDF with the properties location
,
method
, inputSerialization
,
outputSerialization
, faultSerialization
and
queryParameterSeparator
. The values of all these properties are
literals, same as in the XML syntax of WSDL.
Message references and faults in an HTTP binding can specify the use of
extra HTTP headers by pointing to a QName with the property
header
. Message references and fault references in HTTP binding
operations can also specify the transfer coding using the property
transferCoding
with a literal string value, as in the XML
representation. Finally, faults can further specify the HTTP status code they
will be accompanies with, using the property errorCode
.
HTTP bindings can also specify access authentication parameters, in
particular authentication type and realm. These parameters are reflected with
the properties authenticationType
and
authenticationRealm
with string values.
WSDL defines a component model which consists of components, component properties and sets of components. This document supplies an ontology (i.e., a set of classes, properties, datatypes, and distinguished individuals) for representing WSDL data. This ontology contains axioms which express some of the constraints the WSDL specification imposes on legal sets of WSDL components whether indirectly (via the XML Schema constraints on the infoset which canonically encodes WSDL component models) or directly (via the natural language of the WSDL specs, or the corresponding Z formalizations of that language).
RDF, RDFS, and OWL are all less (and differently) expressive than the subset of Z used to formalize the WSDL specification, and are designed for different purposes. In a nutshell, RDF, RDFS, and OWL are relatively small fragments of first order logic, whereas Z encompasses all of first order logic plus set theory. Z supports validation of component models, that is, the acceptance or rejection of component models. This includes type checking, consistency checking, and the verification of integrity constraints. The current set of Semantic Web langauges focus on inference and integration of information. To take a simple example, if a Z checkable representation of an Interface component lacks a {name} component property, a Z based validator will complain that that representation is ill formed (given the WSDL specification). An OWL reasoner encountering it will, all other things being equal, conclude that there is such a property, albeit unknown.
RDF, RDFS, or OWL documents using the ontology presented in this document may describe component models which are incomplete, or illegal, or contain extentions (new components, etc.). They may contain multiple unrelated Descriptions, that is, they may be aggregations of many unrelated WSDL documents. In general, Semantic Web based descriptions of Web services using the WSDL conceptual framework tend to be looser than what the WSDL spec prescribes.
Apart from this difference stemming from the fundamental intentional differences between strict specification (supporting validation) and Semantic Web modeling (supporting inference), there are a number of other differences between the ontological model presented in this document and the component model of WSDL. These differences are detailed in the following subsections.
In the RD representation, all WSDL components are identified with their respective component designators (see todo ref), which are URIs generally constructed from the namespace and name of the component and from its parent component hierarchy. The original names and namespaces are not explicitly modeled in the RDF representation, which intends to convey the semantic meaning of the WSDL component, not the WSDL serialization details.
In some situations we can see the RDF representation to be used as an exchange syntax for WSDL. While it's not an intended use, it is possible that in some systems the XML syntax will be lost or inaccessibly hidden in several layers of processing software. Such an application that only receives the RDF form of WSDL can still need to reconstruct the original component names, for example if it uses an API that identifies WSDL operations by their parent interface's QName and the operation name.
The component designators put the names of the components in the fragment
identifier part of the resulting URIs. On the Web [todo ref webarch], the
interpretation of fragment identifiers is defined by the MIME media type of
the representation of the resource identified by the URI without the fragment
identifier. In our particular case, we expect that the namespace URI
identifies an application/wsdl+xml
document so that the constructed component
designator fragment identifiers can have their intended meaning. An
application working with the RDF representation of WSDL can reconstruct the
names of the components by reversing the process that resulted in the
component designator, for example for a URI
http://example.com/service#wsdl.interfaceOperation(TicketInterface/BookTicket)
we
could reconstruct that the name of the interface is "TicketInterface" in the
namespace http://example.com/service
and that the operation is named
"BookTicket". Such decomposition is only valid, though, if the URI
http://example.com/service
identifies a document of MIME media type
application/wsdl+xml
, as explained above.
Checking the MIME media type of every resource identified by a URI in an RDF
graph could be prohibitively slow for some applications, therefore it
may be practical (albeit not entirely correct) simply to assume the correct
media type and deconstruct the component names without the preceding media
type check. Such applications, though, must be aware that in the RDF
representation it is possible to assert about any resource (identified by any
kind of URI) that it is, for example, a WSDL operation, and if an application
tries to deconstruct that URI according to WSDL component designator
specification, it may find that the URI doesn't conform to the syntax (e.g.
http://example.com/service/operation)
or, by accident or malice, it does
conform to the syntax but doesn't contain the correct data (e.g.
http://example.com/service#wsdl.interface(TicketInterface)
that is marked to
be a WSDL operation, not an interface as it would seem).
While the RDF representation of WSDL contains the Description component representing a logical group of WSDL components, these components can also be viewed as free-floating pieces of description, which should be easily combinable with other information about related resources. Strictly speaking, interfaces don't need to belong to any Description, and interface operations don't actually need to belong to any interface in the RDF representation.
In the XML syntax for WSDL, documents can be included and imported, allowing for modularization while keeping the ability to validate that a WSDL document (plus all the includes and imports) doesn't use any unknown components. In RDF, data can generally be split into any number of pieces, which can be put together by the application as appropriate. If a piece of WSDL description uses an unknown component (an interface described in one document may extend other interface, not described in this document), the application may, if necessary, attempt to locate the description of the unknown component using its identifier IRI.
The same reasoning applies to the schema documents included and imported in WSDL. All references to element declarations and type definitions are done by QName in the RDF representation and we expect the applications processing this representation to have means of locating the appropriate descriptions for these QNames. We do not model XML Schema (or any other) type and element descriptions in this ontology.
In the XML representation of WSDL, components are refered to using their
names, and extensibility points usually use IRIs to identify things. All
these references are, from XML point of view, literals. In the RDF
representation, on the other hand, most references are direct, using the
particular identifier IRIs, not represented as literals. For example, most
instances representing components are identified with their component
designators (see todo ref) and all references point directly there. The one
notable exception are references to type definitions and element declarations
(usually from XML Schema) which are represented as instances of our class
QName
, with both namespace and local part represented as
literals. This might change if a standard RDF representation for XML Schema
element declarations and type definitions is developed — then direct
references to the URIs used in that representation would be used.
Ednote: Additionally, certain components in WSDL are only pointers, they only have a single literal property that points to an external thing. For example, the feature component only carries the URI of the feature, and the HTTP Header component only carries an element QName. While these components can contain documentation and extensions in WSDL2, we chose to represent these components as direct links from the parent component to the target feature or the element QName, as the indirection seems to add very little value.
In certain cases the RDF mapping introduces classes where the WSDL 2
component model has a property with a limited number of values. For instance,
instead of having a direction property on message and fault references, with
the values either "in" or "out", we introduce two classes,
InputMessage
and OutputMessage
, and the direction
of a particular message or fault reference is then indicated by belonging to
either of these classes. Similarly, binding types are classes and the type of
a particular binding is indicated by its belonging to that class; we
predefine the two classes for the two bindings that are part of WSDL 2.
Finally, the operation safety property is represented with the class
SafeInteraction
, and safe operations are instances of this
class.
On a similar note, in the case of features, the flag that a feature is
required is not modeled as a property of the feature component, required
features are instead pointed to using the RDF property
requiresFeature
, whereas optional features are pointed to using
the property offersFeature
.
<?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:owl="http://www.w3.org/2002/07/owl#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:wsdl="http://www.w3.org/2005/10/wsdl-rdf#" xmlns:xml="http://www.w3.org/XML/1998/namespace" xml:base="http://www.w3.org/2005/10/wsdl-rdf"> <!-- todo modularize into many more namespaces --> <!-- todo maybe rename properties to verbs and adjectives? --> <owl:Ontology rdf:about=""> </owl:Ontology> <owl:Class rdf:about="#Binding"> </owl:Class> <owl:Class rdf:about="#BindingFault"> </owl:Class> <owl:Class rdf:about="#BindingFaultReference"> </owl:Class> <owl:Class rdf:about="#BindingMessageReference"> </owl:Class> <owl:Class rdf:about="#BindingOperation"> <rdfs:comment>The type of a binding is indicated with rdf:type</rdfs:comment> </owl:Class> <owl:Class rdf:about="#Description"> </owl:Class> <owl:Class rdf:about="#Endpoint"> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#address"/> <owl:maxCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">1</owl:maxCardinality> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:about="#Feature"> </owl:Class> <owl:Class rdf:about="#Interface"> <rdfs:label>WDSL Interface</rdfs:label> </owl:Class> <owl:Class rdf:about="#InterfaceFault"> </owl:Class> <owl:Class rdf:about="#InterfaceFaultReference"> </owl:Class> <owl:Class rdf:about="#InterfaceMessageReference"> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#messageContentModel"/> <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:about="#InputMessage"> <rdfs:comment>To be used by message references and fault references instead of direction property</rdfs:comment> <owl:disjointWith rdf:resource="#OutputMessage"/> </owl:Class> <owl:Class rdf:about="#OutputMessage"> <rdfs:comment>To be used by message references and fault references instead of direction property</rdfs:comment> </owl:Class> <owl:Class rdf:about="#InterfaceOperation"> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#messageExchangePattern"/> <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:about="#PropertyValue"> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#propertyValue"/> <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:about="#Property"> </owl:Class> <owl:Class rdf:about="#Service"> </owl:Class> <owl:Class rdf:about="#MessageExchangePattern"> </owl:Class> <owl:Class rdf:about="#MessageLabel"> </owl:Class> <owl:ObjectProperty rdf:about="#definesMessageLabel"> <rdfs:domain rdf:resource="#MessageExchangePattern"/> <rdfs:range rdf:resource="#MessageLabel"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#address"> <rdfs:domain rdf:resource="#Endpoint"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#binding"> <rdfs:range rdf:resource="#Binding"/> <rdfs:comment>To be used for pointing to a Binding, for example from Description or Endpoint</rdfs:comment> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#bindingFault"> <rdfs:range rdf:resource="#BindingFault"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#bindingOperation"> <rdfs:range rdf:resource="#BindingOperation"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#bindingMessageReference"> <rdfs:range rdf:resource="#BindingMessageReference"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#bindingFaultReference"> <rdfs:range rdf:resource="#BindingFaultReference"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#typeDefinition"> <rdfs:range rdf:resource="#QName"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#elementDeclaration"> <rdfs:range rdf:resource="#QName"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#endpoint"> <rdfs:range rdf:resource="#Endpoint"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#extensionOf"> <rdfs:range rdf:resource="#Interface"/> <rdfs:domain rdf:resource="#Interface"/> </owl:ObjectProperty> <owl:Class rdf:about="#QName"> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#localName"/> <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#namespace"/> <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:DatatypeProperty rdf:about="#localName"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#NCName"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:about="#namespace"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#anyURI"/> </owl:DatatypeProperty> <owl:ObjectProperty rdf:about="#offersFeature"> <rdfs:range rdf:resource="#Feature"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#requiresFeature"> <rdfs:range rdf:resource="#Feature"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#interface"> <rdfs:range rdf:resource="#Interface"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#interfaceFault"> <rdfs:range rdf:resource="#InterfaceFault"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#interfaceFaultReference"> <rdfs:range rdf:resource="#InterfaceFaultReference"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#interfaceMessageReference"> <rdfs:range rdf:resource="#InterfaceMessageReference"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#operationStyle"> <rdfs:domain rdf:resource="#InterfaceOperation"/> <rdfs:range rdf:resource="#OperationStyle"/> <rdfs:comment> points to one style this operation conforms to (can be used multiple times to point to multiple styles) </rdfs:comment> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#interfaceOperation"> <rdfs:range rdf:resource="#InterfaceOperation"/> <rdfs:comment> can be used on interface to link to an operation and on a binding operation to link to the interface operation that is being bound </rdfs:comment> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#messageContentModel"> <rdfs:range rdf:resource="#MessageContentModel"/> </owl:ObjectProperty> <owl:Class rdf:about="#MessageContentModel"> <owl:oneOf rdf:parseType="Collection"> <owl:Thing rdf:about="#AnyContent"/> <owl:Thing rdf:about="#NoContent"/> <owl:Thing rdf:about="#ElementContent"/> <owl:Thing rdf:about="#OtherContent"/> </owl:oneOf> </owl:Class> <owl:ObjectProperty rdf:about="#messageExchangePattern"> <rdfs:range rdf:resource="#MessageExchangePattern"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#messageLabel"> <rdfs:range rdf:resource="#MessageLabel"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#propertyValue"> <rdfs:range rdf:resource="#PropertyValue"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#property"> <rdfs:range rdf:resource="#Property"/> </owl:ObjectProperty> <owl:DatatypeProperty rdf:about="#propertyActualValue"> <rdfs:domain rdf:resource="#PropertyValue"/> <rdfs:range rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"/> </owl:DatatypeProperty> <owl:ObjectProperty rdf:about="#propertyValueType"> <rdfs:domain rdf:resource="#PropertyValue"/> <rdfs:range rdf:resource="#QName"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#service"> <rdfs:range rdf:resource="#Service"/> </owl:ObjectProperty> <owl:DatatypeProperty rdf:about="#documentation"> <rdfs:range rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"/> </owl:DatatypeProperty> <!-- todo - can we combine extensionElement property with extensionAttribute into an "extension" property? Problem is the first is datatype and the second is object property - is that a real problem? --> <owl:DatatypeProperty rdf:about="#extensionElement"> <rdfs:range rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral"/> </owl:DatatypeProperty> <owl:ObjectProperty rdf:about="#extensionAttribute"> <rdfs:range rdf:resource="#ExtensionAttribute"/> </owl:ObjectProperty> <owl:Class rdf:about="#ExtensionAttribute"> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#attributeName"/> <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#value"/> <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> <rdfs:comment> Represents an extension attribute with a name and a value. The value should be a literal. This should only be used for extension attributes that aren't understood by the generator of the RDF model, otherwise the extension should define how the attribute shows in the RDF model. </rdfs:comment> </owl:Class> <owl:ObjectProperty rdf:about="#attributeName"> <rdfs:range rdf:resource="#QName"/> </owl:ObjectProperty> <!-- part 2: message exchange patterns --> <owl:Class rdf:about="#NoFaults"> <rdfs:subClassOf rdf:resource="#MessageExchangePattern" /> <owl:disjointWith rdf:resource="#FaultReplacesMessage"/> <owl:disjointWith rdf:resource="#MessageTriggersFault"/> </owl:Class> <owl:Class rdf:about="#FaultReplacesMessage"> <rdfs:subClassOf rdf:resource="#MessageExchangePattern" /> <owl:disjointWith rdf:resource="#MessageTriggersFault"/> </owl:Class> <owl:Class rdf:about="#MessageTriggersFault"> <rdfs:subClassOf rdf:resource="#MessageExchangePattern" /> </owl:Class> <wsdl:NoFaults rdf:about="http://www.w3.org/2005/08/wsdl/in-only"> <wsdl:definesMessageLabel> <wsdl:MessageLabel rdf:about="http://www.w3.org/2005/08/wsdl/in-only#In"/> </wsdl:definesMessageLabel> </wsdl:NoFaults> <wsdl:NoFaults rdf:about="http://www.w3.org/2005/08/wsdl/out-only"> <wsdl:definesMessageLabel> <wsdl:MessageLabel rdf:about="http://www.w3.org/2005/08/wsdl/out-only#Out"/> </wsdl:definesMessageLabel> </wsdl:NoFaults> <wsdl:MessageTriggersFault rdf:about="http://www.w3.org/2005/08/wsdl/robust-in-only"> <wsdl:definesMessageLabel> <wsdl:MessageLabel rdf:about="http://www.w3.org/2005/08/wsdl/robust-in-only#In"/> </wsdl:definesMessageLabel> </wsdl:MessageTriggersFault> <wsdl:MessageTriggersFault rdf:about="http://www.w3.org/2005/08/wsdl/in-opt-out"> <wsdl:definesMessageLabel> <wsdl:MessageLabel rdf:about="http://www.w3.org/2005/08/wsdl/in-opt-out#In"/> </wsdl:definesMessageLabel> <wsdl:definesMessageLabel> <wsdl:MessageLabel rdf:about="http://www.w3.org/2005/08/wsdl/in-opt-out#Out"/> </wsdl:definesMessageLabel> </wsdl:MessageTriggersFault> <wsdl:MessageTriggersFault rdf:about="http://www.w3.org/2005/08/wsdl/robust-out-only"> <wsdl:definesMessageLabel> <wsdl:MessageLabel rdf:about="http://www.w3.org/2005/08/wsdl/robust-out-only#Out"/> </wsdl:definesMessageLabel> </wsdl:MessageTriggersFault> <wsdl:MessageTriggersFault rdf:about="http://www.w3.org/2005/08/wsdl/out-opt-in"> <wsdl:definesMessageLabel> <wsdl:MessageLabel rdf:about="http://www.w3.org/2005/08/wsdl/out-opt-in#Out"/> </wsdl:definesMessageLabel> <wsdl:definesMessageLabel> <wsdl:MessageLabel rdf:about="http://www.w3.org/2005/08/wsdl/out-opt-in#In"/> </wsdl:definesMessageLabel> </wsdl:MessageTriggersFault> <wsdl:FaultReplacesMessage rdf:about="http://www.w3.org/2005/08/wsdl/in-out"> <wsdl:definesMessageLabel> <wsdl:MessageLabel rdf:about="http://www.w3.org/2005/08/wsdl/in-out#In"/> </wsdl:definesMessageLabel> <wsdl:definesMessageLabel> <wsdl:MessageLabel rdf:about="http://www.w3.org/2005/08/wsdl/in-out#Out"/> </wsdl:definesMessageLabel> </wsdl:FaultReplacesMessage> <wsdl:FaultReplacesMessage rdf:about="http://www.w3.org/2005/08/wsdl/out-in"> <wsdl:definesMessageLabel> <wsdl:MessageLabel rdf:about="http://www.w3.org/2005/08/wsdl/out-in#Out"/> </wsdl:definesMessageLabel> <wsdl:definesMessageLabel> <wsdl:MessageLabel rdf:about="http://www.w3.org/2005/08/wsdl/out-in#In"/> </wsdl:definesMessageLabel> </wsdl:FaultReplacesMessage> <!-- part 2: safety --> <owl:Class rdf:about="http://www.w3.org/2005/08/wsdl-extensions#SafeInteraction"> <rdfs:subClassOf rdf:resource="#InterfaceOperation" /> <rdfs:comment> Class of all operations that are asserted to be safe interactions as defined in Web Architecture at W3C. </rdfs:comment> </owl:Class> <!-- part 2: operation styles --> <wsdl:OperationStyle rdf:about="http://www.w3.org/2005/08/wsdl/style/rpc"> <rdfs:comment>RPC operation style</rdfs:comment> </wsdl:OperationStyle> <owl:DatatypeProperty rdf:about="http://www.w3.org/2005/08/wsdl/rpc#signature"> <rdfs:domain rdf:resource="#InterfaceOperation"/> <rdfs:range rdf:resource="http://www.w3.org/2005/08/wsdl/rpc#signatureType"/> <rdfs:comment>todo - can we use the above URI for the datatype of this property?</rdfs:comment> </owl:DatatypeProperty> <wsdl:OperationStyle rdf:about="http://www.w3.org/2005/08/wsdl/style/iri"> <rdfs:comment>IRI operation style</rdfs:comment> </wsdl:OperationStyle> <wsdl:OperationStyle rdf:about="http://www.w3.org/2005/08/wsdl/style/multipart"> <rdfs:comment>multipart operation style</rdfs:comment> </wsdl:OperationStyle> <!-- part 2: bindings --> <!-- SOAP binding --> <owl:Class rdf:about="http://www.w3.org/2005/08/wsdl/soap"> <rdfs:comment>WSDL 2 SOAP binding</rdfs:comment> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="http://www.w3.org/2005/08/wsdl/soap#version"/> <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="http://www.w3.org/2005/08/wsdl/soap#protocol"/> <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:DatatypeProperty rdf:about="http://www.w3.org/2005/08/wsdl/soap#version"> <rdfs:comment> indicates what version of SOAP is used by the binding, usually "1.2" todo - using string is fairly ugly, but can we invent URIs? </rdfs:comment> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:DatatypeProperty> <owl:ObjectProperty rdf:about="http://www.w3.org/2005/08/wsdl/soap#protocol"> <rdfs:comment> indicates the underlying protocol used by a binding </rdfs:comment> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="http://www.w3.org/2005/08/wsdl/soap#faultCode"> <rdfs:comment> indicates the fault code of a binding fault </rdfs:comment> <rdfs:range rdf:resource="#QName"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="http://www.w3.org/2005/08/wsdl/soap#faultSubcode"> <rdfs:comment> indicates a fault subcode of a binding fault; there can be multiple subcodes </rdfs:comment> <rdfs:range rdf:resource="#QName"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="http://www.w3.org/2005/08/wsdl/soap#soapMEP"> <rdfs:comment> indicates the SOAP MEP this binding operation uses </rdfs:comment> <rdfs:range rdf:resource="#SOAPMessageExchangePattern"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="http://www.w3.org/2005/08/wsdl/soap#defaultSoapMEP"> <rdfs:comment> indicates the default SOAP MEP this binding's operations use </rdfs:comment> <rdfs:range rdf:resource="#SOAPMessageExchangePattern"/> </owl:ObjectProperty> <owl:Class rdf:about="#SOAPMessageExchangePattern"> <rdfs:comment> todo - the URI of this class could be SOAP-1.2-specific, not WSDL2-specific </rdfs:comment> </owl:Class> <wsdl:SOAPMessageExchangePattern rdf:about="http://www.w3.org/2003/05/soap/mep/request-response/"/> <wsdl:SOAPMessageExchangePattern rdf:about="http://www.w3.org/2003/05/soap/mep/soap-response/"/> <owl:ObjectProperty rdf:about="http://www.w3.org/2005/08/wsdl/soap#action"> <rdfs:comment> indicates the SOAP action this binding operation uses </rdfs:comment> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="http://www.w3.org/2005/08/wsdl/soap#offersSOAPModule"> <rdfs:range rdf:resource="http://www.w3.org/2005/08/wsdl/soap#SOAPModule"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="http://www.w3.org/2005/08/wsdl/soap#requiresSOAPModule"> <rdfs:range rdf:resource="http://www.w3.org/2005/08/wsdl/soap#SOAPModule"/> </owl:ObjectProperty> <owl:Class rdf:about="http://www.w3.org/2005/08/wsdl/soap#SOAPModule"> <rdfs:comment> a SOAP module; a WSDL 2 SOAP binding (and subcomponents) may use or require any number of modules </rdfs:comment> </owl:Class> <owl:ObjectProperty rdf:about="http://www.w3.org/2005/08/wsdl/soap#header"> <rdfs:range rdf:resource="http://www.w3.org/2005/08/wsdl/soap#SOAPHeader"/> </owl:ObjectProperty> <owl:Class rdf:about="http://www.w3.org/2005/08/wsdl/soap#SOAPHeader"> <rdfs:comment> a SOAP header </rdfs:comment> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#elementDeclaration"/> <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:about="http://www.w3.org/2005/08/wsdl/soap#MustUnderstandSOAPHeader"> <rdfs:subClassOf rdf:resource="http://www.w3.org/2005/08/wsdl/soap#SOAPHeader" /> <rdfs:comment> a SOAP header that must be marked as mustUnderstand by the sender </rdfs:comment> </owl:Class> <!-- HTTP binding --> <owl:Class rdf:about="http://www.w3.org/2005/08/wsdl/http"> <rdfs:comment>WSDL 2 HTTP binding</rdfs:comment> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="http://www.w3.org/2005/08/wsdl/http#version"/> <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:DatatypeProperty rdf:about="http://www.w3.org/2005/08/wsdl/http#version"> <rdfs:comment> indicates what version of SOAP is used by the binding, usually "1.1" todo - using string is fairly ugly, but can we invent URIs? </rdfs:comment> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:about="http://www.w3.org/2005/08/wsdl/http#location"> <rdfs:comment> defines the location for an operation, relative to the address of the service; this is the only URI-valued property modeled as datatype property because the URI is not meant as pointer to a resource </rdfs:comment> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#anyURI"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:about="http://www.w3.org/2005/08/wsdl/http#defaultMethod"> <rdfs:comment> declares the default HTTP method used by this binding's operations </rdfs:comment> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:about="http://www.w3.org/2005/08/wsdl/http#method"> <rdfs:comment> declares the HTTP method used by this operation </rdfs:comment> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:about="http://www.w3.org/2005/08/wsdl/http#inputSerialization"> <rdfs:comment> declares the media type of the input message of an operation </rdfs:comment> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:about="http://www.w3.org/2005/08/wsdl/http#outputSerialization"> <rdfs:comment> declares the media type of the output message of an operation </rdfs:comment> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:about="http://www.w3.org/2005/08/wsdl/http#faultSerialization"> <rdfs:comment> declares the media type of the fault messages of an operation </rdfs:comment> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:about="http://www.w3.org/2005/08/wsdl/http#defaultQueryParameterSeparator"> <rdfs:comment> declares the default character to be used as query parameter separator by this binding's operations </rdfs:comment> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:about="http://www.w3.org/2005/08/wsdl/http#queryParameterSeparator"> <rdfs:comment> declares the character to be used as query parameter separator by an operation </rdfs:comment> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:DatatypeProperty> <owl:ObjectProperty rdf:about="http://www.w3.org/2005/08/wsdl/http#header"> <rdfs:range rdf:resource="#QName"/> </owl:ObjectProperty> <owl:DatatypeProperty rdf:about="http://www.w3.org/2005/08/wsdl/http#errorCode"> <rdfs:comment> declares the error status code that a fault will return </rdfs:comment> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#int"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:about="http://www.w3.org/2005/08/wsdl/http#errorReason"> <rdfs:comment> declares the error reason phrase that a fault will return </rdfs:comment> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:about="http://www.w3.org/2005/08/wsdl/http#defaultTransferCoding"> <rdfs:comment> declares the default transfer coding to be used by this binding's operation messages </rdfs:comment> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:about="http://www.w3.org/2005/08/wsdl/http#transferCoding"> <rdfs:comment> declares the transfer coding to be used by operation messages </rdfs:comment> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:DatatypeProperty> <owl:Class rdf:about="http://www.w3.org/2005/08/wsdl/http#HTTPBindingWithCookies"> <rdfs:comment>WSDL 2 HTTP binding with cookies</rdfs:comment> <rdfs:subClassOf rdf:resource="http://www.w3.org/2005/08/wsdl/http"/> </owl:Class> <owl:DatatypeProperty rdf:about="http://www.w3.org/2005/08/wsdl/http#authenticationType"> <rdfs:comment> declares the authentication type used by an endpoint, by default "none" </rdfs:comment> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:about="http://www.w3.org/2005/08/wsdl/http#authenticationRealm"> <rdfs:comment> declares the authentication realm used by an endpoint </rdfs:comment> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:DatatypeProperty> <!-- todo binding defaults are necessary for interfaceless bindings, but they aren't currently in the component model - they are modeled here tho, in anticipation that my LC comment gets accepted --> </rdf:RDF>
todo: mapping there, not really back, certainly not roundtrip
todo, plus references