ontolog-forum
[Top] [All Lists]

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

 To: "[ontolog-forum] " David Leal Fri, 20 Mar 2009 16:16:05 +0000 <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] > >_________________________________________________________________ >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) ```
 Current Thread Re: [ontolog-forum] N3+, an N3-variant for units, David Leal Re: [ontolog-forum] N3+, an N3-variant for units, Joel Bender Re: [ontolog-forum] N3+, an N3-variant for units, David Leal <=