ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] N3+, an N3-variant for units

To: "[ontolog-forum] " <ontolog-forum@xxxxxxxxxxxxxxxx>
From: David Leal <david.leal@xxxxxxxxxxxxxxxxxxx>
Date: Fri, 20 Mar 2009 16:16:05 +0000
Message-id: <1.5.4.32.20090320161605.00d8e160@xxxxxxxxxxxxxxxx>
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 "times-like" 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 times-like 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 times-like 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 "times-like" 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/REC-xmlschema-2-20010502/).
>
>According to my interpretation of the standard, the si:meter URI cannot 
>be used as a user-derived 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 non-zero 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 Lisp-ish 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/ontolog-forum/  
>Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
>Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
>Shared Files: http://ontolog.cim3.net/file/
>Community Wiki: http://ontolog.cim3.net/wiki/ 
>To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
>To Post: mailto:ontolog-forum@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
e-mail:   david.leal@xxxxxxxxxxxxxxxxxxx
web site: http://www.caesarsystems.co.uk
============================================================    (013)


_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx    (014)

<Prev in Thread] Current Thread [Next in Thread>