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 > [email protected] > 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 [EMAIL PROTECTED] http://kwarc.info/kohlhase skype: m.kohlhase * International University Bremen until Feb. 2007 ---------------------------------------------------------------------- _______________________________________________ Om3 mailing list [email protected] http://openmath.org/mailman/listinfo/om3
