Dear Joel, (01)
I think that we are in broad agreement, but think that you may have
misunderstood my notation. It is one of the problems of doing things in
typescript :). (02)
I used the notation (*rl) to represent a "timeslike" operator where the
first operand is a real and the second operand is a length. (03)
In your example you have: (04)
(2 * m) * (3 * m) (05)
Here there are two completely different timeslike operators:
 one where the first operand is real and the second length  for which I
used the notation (*rl); and
 one where both operands are length  for which the notation (*ll) could be
used,
so being precise about the nature of the timeslike operators we have: (06)
(2 (*rl) m) (*ll) (3 (*rl) m) (07)
Operand (*ll) is not needed for the definition of length, but is needed for
the definition of area. (08)
Operand (*rl) is "timeslike" because it satisfies most of the properties of
"times" defined in http://www.w3.org/TR/MathML2/appendixc.html#cedef.times ,
except commutivity. It cannot satisfy commutivity because the first and
second operands are from different spaces. (09)
I am not convinced that converting MathML into OWL is the right thing to do,
because although all of maths can be probably be regarded as a branch of
logic, it is not always convenient to do so and the result is often
incomprehensible. An RDF serialisation of MathML would be useful but this is
just a question of syntax, and would not fix any semantic problems with MathML. (010)
Best regards,
David (011)
At 10:56 20/03/2009 0400, you wrote:
>David,
>
>
>Thank you for your comments.
>
>> There are many ways in which these URIs can be used to represent the length
>> that is 2 metres. One of these is as a datatype (see
>> http://www.w3.org/TR/2001/RECxmlschema220010502/).
>
>According to my interpretation of the standard, the si:meter URI cannot
>be used as a userderived datatype, because it is doing something
>orthogonal to "constrain [certain of] its properties (e.g., range,
>precision, length, format)."
>
>> If the value space is "physical quantity", then a lexical representation of
>> 2 metres within this space can be:
>> (lengthURI, metreURI, 2.0) .
>
>This is a different syntactical representation that what I'm proposing
>in N3+ but...
>
>> The inclusion of lengthURI within the lexical representation is necessary
>> because the same unit can be used for different physical quantities. (e.g.
>> the same unit is valid for moment of force and for energy).
>
>...there must be different URI's to represent the different concepts,
>even if they have labels that are ambiguous...no...maybe contextually
>sensitive.
>
>> If the value space is "length", then a lexical representation of 2 metres
>> can be reduced to:
>> (metreURI, 2.0) .
>
>Since "2.0"^^metreURI is a syntactic transformation of your tuple, I
>believe we are representing the same thing. So far, so good.
>
>> Unfortunately, the datatype approach does not care about the semantics of
>> metre and length, i.e. that "the metre" is a member of "length". Hence the
>> datatype approach is limited.
>
>Yep.
>
>> It seems obvious that (and can be proved that), given a nonzero length U,
>> for any length X there exists a real r such that:
>>
>> X = r (*rl) U
>>
>> Arbitrarily we can choose U to be "the metre".
>
>And because my documents are semantic marked up notations from many
>years ago, if I provide measurements in furlongs [1], then I simple have
>to provide you with r1 and our systems become interoperable.
>
>> We could seek an rdf/rdfs/owl serialisation of this, but in MathML we
>> already have a perfectly valid serialisation. It may be better to embed
>> MathML in rdf/rdfs/owl, rather to invent something new.
>
>Because the underlying data storage and processing models for the XML
>DOM and RDF triples are so wildly different, I don't think an effort to
>do this would gain any traction. There are too many arbitrary and
>capricious design decisions for markup (should some concept be a child
>element or an attribute?) that make perfectly reasonable transformations
>painful. But I digress.
>
>Another problem with MathML is that the same equation can be represented
>in several different ways. It would be far easier, and ultimately more
>productive for the MathML folks to provide an owl specification
>specifically targeted at content, leaving the presentation and combined
>markup for the embedded HTML folks.
>
>> Actually this is not quite right, because the default definition of "times"
>> is too generic.
>
>I think that's because it is not really multiplying. For example, a
>table is 2m wide and 3m long, its area is 6m^2. In Lispish notation,
>you might think it's like this:
>
> (times (times (real "2") (unit "m")) (times (real "3") (unit "m")))
>
>or easier to read
>
> (2 * m) * (3 * m)
>
>But by the associative property of multiplication, that is the same as:
>
> (times (times (real "2") (times (unit "m") (real "3")) (unit "m")))
>
>or
>
> ((2 * (m * 3)) * m)
>
>Which is not true, the center expression (m * 3) is meaningless. If
>swapping the '3' and 'm' suddenly gives it meaning, then you are not
>really multiplying. Commuting to this:
>
> (2 * 3) * (m * m)
>
>is a different kind of transformation, and the MathML folks should make
>that clear. It would be easier with a "associate with dimension"
>concept, I'll call it 'dim'.
>
> (times (dim (real "2") (unit "m")) (dim (real "2") (unit "m")))
>
>Now times is just fine:
>
> (dim (times (real "2") (real "3")) (unitTimes (unit "m") (unit "m")))
>
>And now 'unitTimes' is a different kind of unit transform function that
>takes two linear units and provides an area unit.
>
>
>Joel
>[1] <http://en.wikipedia.org/wiki/Furlong>
>
>_________________________________________________________________
>Message Archives: http://ontolog.cim3.net/forum/ontologforum/
>Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontologforum/
>Unsubscribe: mailto:ontologforumleave@xxxxxxxxxxxxxxxx
>Shared Files: http://ontolog.cim3.net/file/
>Community Wiki: http://ontolog.cim3.net/wiki/
>To join: http://ontolog.cim3.net/cgibin/wiki.pl?WikiHomePage#nid1J
>To Post: mailto:ontologforum@xxxxxxxxxxxxxxxx
>
> (012)
============================================================
David Leal
CAESAR Systems Limited
registered office: 29 Somertrees Avenue, Lee, London SE12 0BS
registered in England no. 2422371
tel: +44 (0)20 8857 1095
mob: +44 (0)77 0702 6926
email: david.leal@xxxxxxxxxxxxxxxxxxx
web site: http://www.caesarsystems.co.uk
============================================================ (013)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontologforum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontologforum/
Unsubscribe: mailto:ontologforumleave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgibin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontologforum@xxxxxxxxxxxxxxxx (014)
