Re: (Round 2) Proposed Extensions to OWL

[Frank Manola]

> Could I suggest a look at
> http://ksl-web.stanford.edu/knowledge-sharing/papers/engmath.html?
>

Oh, that is an excellent reference, Frank! Cruising rapidly through it, I
see that for Roger's case of a 1-inch length, the corresponding concept is
"constant-quantity".  To quote from the constant-quantity page -

"A constant-quantity is a constant value of some physical-quantity"

and

"All constant quantites can be expressed as the product of some
dimensionless quantity and a unit of measure. This is what it means to say a
quantity `has a magnitude'."

and, from the physical-quantity page -

"Physical quantities are distinguished from purely numeric entities like a
real numbers by their physical dimensions. A physical-dimension is a
property that distinguishes types of quantities."

"Every physical-quantity has exactly one associated physical-dimension. In
physics, we talk about dimensions such as length, time, and velocity; again,
nonphysical dimensions such as currency are also possible. "

That is __precisely__ what my formulation does.

{resource                       // the "physical-quantity"
    {type:length-measure}   // the "physical dimension"
    {value:                      // the "constant-quantity"
        transform:           // the mapping from physical to constant
            {
                type:length-in-inches
                number: 1           // the constant-quantity's value
            }
    }
}

I used "transform" so that the value can be linked to a resource that
defines the mapping. Of course that definition could be done inline, but
better to do it once and refer to it than to create a lot of equivalent
mapping resources.  I call it a transform instead of a product to have a
more general model - other types of quantities will use other types of
transforms (although I really prefer "operator" to "transformation" here).

Here is an exactly equivalent version using the vocabulary from the Stanford
paper -

{physical-quantity
    {label: "Roger's Length Measurement"}
    {physical-dimension:length}
    {constant-quantity
        {transform:   // not sure what Stanford term to use here
            {type:length-in-inches}
            {value:1}
        }
    }
}

I would say that the Stanford ontology is just what should be used here, and
the way I have formulated the triples captures the design effectively.

Note that you could put more than one transform into the group of
statements:

{
{physical-quantity
    {physical-dimension:length}
    {constant-quantity
        {transform:
            {type:length-in-inches}
            {value:1}
        }
        {transform:
            {type:length-in-cm}
            {value:2.54}
        }
    }
}

If our app knows how to take an inch measure and convert it to cm - in other
words, if it understands the "length-in-inches" amd length-in-cm
transforms -  we do not have to have this redundancy, but if the app does
not, it could be useful.  In fact, an app could start to build up its own
inch-to-cm mapping from a number of statements like this, even without
understanding the transform.

Cheers,

Tom P

Received on Saturday, 28 June 2003 11:47:59 UTC