W3C home > Mailing lists > Public > www-rdf-interest@w3.org > June 2003

Re: (Round 2) Proposed Extensions to OWL

From: Thomas B. Passin <tpassin@comcast.net>
Date: Sat, 28 Jun 2003 11:48:24 -0400
To: www-rdf-interest@w3.org
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"


"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
                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 -

    {label: "Roger's Length Measurement"}
        {transform:   // not sure what Stanford term to use here

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


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.


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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:46 UTC