Re: Paper on Quantities in OWL

Hi David!

On Tue, Aug 26, 2008 at 6:04 PM, David Leal
<david.leal@caesarsystems.co.uk> wrote:
> 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,

No. This is a primitive feature of the language. In certain restricted
cases it is *equivalent* (or at least equisatisfiable) with our
translation, so we use that as a simple, generic implementation
technique. Otherwise, it's exactly on a par with:

   PropertyAssertion(a:height a:JohnDoe "6.0"^^xsd:decimal)

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

This translation work so long as you don't intend for the assertion to
interact with equations.

This is an implementation detail, though, and not intended for user exposure.

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

Assuming we have naming support in OWL2 for derived types, you can
easily name a quantity by deriving it from owl:quantity. For example
(coining a naming axiom):

    NamedDatatype(BijanHeight DataOneOf("6.0 ft"^^owl:quantity)

Now you can use that quantity via BijanHeight anywhere. This would
also work for ranges (e.g., using min/max inclusive/exclusive on
owl:quantity). One slight issue is if you just want to type the
dimension, but I can think of several syntaxes for that including
allowing just unit names( "m"^^owl:quantity or "length"^^owl:quantity)
or having derived types (owl:length).

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

You can do that now, but I don't recommend it. The derived statements
have *also* been through a normalization process (i.e., converting to
standard units; dimensionality analysis) so writing them by hand is
*not* the same as writing the original statement (without doing a fair
bit of computation!)

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

There's two things: 1) users shouldn't use this intermediate form; 2)
I have no problem with naming quantities qua types. Currently OWL2
doesn't allow that, but I think that's an oversight.

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

hmm.

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

Hmm. I was sort of expecting this to be handled by the OWL half (e.g.,
OWL defines hasHeight and hasCSAGTP :)) as disjoint properties and the
type analysis handles the dimensional analysis. But I see that won't
work. Er...hrm. Seems like we need a nominal type system over
dimensions. Ok, will think about it more.

Thanks!

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

Again, this is entirely internal. No user should ever ever see it. In
pellet, we'll replace it with a native implementation soon

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

They *aren't* computationally tractable, except in limited cases.
(This was, I totally confess, rather ellipitical.)

If you want to have an n-ary datarange (e.g., CONSTRAINT =
lambda(x,y,z)(z < x+y)) such that you can say, "a person's depth is
less than their breath + their height) as a constraint on persons
(e.g., allValuesFrom hasBreath, hasHeight, hasDepth.CONSTRAINT), then
the properties have to be direct properties (i.e., hasB, hasH, and
hasD have to be on the *same* individual). This is called "path free"
concrete domains. Obviously, having paths would be enormously useful
(my height is less than any of my parent's friend's children's height)
and would make the structured object approach viable. Alas, we just
don't know how to do it and won't for the foreseeable future. It's
*much* harder than the path free case and often undecidable.

Thus, aside from usability, if you would like to use quantities in
equations in owl and have those equation interact with the knowledge
base, we are forced into having only direct properties. Thus, with
equations, our translation approach will be broken.

However, just having datatypes is useful, so it's a good transitional
implementation technique.

I hope this helps clarify.

BTW, if you plan to attend OWLED, I'm really hoping to get a
quantities in OWL BOF going.

Cheers,
Bijan.

-- 
Cheers,
Bijan.

http://clarkparsia.com

Received on Tuesday, 26 August 2008 17:49:21 UTC