|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: equivalentTo vs. XSLT
Miles Sabin wrote: >... >>Yes, if you don't care about reliability, performance, security or >>using specs as they were designed to be used, then XSLT can be used to >>handle some carefully chosen subset of OWL's use-cases. > > Carefully chosen? I thought _you_ chose the use-case as a demonstration > of how SW technologies solve real practical problems better than the > alternatives. Oh well ... Sure, and any other particular problem that OWL is designed to solve could also be solved with some Turing-complete language. That's the beauty of Turing-complete languages. But we could also argue that anything that can be done in XML can be done with Java objects, no matter how inconvenient, insecure or unreliable that would make the resulting system. XSLT is not a viable alternative to OWL for granular remapping and wasn't designed to be. > And I'm mildly astonished that you think that XSLT and it's > implementations are so poor, and that transformations aren't what it > was designed to express! XSLT implementations are excellent at what they are designed for, which is *document-to-document* transformations. XSLT was NOT designed for mapping an element _forund in some arbitrary context_ to some other element. >... > None ... I'm quite well aware of the fact that DLs are decidable. I > simply question the value of something that's so expressively > impoverished for general vocabulary to vocabulary mapping. > > For example, consider a mapping from, > > <foo> > <dimensions> > <height>2</height> > <width>4</width> > <depth>10</depth> > </dimensions> > </foo> > > to, > > <bar> > <volume>80</volume> > </bar> > > (ie. volume = height*width*depth) > > Surely not a completely bizarre type of transformation to want in many > domains, and implementable in any number of ways. But it's not > expressible in OWL/DL. No, it isn't expressible in OWL 1.0. But it also doesn't require Turing-completeness so OWL 2.0 will probably handle it. It is a stated objective! "In addition to the set of features that should be in the language (as defined in the previous section), there are other features that would be useful for many use cases. These features will be addressed by the working group if possible, but the group may decide that there are good reasons for excluding them from the language or for leaving them to be implemented by a later working group. ... O10. Arithmetic primitives The language should support the use of arithmetic functions. These can be used in translating between different units of measure. Motivation: Ontology interoperability" > Expressive power, decidability: pick one. No, I don't have to pick one. I can have both by using a collection of tools with each doing what it is best at. I can do what can be done in the decidable language and then layer a Turing-complete language on top (or embed it inline) for the more tricky stuff. Then the computer understands what it can and the rest is done in comparitively opaque code. IMHO, that's a better strategy than going entirely one way or entirely the other way. The best tool for the job: XSLT wasn't designed for layered renaming of elements in a granular way. I've tried alternatives that WERE designed to do that at the syntactic level and I find OWL to be more flexible and expressive without giving up decidability. Paul Prescod
|
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
|
|||||||||

Cart








