Re: (Round 2) Proposed Extensions to OWL

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 P

Received on Tuesday, 8 July 2003 09:08:40 UTC