[SCL] telecon elaborations
Tanel Tammet
tammet at staff.ttu.ee
Tue May 27 22:50:37 CDT 2003
Hi,
andersen at ontologyworks.com wrote:
>
> What may happen in a negative scenario, though, is that from
> SCL concrete syntax 1 predicate P is converted to Pred(P...
> while from SCL concrete syntax 2 P is converted to Holds(P...
> while from RDF/RDF it is converted to Triple(...,P,...)
> while from a concrete traditional FOL syntax it is converted to just P.
>
> ---
>
> First, would not Pred(P..., Holds(P..., and Triple(...,P,...) be the forms
> converted FROM not TO?
No. In the scenario the concrete syntaxes probably do not contain
Pred, Holds, Triple. They are likely to contain P(...) or <P> or (P ...)
The scenario is intended to be a trivial example of what may easily
go wrong or cause problems unless we take care in SCL documents.
There is nothing clever about the scenario. Quite contrary: I am
trying to stress the importance of seemingly trivial issues.
> Second, if P is taken to be the same relation across your theories 1-3, and
> predication works like we think it does, then why would one obtain 3
> translations? Using Pred_n and App_n, one should only get one translation.
That is the trivial point in the example: the CONVERTER WRITERS
may just happen to write DIFFERENT CONVERTERS unless they are clearly
instructed about the suitable ways of converting. It is not at all
obvious they do manage (for various reasons) to get only one
translation. One translation is certainly what we want to get, though.
It is a non-obvious question: how to convert SCL syntaxes, RDFS and
traditional FOL in a compatible manner. Pred_n and App_n would
be a possibility, but then it should be stated as THE possibility.
In other words: the ABSTRACT syntax and semantics itself does not
seem to guarantee a suitable translation from all the different
languages. Clear translation rules from SCL syntaxes, RDFS, traditional
FOL to FOL are needed.
> Third, even if one were to obtain different translated forms, as you
> describe above, somewhere would have to be relevant axioms, like:
>
> (P,x,y)P(x,y)<->Triple(x,P,y)
The axioms are problematic: incompatible signatures
are used. What if Triple is already used in one input file for
different purposes?
There are other potential problems as well, like different
meanings of the quantifiers (range over predicates (which
predicates?) or not).
Even if no problems like these occur, axioms like this are
still unpleasant, since their usage penalties speed and clarity.
> For if not, then the translations would make no sense.
Exactly: except that they WOULD make sense in the context
of a single concrete syntax. Each translation itself may
make perfect sense (unless obvious errors are made), yet
they might be trivially incompatible.
Regards,
Tanel
More information about the Scl
mailing list