Re: Review of WSDL 2.0 - RDF Mapping

Hi David, 

below are my comments on your comments by section, currently all
together tracked as issue 284 [1]. I have updated the editors' draft [2]
in some places to address your comments; as detailed below.

[1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x284
[2] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-rdf.html?content-type=text/html;%20charset=utf-8

On Thu, 2005-12-22 at 15:46 -0500, Booth, David (HP Software - Boston)
wrote:
> COMMENTS BY SECTION
> Section 1. Introduction: 
> Good motivation.  If the creation of WSDL2.0-->RDF mapping helped to
> expose unnoticed issues in the WSDL 2.0 definition, that would be good
> to mention also.

Sorry, while it could be nice, it doesn't really fit in the content...

> Section 2.2 Handling Features, Properties and Generic Extensions: 
> Good overview of WSDL 2.0 extensibility.

Thanks. 8-)

> Section 3. Differences from the WSDL Component Model:
> I found myself getting confused about whether a paragraph was discussing
> the RDF that results from mapping a legal WSDL document, versus
> arbitrary RDF that might be written using the ontology and thus may not
> correspond to any legal WSDL document.  The document as a whole is about
> the mapping from legal WSDL documents, and thus as a reader I kept
> expecting to be reading about the RDF that results from mapping a legal
> WSDL document. 

I introduced explicit distinction between RDF graphs resulting from
mapping valid WSDL documents, and arbitrary RDF graphs that follow our
ontology, and mentioned that sec 3 is only about the former.

> Section 3.1 Component naming:
> Re: "The original names and namespaces are not explicitly modeled in the
> RDF representation"
> I found myself wondering which namespace this section was discussing,
> but I think it is referring to the wsdl:targetNamespace.  It would be
> good to clarify.

I switched name and namespace in the sentence, should now be clear that
both are "of the component".

> I notice that in section 3.1 the ontology runs into the issue of the
> dependency between the meaning of a hash URI and the mime type of the
> content that is returned from that URI, and thus the need to dereference
> the URI to determine the mime type.  This is exactly the kind of problem
> I describe in my discussion of how URIs/IRIs should be minted:
> http://lists.w3.org/Archives/Public/public-swbp-wg/2005Dec/0056.html

This may be raised as an issue against the component designators section
in part 1, but we are assuming in WSDL that the namespace URI will in
fact point to the WSDL file, therefore the "hash-URI" problem may not be
a problem for us.

> Section 3.2 Documents, imports and includes:
> I don't understand this sentence: "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.".
> Is it referring to your ontology in general or to your mapping?  I
> thought a wsdl:interface MUST belong to a wsdl:description, so I would
> think that in any RDF resulting from applying the mapping that you
> describe, each interface *would* belong to a Description and each
> interface operation *would* belong to an interface.  In retrospect, it
> looks like that sentence is referring to the ontology in general.  This
> is an example of the confusion I mentioned under section 3.1 above.

Rewritten, offending text judged unnecessary, removed, partly added as
example in sec. 3. 8-)

> I don't understand the implications of section 3.2.

Is it better now, after the rewrite?

> Appendix A: the owl ontology source:
> I notice that a lot of properties have rdfs:range defined, but not
> rdfs:domain.  I assume this is because these properties could be applied
> to more than one class.  Would it make sense to create some superclasses
> for these, so that the rdfs:domains can be specified?

Yes, some of the properties can be applied to multiple classes. I choose
not to introduce superclasses for such things. For example, the
"binding" property points to a Binding both from its parent Description
and from and endpoint that uses the Binding. I don't think there is a
useful superclass for Description and Endpoint for the purpose of being
able to point to a Binding.

However, this may change if we adopt the part-whole ontology by
eliminating the "binding" property of Description and instead using
"is_part_of_directly".

Hope it helps,

Jacek

Received on Thursday, 2 February 2006 13:41:03 UTC