Re: Paper on Quantities in OWL

Dear Bijan,

I am a little more into your paper, and I hope that you can clarify some
points. The essence seems to be conveyed by example 3. You suggest that a
user will make the single statement:

  PropertyAssertion( a:height a:JohnDoe "6.0 ft"ˆˆowl:quantity )

This single statement is regarded as a shorthand, which is transformed for
processing into the three statements:

  PropertyAssertion( mint:height a:JohnDoe _:d1 )
  ClassAssertion( mint:DimLength _:d1 )
  PropertyAssertion( quantity:magnitude _:d1 "1.8288"ˆˆowl:real )

Some thoughts upon which I would be interested in your opinions are as follows:

1) We have been arguing about whether quantities can be assigned URIs. In
your three statements, the length quantity, is assigned the internal
identifier "d1". There are many other statements which could be made about
this quantity. If a user wished to refer to the quantity in other
statements, he or she could assign an URI to the quantity and make the three
derived statements explicitly.

Do you regard this as:
a) something which will be done only occasionally (a statement I agree with); or
b) something which should be prevented?

2) The range of mint:height is probably a:length. You have classified the
quantity "d1" according to its dimension. This is useful, but less useful
than classifying it according to the type of the quantity.

Quantities of different types can have the same dimension. For example the
cross section area gradient in a tapered pipe (rate of change of area with
respect to distance along the pipe) also has dimension length. It is not
valid to add a length to a cross section area gradient, even though they
have the same dimension.

There are very many different quantity types, so that it has to be possible
for different engineering domains to extend a standard set as required.

3) The name "quantity:magnitude" is confusing. A quantity has a magnitude
whether or not you describe it using a number. In the example, the
relationship between "d1" and 1.8288 is scale:metre, so why not say so, to give:

  PropertyAssertion( scale:metre _:d1 "1.8288"ˆˆowl:real )

If you are determined to be vague, you can have:

  PropertyAssertion( scale:internal _:d1 "1.8288"ˆˆowl:real )

4) At the end of section 2.1 in your paper, you say "That is, instead of
writing that a person’s height is 2 meters (where height is represented as a
data property) we have to make height an object property with a range Length
which has a property like hasUnit and another measuredValue. But now there
is no hope of using these values in equation systems for the forseeable
future, ..."

This rejected approach seems to be similar to that described in Tim
Berners-Lees' proposal http://www.w3.org/2007/ont/unit. However, the three
statements of the internal form in example 3 of your paper are very nearly
consistent with the TBL proposal.

Why are these three statements computationally tractable, whilst the TBL
proposal is not?

Best regards,
David

============================================================
David Leal
CAESAR Systems Limited
29 Somertrees Avenue
Lee London SE12 0BS
tel:      +44 (0)20 8857 1095
mob:      +44 (0)77 0702 6926
e-mail:   david.leal@caesarsystems.co.uk
web site: http://www.caesarsystems.co.uk
============================================================

Received on Tuesday, 26 August 2008 17:05:22 UTC