Re: Paper on Quantities in OWL - response on a minor point

Dear Bijan,

I need to do much more work on your paper (and so will be quiet for a
while). However, I would like to respond immediately on a minor point.

You say:
>Actually, MathML does not have any support for quantities per se, afaict,
and doesn't plan to:
>   <http://www.w3.org/TR/mathml-units/>

This is not correct. The document you reference has almost all the
capabilities that are needed for quantities and units, except that they are
only accessible within the "MathML world". (When I said that MathML was a
"closed world", I meant this in a general sense meaning that MathML has a
scope limited to mathematics, rather than in the technical sense related to
inferencing.)

In MathML, I can state that:

- the quantity x (local name) with URI http://www.example.com/x is a length:

 <semantics>
  <csymbol definitionURL="http://www.example.com/x">x</csymbol>
  <annotation definitionURL='http://.../dimension/length'/>
 </semantics>

- the unit quantity m (local name) with URI http://.../units/metre is a length:

 <semantics>
  <csymbol definitionURL="http://.../units/metre">m</csymbol>
  <annotation definitionURL='http://.../dimension/length'/>
 </semantics>

- x = 10.3 m

 <apply>
  <eq/>
  <csymbol definitionURL="http://www.example.com/x">x</csymbol>
  <apply>
   <times/>
   <cn>10.3</cn>
   <csymbol definitionURL="http://.../units/metre">m</csymbol>
  </apply>
 </apply>

This is fine, except that:
1) it is MathML and not RDF/OWL;
2) it needs an extension for quantities which are described using scales
rather than units (e.g. Celsius, ITS90, Richter, decibel, Moh, etc.);
3) somebody has to provide the namespace "http://www.../" used in the MathML
document - that somebody should be BIPM or ISO.

Best regards,
David

