Adam (01)
> While that might be true in general, could you describe how an axiom in
> first order logic could be translated into another formalism using
> XSL? Translating SUMO for use in the SNARK theorem prover required
> renaming predicates in the ontology itself, quoting certain kinds of
> statements, and treating certain kinds of variables as macro statements
> that require expansion. Translating SUMO for use in Protege would require
> first detecting and then throwing away axioms such as the one below. At
> that level of complexity I wonder what the advantage is of using a
> scripting language like XSL over a full-blown programming language with
> good string-processing support like Perl or Java? And why the penalty of
a
> far more verbose encoding is worth the trouble.
> The point I'm converging on here is that it's all well and good to say
> an XML encoding is a Good Thing, but we should be clear on why, and in
> which use cases. (02)
Not "XML encoding is a Good Thing", but "interchangeable processability is a
Great Thing". You quote Perl and Java as alternatives to XSLT. XSLT includes
Perl's pattern matching functionality and adds the ability to select nested
structures for processing. Java as an alternative is, because of its
portability, just as useful as XSLT, if you prefer to use procedural
languages rather than declarative ones. (I'm biased to declarative
languages!) Now to counter the "error" relating to file sizes. XML is not
more verbose that other languages once you tokenize it using any of the
standard compression languages. Lets take your example. You chose to
convert: (03)
> > > <kif>
> > > (=>
> > > (instance ?X Horse)
> > > (exists (?Y)
> > > (and
> > > (instance ?Y Head-PartOfBody)
> > > (part ?X ?Y))))
> > > </kif> (04)
to (05)
> > > > > ><implies>
> > > > > > <antecedent>
> > > > > > <clause>
> > > > > > <predicate value="instance">
> > > > > > <argument number=1 value="?X">
> > > > > > <argument number=2 value="Horse">
> > > > > > </clause>
> > > > > > </antecedent>
> > > > > > <consequent>
> > > > > > <existential>
> > > > > > <varlist><var name="?Y"></varlist>
> > > > > > <and>
> > > > > > <clause>
> > > > > > <predicate value="instance">
> > > > > > <argument number=1 value="?Y">
> > > > > > <argument number=2 value="Head-PartOfBody">
> > > > > > </clause>
> > > > > > <clause>
> > > > > > <predicate value="part">
> > > > > > <argument number=1 value="?x">
> > > > > > <argument number=2 value="?Y">
> > > > > > </clause>
> > > > > > </and>
> > > > > > </existential>
> > > > > > </consequent>
> > > > > > </implies> (06)
My version of the KIF statement would be much simpler as it would be based
on types of elements, rather than their primitive constructss: (07)
<imply>
<instance id="variable-X">
<type>Horse</type>
</instance>
<exists>
<variable id="variable-Y"/>
<and>
<instance id="variable-Y">
<type domain="PartOfBody">Head</type>
</instance>
<ispart container="variable-X" contains="variable-Y"/>
</and>
</exists>
</imply> (08)
Now this is still longer than the basic KIF statement, but it does allow me
to control processing based on types of statement (e.g the exists statement)
by parsing the tree of name-distinguished elements rather than a set of
brackets. If I replace each element name and attribute with a token
(represented below by t and an number) on compression I end up with some 13
tokens, some symbols and three variables, viz: (09)
<t1>
<t2 t3="t4">
<t5>Horse</t5>
</t2>
<t6>
<t7 t3="t8"/>
<t9>
<t2 t3="t8">
<t5 t10="PartOfBody">Head</t5>
</t2>
<t11 t12="t4" t13="t8"/>
</t9>
</t6>
</t1> (010)
This is the length you need to compare with the KIF statement length. (011)
Now to come back to your real challenge, how to convert one type of FOL
axiom to another. This I admit is the difficult part. Renaming is one
problem, but restructuring is the one that is the killer. Here is where
having a tree to process, as you do with XML, is much easier to handle than
having a stream to process, as you need with Perl and Java. You can write
rules that say "If I find an A with a parent of type B then I do this
transformation" rather than having to say "If I find a B look to see if
there is an A before the Z that identifies the end of B", which is
effectively what you have to do with string processing. This ability to
decide what to do based on the children's structure/content rather than on
the parent's content is one of the keys of success to XSLT (and one of the
reasons why people find XSLT as hard as LISP to come to terms with!). (012)
Martin Bryan
The SGML Centre, 29 Oldbury Orchard, Churchdown, Glos GL3 2PU, UK
Phone/Fax: +44 1452 714029 E-mail: mtbryan@xxxxxxxxxxxxxx (013)
For further details about The SGML Centre visit http://www.sgml.u-net.com (014)
--
To post messages mailto:ontolog@xxxxxxxxxxxxxxx
An archive of the [ontolog] forum can be found
at http://ontolog.cim3.org/forums/ontolog (015)
|