[Prev][Next][Index][Thread]
Re: semantics

To: w3cmatherb <w3cmatherb@w3.org>

Subject: Re: semantics

From: Ron Whitney <RFW@MATH.AMS.ORG>

Date: Fri, 23 Aug 1996 12:45:58 0400 (EDT)

From w3cmatherbrequest@www10.w3.org Fri Aug 23 15: 57:58 1996

Inreplyto: <321C49CF.4D82@wolfram.com>

Mailsystemversion: <MultiNetMM(369)+TOPSLIB(158)+PMDF(5.0)@MATH.AMS.ORG>

Messageid: <840818758.446715.RFW@MATH.AMS.ORG>
This note is in reponse to the recent postings of Neil, Bob, and Steve.
There is considerable ambiguity in our notions of 'semantics', even as
the term is being used in our conversations. When AMS was invited to
join this ERB, the goals of HTMLMath had been considerably extended
over those of the older (1995), PlainTeXlike approach. One can
describe the goals functionally in terms of targets for transformation
to and from HTMLMath, but I think it's also commonly agreed that the
foundations for these superior transformational capabilities are
'semantical'. If TeX and other currentday notational systems are
viewed as 'defective', I think the view of those defects is that they
are ambiguities of expression which block mapping to other uses. When
one uses the term 'ambiguity', I take it to mean that two disparate
'uses' appear as one. This is a simple *semantical* distinction. In
this way, I think it is legitimate to say that the goals of HTMLMath
have raised considerations about semantics in mathematical notation.
We are not trying to ferret out whether to include semantics, but
rather how and to what extent. We're speaking of semantics, not
Semantics.
I think everyone on this list realizes that the full problem of
semantics is very difficult, and I don't know of anyone who has said
that he or she would go to the ends of the earth to incorporate some
huge formal specification. Speaking loosely (and guessing), my view of
the spectrum of values attached to semantical attachments is
less value more value higher value

AMS Wolfram OpenMath
Elsevier MINSE
This says nothing about what 'less', 'more', and 'higher' come to.
It also does *not* say that people in the groups mentioned lack
understanding of the views of others. Neil and Steve from Wolfram
have gone to some length to argue against some forms of semantics
which I think no one on this list has pushed. Ping has indicated a
strong interest in driving the various renderings from a disambiguated
notation. I discussed what full semantics might mean, not to suggest
doing it, but only to give it legitimacy. Bob has lobbied for the
mere capability of including independently determined semantics within
the HTMLMath notation. Bob's argument is for a tangent (or
orthogonal  the image is one of rooted intersection at a single
point) semantics, not that our ERB has to define the semantics.
With this in mind, I'd like to return to the matter of the goals of
HTMLMath and how best to achieve them. The goals involve devising a
notation (or a class of notations) each of which can be used for a
variety of renderings (visual, audio, CAS, ...). The exactness
with which these targets can be hit is very much under discussion.
Standard TeX (and ISO 12083 and other forms of) visual markup allows
at least two forms of ambiguity: (a) operator overload, and (b)
unspecified expression structure. The Wolfram and MINSE approaches
require that authors be much more careful about avoiding (b). MINSE
asks that authors introduce new vocabulary to solve (a). The Wolfram
proposal allows for 'macros' which disambiguate (much like the MINSE
solution) and 'templatematching' which allows for late semantical
binding and contextsensitive maps.
Bob has indicated a desire to allow type and contextinformation to
be associated with notational objects. MINSE allows this underneath
the surfacelevel notation (along with display and other rendering
characteristics). The WP allows it, I believe, in the macro and
templatematching specifications. I asked in a previous posting
whether such information might be specified "on the fly" within the
notation itself (perhaps no one sees a need to do so.  If an
object's name is unambiguous, type characteristics can be handled
externally; otherwise the object will fit (WP assumes) a template
which points to it uniquely and the type characteristics can be
associated with that template.).
To focus then:
1. Do we have objections to allowing for specification of externally
defined information within our notational system? This could be
semantics or other values associated with the 'objects' of our
standard.
2. Must that specification (if permissible) lie beyond the
surfacelevel mathematical notation we allow or can it be embedded
directly within the mathematical notation?
Ron
References: