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

Re: Proposed extensions to OWL?

From: Thomas B. Passin <tpassin@comcast.net>
Date: Sun, 15 Jun 2003 11:36:20 -0400
To: www-rdf-interest@w3.org
Message-id: <004a01c33353$de71d4d0$6401a8c0@tbp1>

[Roger L. Costello]
> The more that I think about this problem, the more convinced I am that
> adding something like a conversionFactor attribute is the right way to
> go, e.g.,
>     <owl:DatatypeProperty rdf:ID="length-in">
>        <owl:equivalentProperty rdf:resource="#length-cm"
>             owl-x:conversionFactor="length-in/value() =
>                                     length-cm/value() / 2.54"/>
>        <rdfs:range rdf:resourse="&xsd;decimal"/>
>     </owl:DatatypeProperty>

Approaches like this come from thinking that a length expressed in inches is
somehow related to a length expressed in centimeters.  This leads one to
think of expressing it using a predicate, which is what Roger is attempting

But under the surface, the real situation is richer.  There is some physical
quantity, one that obeys the laws of nature.  When we write it down, we
choose one or another system of units to express it.  In my post a few
minutes ago, I suggested modeling the conversion as a concept in its own
right.  I think this is an obvious approach since we have been talking about
these conversions as things in themselves, so obviously they are  concepts.

More fundamentally, it is useful to view the expression of the actual
numerical value as an __operation__ on the underlying physical quantity.
Modern physics uses operators all the time.  There is an operator that
translates an object in time, another that translates it in space, and so
on.  A units conversion is, from this viewpoint, just another operation.
Many business functions can be viewed as transformations of business data
from one state to another using an appropriate operator.

An operation has parameters and an algorithm or formula.  It is not
(necessarily) just a predicate.  Modeling a units conversion as a resource,
as I did in my last post, is a way to represent a simple, scalar operator.
It would probably be better in the long run to devise a general way to
represent operators that can perform non-scalar as well as scalar
transformations.  These would probably turn to be extremely useful in many
ways, some of them not anticipated now.


Tom P
Received on Sunday, 15 June 2003 11:33:30 UTC

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