From: Roger L. Costello <costello@mitre.org>

Date: Tue, 08 Jul 2003 09:08:33 -0400

Message-ID: <3F0AC250.592DCEB0@mitre.org>

To: www-rdf-interest@w3.org

CC: "Thomas B. Passin" <tpassin@comcast.net>, "Costello,Roger L." <costello@mitre.org>

Date: Tue, 08 Jul 2003 09:08:33 -0400

Message-ID: <3F0AC250.592DCEB0@mitre.org>

To: www-rdf-interest@w3.org

CC: "Thomas B. Passin" <tpassin@comcast.net>, "Costello,Roger L." <costello@mitre.org>

Excellent work Tom! I am still assimilating your thoughts, and will comment more fully later. In the meantime I have an idea which I would like to toss into the mix. This is what we are currently proposing: <LengthValue> <numericalValue>6300</numericalValue> <unitSpecification rdf:resource="#Kilometers"/> </LengthValue> That is, the length of the Yangtze River is indicated by a pair of values - a number and an indication of the units. How would a machine know that the units (Kilometers) applies to the number (6300)? Answer: we are depending upon the fact that <unitSpecification> is *physically co-located* with <numericValue>. Suppose that we had those elements separated: <LengthValue> <numericalValue>6300</numericalValue> <precision>...</precision> <source>...</source> <unitSpecification rdf:resource="#Kilometers"/> </LengthValue> Now it becomes less obvious that Kilometers applies to 6300. Instead, suppose that we were to represent it like this: <Kilometers>6300</Kilometers> That is, 6300 is a value in the Kilometers Class. <Miles>3914</Miles> 3914 is a value in the Miles Class. Each value in the Kilometers Class maps to a single value in the Miles Class, and vice versa. Kilometers Miles ------------------------------------- 1.6 <--------------------> 1 6300 <--------------------> 3914 A notional definition of these classes might be: <owl:Class rdf:ID="Kilometers"> <rdfs:subClassOf rdfs:resource="&xsd;decimal"/> -- express instance value mapping equivalence here </owl:Class> <owl:Class rdf:ID="Miles"> <rdfs:subClassOf rdfs:resource="&xsd;decimal"/> -- express instance value mapping equivalence here </owl:Class> Comments? /Roger "Thomas B. Passin" wrote: > [Roger L. Costello] > > > > I would like to take a stab at defining the conceptual model for > > unitSpecification: > > > > unitSpecification > > Units > > > > M15) The value of unitSpecification is Units. > > M16) Kilometers, Miles are types of Units. > > > > Units > > | > > ---------------- > > | | > > Kilometers Miles > > > > M17) Kilometers = Miles * 1.609344 > > M18) Miles = Kilometers * (100000 / 160934.4) > > > > I dunno, Roger. Just sticking with the values for now, why just that > precision? And the numerator of the fraction has a different precision than > the denominator. That just isn't right. Any thoughts about how to specify > the multiplication in OWL? > > Any unit specification should be capable of being reduced to a combination > of fundamental units (e.g., MKSQ, cgs, etc). Given a length measurement and > its units, it seems to me that the measurement value should be capable of > being compared with some international standard. I am not saying that these > capabilities always have be be included in the statement of a measurement > value or a unit, but we ought to make sure that it can be done when needed. > > Furthermore, some units are fundamental - meter, second, kilogram, coulomb > for example. Others are considered to be combinations of the fundamental > ones. This needs to be accounted for somehow (again, not in every case). > > Let's see. There is a relationship between the "miles" value and the > "kilometers" value of a length. In this case, we know that their ratio is > constant. More generally, there is going to be some formula that relates > them. Degrees F vs degrees C is a simple example but common enough in (US) > practice. The formula may or may not be linear. > > Suppose that we have a standard kilometer and a standard mile, sort of like > a standard meter rod and a standard foot rod. The the length of the two > rods is related by > > L-std-km-rod = f(L-std-mile-rod) // f(x) = 0.625*x > L-std-mile-rod = g(L-std-km-rod) // f(x) = 1.6*x > > (neglecting numerical errors!). Here, g in the inverse function of f: > g == f^-1 // Can't format this decently in plain text! > > Also, the relation between the numerical values of a length measurement is > > Value-in-km = g(Value-in-miles) = f^-1(Value-in-miles) > > Now f and g are established by national or international standards bodies. > So we ought to be able to create resources to represent them, something like > this - > > Transform-from-miles-to-km sameTransformAs nist:g > Transform-from-km-to-miles sameTransformAs nist:f > > So here is the first thing we can establish - > > X1) The relation between a "miles" measurement value and a "kilometers" > measurement value of the same measurement is the same as the relation "g" > between a standard mile and a standard kilometer. > > This is something that can be stated in OWL (although we may not be able to > spell out how f and g work with OWL). In fact, it looks like a > samePropertyAs predicate between the transforms. A math-aware processor > could figure things out. > > Note that f and g are directional - you have to know which side gets miles > and which side gets kilometers. > > This works by appeal to standard rods, and not to the dimensions of "units" > per se. But they are closely related. A more dimensionally complex unit > could be built up in a similar way, I would think. > > Next, what does a conversion between units of measure actually operate on? > This is interesting because the transform to use depends on the input unit > spec and the target unit spec, but the transform operates on both the > numerical value and the unit sec (since miles get changed to kilometers). > This could be represented symbolically something like this - > > Value-in-units-A = g[units-A, units-B] (Value-in-units-B) > > Here, g[...] indicates that we have selected a specific "g" transform based > on the two units specs. > > What is a "Value-in-miles" measurement value? Simple - it is the value of a > LengthMeasurement for which the unitSpec equals Miles. That can be stated > in OWL. Thus, a processor could infer a Value-in-miles type by examining > the unitSpec object. > > I think I can now see how to represent the relation between a length value > in miles the kilometer version of the same length. They are related by the > transform "g" , and also by the allowed tolerance of the comparison. > > Value-in-Miles // the value of a specific measurement > numericalValue > 1 > unitSpec > Miles > > Value-in-Km // another value > numericalValue > 1.6 > unitSpec > Kilometer > > Transform > function > G > tolerance > "5%" > inputValue > Value-in-Miles > outputValue > Value-in-Kilometers > inputUnits > Miles > outputUnits > Kilometers > > With this formulation, a processor that understood how to apply the "G" > transformation could check these statements for consistency. A query > processor could return the right value in kilometers by applying the > transform to the miles version. In fact, I suspect that an xslt stylesheet > could do these tasks, given a few templates for the transforms of interest > (recall that the right transformation is specified by the two unit specs, so > we are looking at a lookup table kind of thing). > > It ought to be possible to take the specific transform stated above and make > it into a general constraint on any transformation between any > length-in-miles and the corresponding length-in-kilometers. > > Notice that the Transform is a statement (a compound one, of course). It is > not a procedure nor a formula. The statement may be true or false, > consistent with the other two statements or not. Up until now I had talked > glibly about a "transform" but had not really though about how to represent > the units conversions we havebeen talking about in an RDF-ish declarative > language. Very interesting! > > With this approach, all the challenges are localized down to just two > areas - > > 1) How to specify the "f" and "g" base transformations, and > 2) How to deal with complex units specifications. > > For named units, 2) is not needed, so many practical cases boil down to > solving 1). Item X1 above is an attempt to get at 1), but it is not really > enough. > > The "f" and "g" functions could be put into a namespace, and a processor > that claims to be aware of that namespace should know what to do with them. > That is probably better that trying to figure out how to work out all the > math stuff in an OWL-only way. Non-aware processors could infer something > about equivalent values - at least, to know if a claimed transform could be > consistent with the other data - but not be able to work out the numbers. > That seems reasonable to me. > > That is all I have time for right now. Sorry to be so rambling but I am > working this out as I go. I do not think I am quite ready to say I have a > conceptual model I feel confortable with, but I think the bits I have > sketched out here are probably OK. Once we understand things better, we > will probably see how they can be simplified for common use. > > Cheers, > > Tom PReceived on Tuesday, 8 July 2003 09:08:40 UTC

*
This archive was generated by hypermail 2.3.1
: Wednesday, 7 January 2015 15:07:46 UTC
*