[
Lists Home |
Date Index |
Thread Index
]
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
|
