Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: equivalentTo vs. XSLT
 Miles Sabin wrote: > I don't think anyone would say that using XSLT transforms to map between > vocabularies is in any interesting sense a SW technology. And yet it > seems to be enough to cover one of the primary use-cases for OWL. Which > takes us back to Mikes earlier question, OWL engine can be implemented in any language. As I understand it correctly, all you are saying is that OWL can at least partially be implemented in XSLT. And it can be implemented in Python, Java, VB, C++, Ruby... I do not see why somebody would disagree. However, an XSLT script that implements a particular OWL would be much less readable then OWL ontology itself. OWL, just as XML Topic Maps can be learned (by a human), explained and interchanged. And that is their main value (as I see it). Internally I can keep ontology as I wish (for example, in RDBMS). But I think that you will value my ontology (if at all :-)) only in one of the agreed upon interchange syntaxes. --Nikita. ----- Original Message ----- From: "Miles Sabin" <miles@m...> To: <xml-dev@l...> Sent: Monday, November 11, 2002 4:41 AM Subject: Re: equivalentTo vs. XSLT > Paul Prescod wrote, > > Miles Sabin wrote: > > > Maybe I should have said transformation rather than mapping. > > > > > > I'll try again: once you've defined an executable transformation > > > (eg. using XSLT), what useful job is there left for RDF/DAML/OWL to > > > do? > > > > Probably none. But I wouldn't define an executable transformation in > > an XSLT program when I could define a declarative mapping in a single > > line of OWL. > > To a certain extent this is missing the point. > > I don't think anyone would say that using XSLT transforms to map between > vocabularies is in any interesting sense a SW technology. And yet it > seems to be enough to cover one of the primary use-cases for OWL. Which > takes us back to Mikes earlier question, > > I know the questions are being asked, but are the answers helping > people to do real work more productively than they could without SW > technologies? > > and suggests that in this case at least, the answer is "No". > > > First, the XSLT is Turing complete. That means that if you send an > > agent onto the Web to find an XSLT that translates ebXML into > > BizTalk, you have no idea what computational resources you are > > committing to run the transformation it finds. You can't even kill > > the process with confidence when it runs in an "unreasonable amount > > of time" because perhaps it was just one second away from completing > > the task. So you set some arbitrary runtime limit and take your > > chances. > > True ... but is it all that surprising? Is it really very different from > hitting a browsers stop button when a web site seems sluggish? If you'd > hung on for another couple of seconds you might have got a response. > Isn't this just the way that the web works? > > > I *believe* that the computational properties of semantic > > web reasoners are more predictable. But I am not a computational > > logician so I could be wrong on that. > > I don't believe that any logic that's likely to be interesting in this > kind of context is decidable. Let's face it, your semantic web reasoner > is going to have to do the same job as the transform, so how could it > be guaranteed to terminate in finite time if the transform can't be? > > > Also, there are issues around security and analysis of > > Turing-complete programs versus declarative specifciations. And > > serious optimization issues! So overall, I see the OWL route as being > > more reliable, secure and performant. > > XSLT can be compiled to Java (amongst other things), and you can prove > the security properties of Java programs ... that's what the bytecode > verifier does. As things stand that doesn't address resource > consumption issues, but you can expect some developments on that front > in the not too distant future. Obviously all this is modulo > implementation issues ... but I don't see why OWL-consuming reasoners > should be any less prone to reliability, security and performance > issues than any other piece of software. > > > Second, the XSLT specification has weak support for handing off from > > one XSLT to another on a very granular (per-element) basis. Consider: > > Granted ... but I only said: eg. XSLT. > > > Third, I've never heard of anybody composing XSLTs that were > > developed entirely independently except by building a pipeline where > > the document is processed by one and handed off to another. > > Sure, but I don't think there's anything which in principle prevents a > sequence of XSLT transforms from being composed into a single > transform. > > And again, I only said: eg. XSLT. It might well be that XSLT is too hard > to compose effectively, in which case we need to find a better model. > These things are only automata, after all ... and composing automata > isn't exactly virgin territory. > > > Fourth, it is much easier to use OWL as it was intended to be used > > than to chain-gang XSLT into the job. XSLT is not even designed to be > > a "general-purpose transformation language" much less a semantic > > mapping language. > > Perhaps ... but the point I'm trying to make is that we don't > necessarily need a "semantic mapping language" in the SW sense. My > guess is that in many, perhaps most, cases all we need are dumb syntax > to syntax transforms. > > Cheers, > > > Miles > > Nikita Ogievetsky, Consultant. Cogitech Inc. email: nogievet@c... phone: (917) 406-8734 web: http://www.cogx.com Cogito Ergo XML 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
