[Om] Abbreviated symbols (was Re: Questions about representing units)

[Paul Libbrecht]

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.

paul


Le 22-févr.-09 à 04:52, "Professor James Davenport"  
<jhd at cs.bath.ac.uk> 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:
>>> It's come back to me. The ones we DO want are miles_per_hour etc.,  
>>> since
>>> the 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  
>> represent
>> this abbreviation?
> 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  
> FMP
> 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 your
>> MKM
>> 2008 paper:  I wouldn't agree with a representation of  
>> abbreviations by
>> introducing additional OpenMath symbols -- your two "alternative
>> definition" cases in that paper.  I share your view that "this  
>> isn't an
>> OpenMath problem".
>> You suggested OWL as a solution.  I don't completely agree with  
>> that.  OK,
>> one
>> could introduce a string-valued OWL "datatype property" for  
>> annotating
>> OpenMath 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.
> True. The OWL suggestion was based on a worldview in which OWL  
> becomes THE
> 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  
> suggestion
> is at least plausible.
>> not-yet-standard) approach is defining notations, and we do that by
>> mapping
>> content markup patterns to presentation markup templates.  That  
>> said, we
>> could
>> 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
> Om at openmath.org
> http://openmath.org/mailman/listinfo/om
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2203 bytes
Desc: not available
Url : http://openmath.org/pipermail/om/attachments/20090222/80bb460b/attachment-0001.bin