RE: Proposed extensions to OWL?

> -----Original Message-----
> From: www-rdf-interest-request@w3.org
> [mailto:www-rdf-interest-request@w3.org]On Behalf Of Thomas B. Passin
> Sent: 15 June 2003 17:36
> To: www-rdf-interest@w3.org
> Subject: Re: Proposed extensions to OWL?
>
>
>
> [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
> here.
>
> 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.

I think there already are the facilities for representing operators in RDF,
even if we call them by another name - processes [1] (as in a strawman
schema I did a while ago) or services [2] (as in DAML-S).

An alternative might be simply to include the appropriate bit of Python (or
whatever) in a literal, with a predicate something like 'applyThis'. This
sounds quick and dirty, but if the language used is well defined, then it
should be possible for the whole thing to be (formally) well defined.

Cheers,
Danny.

[1] http://dannyayers.com/2001/04/rpp.htm
[2] http://www.daml.org/services/daml-s/0.9/

Received on Sunday, 15 June 2003 16:16:28 UTC