[Om3] FM re three avenues for the condition elements

[Professor James Davenport]

On Wed, November 5, 2008 11:44 pm, David Carlisle wrote:
> Chris
>> What would be its 'content model' and would it necessitate saying
>> something about Boolean values in Basic OpenMath (which may be useful
>> anyway)?
>
> I think the content of OMC, if it were added, would be any openmath
> object wouldn't it? nowhere in OM do we restrict the kinds of object
True. STS does restrict types, but doesn't define what a type is in any
formal sense (deliberately).
> that can appear in any construct with the one exception attribution keys
> and bound variables which must be (possibly attributed) OMS rather than
> arbitrary objects.
OMV for bound variables surely.
In particular, the 'head' of OMBIND is not so restricted, which allows
constrcuts like the proposed forallrestricted.
>> and would it necessitate saying something about Boolean values in
>> Basic OpenMath
>
> I don't think so, if a condition can't be interpreted as a boolean
> it might cause problems for a system interpretting the OM, but I don't
> think that should be restricted by OpenMath itself.
>
> <OMC><OMSTR>condition in words</OMSTR></OMC>
>
> May even make sense...
>
> However haviing flirted with the idea of agreening with adding
> condition, after dscussions at the mathml face 2to face, and
> subsequently with James, I tink we can model condition adequately at the
> CD level, so we should probably do that.
Here I am in total agreememt with David.
> That has the advantage that we can then, if desired, restrict to boolean
> valued conditions using the existing mechanisms such as STS signatures,
> rather than requiring to talk about typing at the level of OpenMath
> itself which as you suggest would be one possible result of promoting
> conditions u from the CDlevel to a core OM feature.
>
> for what it's worth, my answers ot your questions
>
>> 2.  More difficult, and probably needs Michael.  Is its introduction
>>     to Basic OpenMath:
>>     -- essential?
> no
Agreed.
>>     -- pragmatically necessary?
> no
Agreed (I now think)
>>     -- useful?
> perhaps
And, equally, prehaps not.
>>     -- tolerable?
> yes
Here I would add 'but with pain'
>>     -- impossibble?
> no

James Davenport
Hebron & Medlock Professor of Information Technology
Formerly RAE Coordinator and Undergraduate Director of Studies, CS Dept
Lecturer on CM30070, 30078, 50209, 50123, 50199
Chairman, Powerful Computing WP, University of Bath
OpenMath Content Dictionary Editor
IMU Committee on Electronic Information and Communication