[Top] [All Lists]

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

To: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: Joel Bender <jjb5@xxxxxxxxxxx>
Date: Fri, 20 Mar 2009 10:56:06 -0400
Message-id: <49C3AE86.2050002@xxxxxxxxxxx>
David,    (01)

Thank you for your comments.    (02)

> 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/).    (03)

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)."    (04)

> If the value space is "physical quantity", then a lexical representation of
> 2 metres within this space can be:
>  (lengthURI, metreURI, 2.0) .    (05)

This is a different syntactical representation that what I'm proposing 
in N3+ but...    (06)

> 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).    (07)

...there must be different URI's to represent the different concepts, 
even if they have labels that are ambiguous...no...maybe contextually 
sensitive.    (08)

> If the value space is "length", then a lexical representation of 2 metres
> can be reduced to:
>  (metreURI, 2.0) .    (09)

Since "2.0"^^metreURI is a syntactic transformation of your tuple, I 
believe we are representing the same thing.  So far, so good.    (010)

> 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.    (011)

Yep.    (012)

> 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".    (013)

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.    (014)

> 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.    (015)

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.    (016)

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.    (017)

> Actually this is not quite right, because the default definition of "times"
> is too generic.    (018)

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:    (019)

   (times (times (real "2") (unit "m")) (times (real "3") (unit "m")))    (020)

or easier to read    (021)

   (2 * m) * (3 * m)    (022)

But by the associative property of multiplication, that is the same as:    (023)

   (times (times (real "2") (times (unit "m") (real "3")) (unit "m")))    (024)

or    (025)

   ((2 * (m * 3)) * m)    (026)

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:    (027)

   (2 * 3) * (m * m)    (028)

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'.    (029)

   (times (dim (real "2") (unit "m")) (dim (real "2") (unit "m")))    (030)

Now times is just fine:    (031)

   (dim (times (real "2") (real "3")) (unitTimes (unit "m") (unit "m")))    (032)

And now 'unitTimes' is a different kind of unit transform function that 
takes two linear units and provides an area unit.    (033)

[1] <http://en.wikipedia.org/wiki/Furlong>    (034)

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    (035)

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