Re: (Round 2) Proposed Extensions to OWL

[Roger L. Costello]

> > <River rdf:ID="Yangtze">
> >     <length>
> >         <LengthMeasure>
> >             <transform rdf:resource='#LengthInKilometers'/>
> >             <number>6300</number>
> >         </LengthMeasure>
> >     </length>
> > </River>
>
> I have three questions:
>
> 1. I believe that what we are proposing is that the above represents
> "Best Practice" in expressing a length value.  Do you agree?
>

Well ,__I__ think so, but I am not sure that my opinion is any kind of Best
Practice.  Apparently the people at Stanford who worked up the
physics/engineering ontology think so, since what they wrote up is
isomorphic to my formulation (I still think it would be good to adopt their
vocabulary).  That should give it some more weight.

> 2. What are the advantages of expressing it as above versus, say, this
> way:
>
> <River rdf:ID="Yangtze">
>     <length rdf:parseType="Resource">
>         <rdf:value>6300</rdf:value>
>         <units rdf:resource='#LengthInKilometers'/>
>     </length>
> </River>
>

I think that the length should be more specific than just "resource".    Is
it plausible that there could be some OWLish statement that sanctions the
inference that anything that has a "units" property whose value is
"LengthInKilometers" must be a "&official_physical-quantity;Length" ?  There
are two points here -

A) Could the concept "units" be a reasonable replacement for "tranform"?
B) Should the "Length" property have a specific type stated, rather than
have to be inferred?

B) is easy (to me, anyway) - just state outright what its type is.  A) is
probably fine - more a matter of terminlogy.  However, one would well
advised to look into other potential uses for "units" to try to make sure
that they would all be compatible with this usage.

In any event, the real point is that

1) an instance of a  length is a specific type of quantity that has
2) a real physical length and
3) a numerical value that is paired with some particular variety of
measurement unit.

The length - or any physical quantity - has an inherent physical dimensional
value (for example, acceleration has (distance/time^2).  It is essential to
be able to capture this dimensionality somehow, even when there is no
standard named unit for the quantity.

Also note that these dimensional formulas can be written in many equivalent
ways.  In the physical sciences, one can reduce any such formula to a
canonical form, something like cancelling out prime numbers in a fraction.
However,one way to test for equivalence of two candidate dimensional
formulae would be to divide one by the other and see if the result is 1.

To me, the most useful and simplest statements would relate the
length-in-inches transform to the length-in-cm transform.  That statement
would only have to be made once, and would apply just to that pair of
transforms.


> 3. Getting back to the original problem ... Suppose that Document #1
> contains this description:
>
> <rdf:Description>
>     <length>
>         <LengthMeasure>
>             <transform rdf:resource='#LengthInKilometers'/>
>             <number>6300</number>
>         </LengthMeasure>
>     </length>
> </rdf:Description>
>
> And Document #2 contains this description:
>
> <rdf:Description>
>     <length>
>         <LengthMeasure>
>             <transform rdf:resource='#LengthInMiles'/>
>             <number>3906</number>
>         </LengthMeasure>
>     </length>
> </rdf:Description>
>

I make it 3915 (rounded) miles for 6300 km, not 3906, and that brings up an
important point, which I referred to a few posts ago in thread -

> An application that receives these two documents should be able to
> recognize that the two resources have the same length value, just
> expressed using different transforms.

That cannot be done with the problem as stated.  The lengths cannot be
compared without giving a tolerance for the comparison.  Otherwise, the
would only compare equal by accident, since to arbitrary precision two
values are bound to be different.  So there cannot be a simple OWL statement
(I mean, just one triple involved) for comparison, even if we could
represent the math.

Instead, we would have to construct a comparison operator (a resource).  It
might be something like this -

{RogersEqualityTest
    {rdfs:type km-to-miles-compares-equal-property}
    {tolerance
        {physical-quantity
            {transform percent}
            {number 10}
         }
      }
    }

{
{LengthMeasure
   {transform rdf:
       {type LengthInKilometers}
       {number 6300}}
    }
 },
RogersEqualityTest,
{LengthMeasure
   {transform rdf:
       {type LengthInMiles}
       {number 3906}
    }
 }
}

This says that the first LengthMeasure has a "RogersEqualityTest"
relationship with the second length, meaning that they are numerically
equivalent to within 10% (or you could specify a tolerance in km, miles,
inches, cm, etc. - that is why I formulated the declaration of the test that
way).  This statement might be true or it might not be true.  Of course, the
two LengthMeasures could be made identified resources instead of bnodes,
which would make the basic equality statement simpler, at the cost of adding
new resources.

> What role should an OWL ontology
> play in assisting the application in understanding the relationship
> between these two length values?
>

As far as I can see, the math part has to be doable somehow - outside of
OWL, since so far OWL has not got math capabiltiies.  Once that is in place,
OWL can help you declare RogersEqualityTest and constrain where you can
apply it, etc.

Cheers,

Tom P

Received on Tuesday, 1 July 2003 22:07:09 UTC