RE: Review of WSDL 2.0 - RDF Mapping

Hi Jacek,

So if I'm understanding correctly, you do intend to provide an XSLT
version of the WSDL 2.0 --> RDF mapping, but you want the English prose
to be based on the WSDL 2.0 component model, right?

In that case, I would suggest making the XSLT version be the normative
definition of the WSDL 2.0 --> RDF mapping, and have the English prose
act as ancillary explanation.  That way I would see no problem with the
English prose being based on the component model.  And defining the
mapping in terms of XSLT would give much greater precision than English
prose, because it is a formal, machine-processable language.  

I think this would be a more direct and useful approach, because it
would not require users to come up with their own interpretations of the
English prose.  Is there some reason why you think such an approach
would not work or not be feasible?

David Booth


> -----Original Message-----
> From: Jacek Kopecky [mailto:jacek.kopecky@deri.org] 
> Sent: Wednesday, January 11, 2006 9:16 AM
> To: Booth, David (HP Software - Boston)
> Cc: Bijan Parsia; WS-Description WG
> Subject: RE: Review of WSDL 2.0 - RDF Mapping
> 
> 
> Hi David, Bijan,
> 
> in the English prose specifying the mapping, I prefer 
> strongly to come from the component model, because the 
> component model is not a simple 1:1 lifting of the infoset, 
> it contains rules like defaulting that make multiple WSDL 
> documents equivalent even if they aren't the same. Basing the 
> RDF mapping spec on the component model gives us 
> automatically all these things, whereas if we were based on 
> the infoset (or even XML bytes, would you say?), we'd have to 
> reiterate in some form at least the defaulting rules from the 
> WSDL 2 spec.
> 
> In fact, if somebody creates an API for accessing and 
> manipulating WSDL 2 documents, I expect it should follow the 
> component model, too. So while I also see specs as software 
> boundaries, I actually see the component model as a software 
> API. This API would provide to the applications the 
> defaulting functionality (and the rest of what the component 
> model specifies) - the defaulting rules should not be 
> implemented in every WSDL-aware application, don't you agree? 8-)
> 
> As I said, an XSLT (most probably) will be produced as an 
> implementation of the mapping, and this XSLT will naturally 
> work from the XML form of WSDL. But I expect the things like 
> defaulting to be implemented in the XSLT or in rules within 
> the ontology (if we have the technology by then), and not in 
> the consumer of the RDF form.
> 
> Hope this clarifies my thinking,
> 
> Jacek
> 
> 
> 
> On Mon, 2006-01-09 at 15:28 -0500, Booth, David (HP Software - Boston)
> wrote:
> > Comments below.
> > 
> > > From: Bijan Parsia [mailto:bparsia@isr.umd.edu]
> > > 
> > > On Jan 3, 2006, at 6:18 PM, Booth, David (HP Software - Boston) 
> > > wrote:
> > 
> > > > [snip]
> > > >> We intend to have the mapping from the component model to RDF, 
> > > >> not
> > > >> directly from the XML.
> > > >
> > > > Oh.  How would that work?   Given a WSDL 2.0 document, what 
> > > > would I do to produce the corresponding RDF?
> > > >
> > > > It sounds like you are saying that there would be two
> > > > mappings, A and B, and you will be doing mapping B:
> > > >
> > > >                     A                               B
> > > > WSDL 2.0 document -----> WSDL 2.0 component model -----> RDF
> > > >
> > > > Is that what you mean?
> > > [snip]
> > > 
> > > Yes. So you have to look at the main specs to figure out how
> > > to get the component model from the xml, then the mapping to 
> > > get the rdf for that component model.
> > > 
> > > (Obviously, in code, you could do it directly once you've 
> figured it
> > > out.)
> > 
> > Although I think this makes obvious sense as an internal 
> strategy, I'm 
> > a little uneasy with the idea that you would only be specifying 
> > mapping B in the published mapping document.
> > 
> > Basically, I think of specs as corresponding to software 
> boundaries, 
> > and I think of the WSDL 2.0 component model as being a 
> mechanism that 
> > is internal to the WSDL 2.0 spec, as a convenient aid in specifying 
> > the WSDL 2.0 language, rather than something that is intended for 
> > external use.  Thus, defining only mapping B feels kind of like 
> > accessing directly into the middle of a piece of software 
> instead of 
> > using its published interface.
> > 
> > More pragmatically, since the WSDL 2.0 --> RDF mapping is from one 
> > machine-processable language to another, I was assuming 
> (hoping?) that 
> > the mapping itself would be also defined in a machine-processable 
> > language (such as XSLT for example).  Doing so would both 
> allow others 
> > to use it directly (instead of having to implement their 
> own mapping 
> > software), and it would eliminate ambiguity that often 
> appears in an 
> > English prose specification of the mapping (though of course there 
> > could still be ambiguity in the meaning of the resulting RDF).
> > 
> > In short, I think it will be substantially more valuable if 
> you define 
> > the WSDL 2.0 --> RDF mapping in a machine-processable language.
> > 
> > David Booth
> > 
> > 
> 
>

Received on Thursday, 12 January 2006 20:28:52 UTC