[om] Newbie questions on the meaning of the Attribution Element

[Richard Fateman]

Cem Karan wrote:
> If all of this true,
   ... if you are trusting my statements, beware that I am not
   ... representing OM officaldom.  In fact, I expect that OM
   ... advocates do not welcome my point of view... RJF

> then OpenMath quickly becomes meaningless; the goal 
> (at least as I understand it) of OM is to guarantee the ability to 
> communicate between two (or more) programs or components. 

OM doesn't make any guarantees, that I know of.

> My program 
> does not, and probably never will understand how to talk to Maple using 
> Maple's native encodings (or anything else for that matter; if it uses 
> OM, then it will use the CDs in as pure a manner as possible).

The notion that one can communicate higher mathematics by some
kind of appeal to comments like "cos means the cosine function"
is hardly supportable, in my opinion.  On the other hand, reducing
cosine to an encoding based on naive set theory is pretty painful
too.  The best way I know of is to refer to it as "cos means
the same as cos in maple.".  That, of course, would be unacceptable
to the un-maple crowd. ... RJF



>  I know 
> that OM does not guarantee that the attribute elements are going to 
> correspond to OM elements that are in the CDs, and I know that I can't 
> force other users to do so correctly.  Would it be worth making a 
> version of OM where the attribute element is deprecated? 

This sounds like a terrible idea.  I would deprecate the non-attribute
part if you want to guarantee anything. That seems to be what all the
front-end/back-end applications do.

> Much of what 
> it seems to supply can probably be supplied via other namespaces;

Java serialization, Lisp's/ read and print programs, OLE, character 
strings, for a few.

> this 
> includes binary information, which can be base64 encoded.  The advantage 
> to removing the attribute element from the OM namepace is that any 
> application that claims to use OM as its communication medium wouldn't 
> be able to limit itself to using attribute elements only, it would have 
> to use information that other parsers could also use.

Eh, so you would force everyone to interpret in his/her own way
what is meant by OM?  You are still not guaranteed that you
have the same meaning in two different programs.  In fact it
would be hard to say that two different programs ever have the same
meaning unless they are two copies of the same program.  Even
the number 2  means different things to Maple and Matlab.
Try to compute 2^5000 in Maple and in Matlab.

You can cover over this problem of communicating between A and B
by writing phrasebooks that in effect tell A what B means by OM 
utterance x and tell B what A means by OM utterance y.
Getting them to agree on what some as yet unknown or even
unwritten program C means by utterance z is problematic.  Unless
you have some trivial explanation "OM means OM"  or alternatively,
programs A and B are identical and will (mis)interpret z in
the same way.

RJF



> 
> Thanks,
> Cem Karan
> 
> On Sunday, January 12, 2003, at 05:14  PM, Richard Fateman wrote:
> 
>> I would go even further and say that any application
>> is compelled to ignore the entire attribution unless
>> the OMObject is coming from a trusted source )or whose
>> attributions are certified in some way).
>>
>> It is conceivable for a front-end to a computer algebra
>> system and a back-end to communicate with OMObjects,
>> in which case it is very likely that the attribution
>> will be the ONLY thing used  (e.g. for Maple, it could
>> be Maple encodings).  That is, the rest
>> of the OM is treated as noise, since it cannot convey anything
>> MORE informative than the Maple command.
>>
>> In almost any other circumstance the attribution must
>> be treated as noise.  Just because someone includes a
>> Maple expression string in the attribution doesn't mean
>> it is accurate; and if it is not Maple that is
>> receiving the object, what sense will be made of it? One
>> can only make sense of it if one has a "fake Maple"
>> parser and knowledge base.
>>
>> In fact this illustrates the fundamental flaw in OM.  In
>> almost any application you might as well be communicating
>> in some side-channel if you want to make sure something
>> is understood exactly and completely.  The alternative
>> of building up a CD etc etc is too painful.  Demonstrations
>> that this encoding might be useful for typesetting
>> (like presentation MathML) is not a proof of concept.
>> It is a proof that OM can be used for typesetting.
> 
> 
> -- 
> om at openmath.org  -  general discussion on OpenMath
> Post public announcements to om-announce at openmath.org
> Automatic list maintenance software at majordomo at openmath.org
> Mail om-owner at openmath.org for assistance with any problems


--
om at openmath.org  -  general discussion on OpenMath
Post public announcements to om-announce at openmath.org
Automatic list maintenance software at majordomo at openmath.org
Mail om-owner at openmath.org for assistance with any problems