[
Lists Home |
Date Index |
Thread Index
]
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@milessabin.com>
To: <xml-dev@lists.xml.org>
Sent: Monday, November 11, 2002 4:41 AM
Subject: Re: [xml-dev] 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@cogx.com phone: (917) 406-8734
web: http://www.cogx.com Cogito Ergo XML
|
