Abbreviated symbols are definitely a matter of input and output and not matter of semantic to my taste. However the need to declare a new symbol often has it's own reasons... merely stating that it should be handled by something else is not really a good answer.
There's a need to declare a symbol as "the same as, if you want to ignore this part of the world". The reason I suggested OWL at the time was that it does have abilities to declare that two classes are to be considered the specialization or the same thing provided you can see such a statement.
I absolutely know that FMPs can declare that one construct is equal to another but the geometry of facts is different. I think the right question that one should be able to answer is "what to do if I meet symbol bla-bla and can't do anything with it".
- an FMP that states that bla-bla is bla would be wrong, it would mean that bla-bla has no finer semantic - an FMP that states that bla-bla is a specialization of bla would allow the processor to ignore bla-bla and replace all occurrences of OMS-bla-bla to OMS-bla
Probably some other discovery effects should be analyzed. paulLe 22-févr.-09 à 04:52, "Professor James Davenport" <[email protected]> a écrit :
On Sat, February 21, 2009 8:16 pm, Christoph LANGE wrote:On Saturday 21 February 2009 19:34:45 Professor James Davenport wrote:We didn't,because the whole question of "how do we handle abbreviations" wasn't fully worked out. At the time, DefMP didn't exist, never mind FMPIt's come back to me. The ones we DO want are miles_per_hour etc., sincethe abbreviation, mph, is non-standard.Really? To my understanding it's wrong to represent such abbreviations on the OpenMath level. And, secondly, I find miles_per_hr in the OpenMath CDs, but I don't find any reference to "mph". So how did you representthis abbreviation?type="alias" or any of the other ideas now circulating.<potential-bias type="omdoc kohlhase ...">:-)More generally, probably off-topic for this discussion, but nevertheless interesting (IMHO), a comment on what you said about abbreviations in yourTrue. The OWL suggestion was based on a worldview in which OWL becomes THEMKM2008 paper: I wouldn't agree with a representation of abbreviations byintroducing additional OpenMath symbols -- your two "alternativedefinition" cases in that paper. I share your view that "this isn't anOpenMath problem".You suggested OWL as a solution. I don't completely agree with that. OK,onecould introduce a string-valued OWL "datatype property" for annotatingOpenMath unit symbols with their abbreviation, e.g. leading to an annotation like http://www.openmath.org/cd/units_imperial1#miles_per_hr http://www.openmath.org/ns/unit-annotation#abbrev "mph". (Recall my OM3 Trac posts about more flexible metadata; within such a framework, one could even embed this into an OpenMath CD.) But then, we'd require an application to know OWL, or at least this particular annotation vocabulary.answer, a world view which certainly hasn'tprevailed yet.More naturally from my point of view is treating this problem as a problem of rendering OpenMath to presentation markup. For that, our (admittedly,No - it's a bi-directional problem, I think. If not, then your suggestionis at least plausible.not-yet-standard) approach is defining notations, and we do that by mappingcontent markup patterns to presentation markup templates. That said, wecould easily define a "presentation context" "abbreviated" and then map units_imperial1#mile to "mi" units_time1#hour to "hr" (arith1#divide units_imperial1#mile units_time1#hour) to "mph".Sorry - I don'tseehow this one works.… i.e. solve the problem without introducing an additional symbol. </potential-bias>James Davenport Visiting Full Professor, University of Waterloo Otherwise: Hebron & Medlock Professor of Information Technology and Chairman, Powerful Computing WP, University of Bath OpenMath Content Dictionary Editor IMU Committee on Electronic Information and Communication _______________________________________________ Om mailing list [email protected] http://openmath.org/mailman/listinfo/om
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Om mailing list [email protected] http://openmath.org/mailman/listinfo/om
