[Om3] FM re three avenues for the condition elements

[Michael Kohlhase]

Dear all,

It has turned out that I will be able to attend the flash meeting after
all, which I am happy about.

To speed up things, let me just say that since I seem to be the only one
in the whole OM world with sympathies for an <OMC> element I will
(grudgingly/gracefully) admit defeat and retract the proposal. So then
we can talk about a general way to treat the pragmatic-to-strict
translation.

Michael



Professor James Davenport wrote:
> 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
>
> _______________________________________________
> Om3 mailing list
> Om3 at openmath.org
> http://openmath.org/mailman/listinfo/om3
>   

-- 
----------------------------------------------------------------------
 Prof. Dr. Michael Kohlhase,       Office: Research 1, Room 62 
 Professor of Computer Science     Campus Ring 12, 
 School of Engineering & Science   D-28759 Bremen, Germany
 Jacobs University Bremen*         tel/fax: +49 421 200-3140/-493140
 m.kohlhase at jacobs-university.de http://kwarc.info/kohlhase 
 skype: m.kohlhase   * International University Bremen until Feb. 2007
----------------------------------------------------------------------