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/RECxmlschema220010502/). (03)
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)." (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 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". (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 Lispish 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)
Joel
[1] <http://en.wikipedia.org/wiki/Furlong> (034)
_________________________________________________________________
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 (035)
