From: Thomas B. Passin <tpassin@comcast.net>

Date: Mon, 7 Jul 2003 18:04:10 -0400

Message-ID: <001c01c344d3$b1890100$6401a8c0@tbp1>

To: <www-rdf-interest@w3.org>

Cc: "Costello,Roger L." <costello@mitre.org>

Date: Mon, 7 Jul 2003 18:04:10 -0400

Message-ID: <001c01c344d3$b1890100$6401a8c0@tbp1>

To: <www-rdf-interest@w3.org>

Cc: "Costello,Roger L." <costello@mitre.org>

[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 Monday, 7 July 2003 18:00:09 UTC

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