# Re: (Round 2) Proposed Extensions to OWL

From: Thomas B. Passin <tpassin@comcast.net>
Date: Sat, 28 Jun 2003 11:48:24 -0400

Message-id: <001201c33d8c\$b5afd0e0\$6401a8c0@tbp1>
```
[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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:43 UTC