At 11:49 25/08/2008 +0100, you wrote:
>
>On Mon, Aug 25, 2008 at 10:43 AM, David Leal
><david.leal@caesarsystems.co.uk> wrote:
>> Dear Bijan,
>>
>> Language tags - a useful analogy
>> --------------------------------
>> You say that XML language tags are analogous to your proposed approach to
>> units and scales.
>
>At least with regard to naming. I think that simple, easy to use names
>are really important (at least at first) and think that the cost of
>centralized coordination is relatively small in this case.
>
>> I agree that their use is simple and ubiquitous, and do
>> not oppose this approach.
>
>I'm glad we're beginning to converge.
>
>> On the other hand there many requirements to do with languages which XML
>> language tags do not cover:
>> - librarians wish to specify which ink on paper or digital resources in
>> their libraries are in which language;
>
>This seems covered in an appropriate language using tags. At least,
>it's possible to see how that would work (e.g., how dc:language
>works).
>
>> - linguists wish to record relationships between languages;
>
>I don't see that this is *in principle* a problem except inso far as
>the set of language tags is more or less fixed and yet not
>comprehensive. A more serious issue may be that they are not
>compositional enough.
>
>> - for many purposes it is useful to record which language is spoken where.
>> (When you find an address in Google maps, it might be useful to be told that
>> the local language is French, or Gujarati. :)
>
>Seems to be handled (or handlable) in the same manner as dc:language.
>
>> For the more sophisticated applications a language ontology is required.
>
>Thus far, I only see one, the linguist one. But there the objects
>modeled *are languages*. Such ontologies are not primarily *users* of
>language indicators (at least, with respect to the objects modeled).
>
>Consider that even such ontologies may well want to use language tags
>(e.g., to indicate the property language handling for an example).
>
>> It
>> would be useful to know how an XML language tag relates to objects in this
>> ontology.
>>
>> Quantities, units and scales
>> ----------------------------
>> It is probably true that 90% of the time, the only thing that you need to
>> know about a quantity is a single identification by a number and a unit or
>> scale.
>
>I don't think that's the only service offered by our approach. But
>suppose that: Getting 90% of the way seems to be a good thing!
>
>> But, the other 10% is very important and is of very high value to
>> science and engineering.
>
>Ok. Let's grant that.
>
>> It includes all real measurements, and all
>> quantities with tolerances.
>
>Quantities with tolerances can be easily represented without extension
>in our current framework. Since we define a datatype basically modeled
>on owl:real, we also allow the standard facets. Thus you can easily
>define a datatype as being a quantity *within a range* and then, e.g.,
>say that some object hasLength >1m and <500ft
>
>> (It may be that of the other 90%, many of the quantities which appear to be
>> nominal dimensions or rated values are not really quantities at all. For
>> example, in a "2 inch" pipe fitting, there is not necessarily any dimension
>> that is 2 inches. Instead, "2 inch" is a classification of the pipe fitting
>> with respect to a standard.)
>>
>> In dimensioning, it is often necessary to make statements such as:
>>  X less than (diameter of MyShaft) + (maximum clearance specified by
>> MyDesignManual)
>
>As long as the latter value is either constant or gleanable from a
>property directly on me, it works in our system (well, you might also
>need linear equations, but we're working on that:
>   <http://www.w3.org/2007/OWL/wiki/Data_Range_Extension:_Linear_Equations>
>
>If everything is explicit, and you primarily care about insantiation,
>then DL Safe rules can handle this.
>
>An pure ontology based approach isn't going to work *at all*.
>Essentially, you end up modeling the syntax of equations without
>making the semantics of those equations available to the reasoner.
>This doesn't seem too useful.
>
>>  X greater than (diameter of MyShaft) + (minimum clearance specified by
>> MyDesignManual)
>>
>> The diameter of MyShaft is a quantity, but it may not yet be known.
>
>Our approach absolutely allows for you to work with unknown or only
>partially constrained quantities. When we combine with linear
>equations, you won't have to declare the derived unit, even.
>
>> It is
>> possible to make the statements involving an anonymous quantity, e.g.:
>>
>>  <Length>
>>   <diameterOf rdf:resource="MyShaft"/>
>>  </Length>
>>
>> but it may be convenient to assign an identifier to the quantity.
>
>Pace having an identifier "Length" (which I've gone back and forth on)
>this can easily be represented in our approach. Just say that MyShaft
>has Length >0m (which is, after all, probably what you really mean
>here). I'm perfectly open to proposals for additional subtypes of
>owl:quantity: it really depends on the style of representation a
>significant class of users prefer.
>
>> Politics
>> --------
>> It is necessary to address these difficult cases, because there is a
>> perception in some of the engineering community that "RDF/OWL is all very
>> well for trivial cases, but does not address what we really do".
>
>I wouldn't be at all surprised by that. But then the right way to deal
>with that is to provide them with some real, usable, representational
>power. Having studied several *massive* attempts to produce
>sophisticated ontologies of quantities in OWL, I've concluded that,
>for the most part, they add a lot of complexity without delivering
>*any*, much less commensurate, representational power. As we show in
>our paper, the ontology based approaches will not be able to interact
>with any reasonable equation add on to OWL for the foreseeable future.
>
>The big challenges I see is adding arbitrary polynomial support,
>including with transcendental constants, and complex number support.
>Alas, we veer into the hard and into the undecidable there.
>
>> Their
>> response is to use homemade XML schemas or to use RDF/OWL in bizarre ways.
>>
>> Personally, I would very much like to see MathML and OWL closer together.
>> MathML can make the statements about the relationships between quantities
>> that you want,
>
>Actually, MathML does not have any support for quantities per se,
>afaict, and doesn't plan to:
>
>   <http://www.w3.org/TR/mathml-units/>
>
>> but it is a closed world and cannot specify the semantics of
>> the quantities with respect to real world objects.
>
>(I don't think closed vs. open world assumptions is relevant here.)
>
>So, what our approach offers *now* (or in the near future :)) is:
>
>1) A way of talking about specific quantities or ranges of quantities
>using familiar units both in assertions about individuals and in class
>definitions.
>2) A syntax for arbitrary derived units from a given base set.
>3) Various entailments based on statements using those assertion,
>including dimensional analysis (for dimensional compatibility),
>simplification, unit conversion, scaling,
>4) A path toward (in)equation support for quantities, e.g., that 1m
>+2secs is inconsistent where as 2m/1s = 2 m/s. This support is *not*
>for computation but for supporting entailments.
>5) A clearly differentiating advantage to using OWL. We aren't
>competing on high performance computing or complex mathematical
>manipulation (at least yet :)). We're competing on being able to
>provide effective support for building complex conceptual models which
>incorporate (in a nice way) quantitative representation.
>
>I think 5 is compelling. We don't have to do *everything*, just some
>good stuff in an effective way.
>
>As an example, my grad student, Matthew Horridge (of Protege4/OWL API
>fame) got his BS as an areospance engineer (and interned at an
>airplane engineering firm...he's fun to fly with). He read the units
>paper and got very excited and started work on an airplane ontology
>(of course, he immediately started pressing on the equation support).
>This is only one data point, but it is an interesting one. He's worked
>with OWL *for years*, but what stimulated him  to work on this
>ontology is the prospect of being able to naturally work with
>quantities.
>
>I feel confident we can handle your 10% (at least that which can be
>handled at all given what we now know how to do!) under our approach.
>I'm happy to try to encode any example you care to write up so we can
>figure out whether my confidence is warranted :)
>
>-- 
>Cheers,
>Bijan.
>
>http://clarkparsia.com
>
>

============================================================
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 08:08:42 UTC