Re: Proposed extensions to OWL?

I think in practical terms the relation described is a process. For some
purposes, it is a process that can quite adequately be represented as
multiplication by a factor of 2.54 (or 25 for mm), but for other applications
that isn't really good enough. So not only is it a process, it is a class of
processes (unit conversion) which can have varying algorithms applied.

In the example given the difference between algorithms is the precision, but
there are other possiblities. How do you convert latitude/longitude into
distances from a point, given that they are non-linear scales? (And do you
mean map distance or distance in space, taking account of altidude, or
walking distance where you have to factor altitude changes along the path?)

As has been noted earlier there is a vocabulary for describing simple
arithmetic relations - this is not part of OWL but seems a reasonable one to
use for simple conversions. But beware of falling into the trap that a rough
conversion, useful because it does all you need, may not be a true
conversion, and would be misleading in other cases.

Chaals

(Who spends his spare time cooking, with units like "some", "a dash", and
"lots", and has ahd to taste examples of why conversions are more difficult
than they seem).

On Sun, 15 Jun 2003, Thomas B. Passin wrote:

>
>[Danny Ayers]
>[I wrote]
>> > 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).
>>
>
>I __am__ talking about using RDF.  As you say, rpp is a strawman, and anyway
>it is for process modeling, is it not?  I do not think that is really the
>right concept, although obviously it could be made to work (see below).
>
>I do think you might be able to use a DAML-S SimpleProcess, but there are
>two things about doing so -
>
>1) It is not the right concept, since the relationship between units is not
>really a process.
>
>2) DAML does not have a vocabulary for describing the actual transformation
>itself (like units-cm = 2.54*units-inch).  So we still have to invent an
>ontology for it and some machinery for making it work, even if we do use a
>DAML SimpleProcess description.  If we have to do that anyway, why not take
>the next step and create a vocabulary for the purpose, one that could be
>extended to more complicated transforms in the future?
>
>I say SimpleProcess instead of AtomicProcess just because the current DAML-S
>draft says that an AtomicProcess must be grounded, but not a SimpleProcess.
>Since we are describing an abstract transfomation rather than a service, I
>think that SimpleProcess fits best.
>
>> 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.
>>
>
>I do not think that this will let a processor discover that two different
>statements that use different units refer correctly to the same quantity.
>It _will_ let the processor figure out how to make a conversion (which I
>suppose could then be checked for consistency, but that can be tricky), but
>I do not think that is what we are really after here.  If we go and invent
>the vocabulary and machinery to do this, we might as well just do the real
>thing instead.
>
>Cheers,
>
>Tom P
>
>

-- 
Charles McCathieNevile  http://www.w3.org/People/Charles  tel: +61 409 134 136
SWAD-E http://www.w3.org/2001/sw/Europe         fax(france): +33 4 92 38 78 22
 Post:   21 Mitchell street, FOOTSCRAY Vic 3011, Australia    or
 W3C, 2004 Route des Lucioles, 06902 Sophia Antipolis Cedex, France

Received on Monday, 16 June 2003 05:40:34 UTC