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