Martin,
I appreciate the detailed and concrete response. While at some level I
agree with you, I feel that we may be approaching a religious
debate. Certainly, with a lisp reader one could have the same sort of
hierarchical data structure and lisp readers would tokenize the keywords to
save space, so that's not unique to XML. But at that point, we're talking
about internal data structures, and not the interchange language. XML has
virtues because of it's current popular acceptance, but there are still
many issues that would need to be resolved.
Your element type approach does yield a more compact structure, but it
appears that you have lost the full expressivity of KIF in doing so. For
example, KIF allows a variable, terms, or function as an argument and your
proposal for the form (01)
<instance id="variable-X">
<type>Horse</type>
</instance> (02)
seems to assume that neither argument is a function application.
I'm playing devil's advocate a bit here, but what's the compelling
benefit of this syntax change, even if you create an XML encoding
sufficient to handle the full expressivity of KIF? The interchange
language becomes more verbose, and any tools that handle generic XML would
need to be specialized to handle not only the syntax of XML, but the
particular features of the encoding, and the semantics of KIF. So you've
just added another layer of software structure. (03)
Adam (04)
At 08:55 AM 11/21/2002 +0000, Martin Bryan wrote:
>Adam
>
> > 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.
>
>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:
>
> > > > <kif>
> > > > (=>
> > > > (instance ?X Horse)
> > > > (exists (?Y)
> > > > (and
> > > > (instance ?Y Head-PartOfBody)
> > > > (part ?X ?Y))))
> > > > </kif>
>
>to
>
> > > > > > ><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>
>
>My version of the KIF statement would be much simpler as it would be based
>on types of elements, rather than their primitive constructss:
>
><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>
>
>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:
>
><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>
>
>This is the length you need to compare with the KIF statement length.
>
>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!).
>
>Martin Bryan
>The SGML Centre, 29 Oldbury Orchard, Churchdown, Glos GL3 2PU, UK
>Phone/Fax: +44 1452 714029 E-mail: mtbryan@xxxxxxxxxxxxxx
>
>For further details about The SGML Centre visit http://www.sgml.u-net.com
>
>
>
>--
>To post messages mailto:ontolog@xxxxxxxxxxxxxxx
>An archive of the [ontolog] forum can be found
>at http://ontolog.cim3.org/forums/ontolog (05)
--
To post messages mailto:ontolog@xxxxxxxxxxxxxxx
An archive of the [ontolog] forum can be found
at http://ontolog.cim3.org/forums/ontolog (06)
|