Re: (Round 2) Proposed Extensions to OWL

[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 P

Received on Monday, 7 July 2003 18:00:09 UTC