Re: (Round 2) Proposed Extensions to OWL

[Roger L. Costello]
>
> <LengthValue>
>       <numericalValue>6300</numericalValue>
>      <unitSpecification rdf:resource="#Kilometers"/>
> </LengthValue>
>
> That is, the length of the Yangtze River is indicated by a pair of
values - a
> number and an indication of the units.
>
> How would a machine know that the units (Kilometers) applies to the number
> (6300)?  Answer: we are depending upon the fact that <unitSpecification>
is
> *physically co-located* with <numericValue>.

>Suppose that we had those elements
> separated:
>
> <LengthValue>
>       <numericalValue>6300</numericalValue>
>       <precision>...</precision>
>       <source>...</source>
>      <unitSpecification rdf:resource="#Kilometers"/>
> </LengthValue>
>
> Now it becomes less obvious that Kilometers applies to 6300.
>

Not at all.  This is part of the reason for the design being the way it is.
A LengthMeasurementValue is required to have exactly one unitSpecification
property and one numericalValue property.  So there can be __no ambiguity__
regardless of the order of any other elements within the LengthValue.

If you wish to make a statement that requires a different numerical value,
you have to use another LengthValue node (they can both belong to the same
Measurement, of course).

> Instead, suppose that we were to represent it like this:
>
> <Kilometers>6300</Kilometers>
>
> That is, 6300 is a value in the Kilometers Class.
>
> <Miles>3914</Miles>
>
> 3914 is a value in the Miles Class.
>
> Each value in the Kilometers Class maps to a single value in the Miles
Class,
> and vice versa.

But in practice, the last sentence is incorrect.  1 mile could map to any or
all of (1.6 km, 1.61 km, 1.609 km, ....).  The point is that these are all
different values, and so each one belongs in its own LengthValue resource.
Simple, and nothing new is needed.

Anyway, from the point of view of proper striping, those elements should be
predicates, so they should be lower-cased.  The natural language equivalent
would be

"There is a LengthValue with a miles property of 3914"

And this would certainly be just as feasible as my original formulation.
The question is whether there is value in having the units spec broken out
explicitly into a separate statement as opposed to having it rolled into the
"miles" and "kilometer" properties.

At this point I think that having the units spec separate has several real
advantages for practical processing, in addition to the fact that
conceptually physical measurements have both values and units.

First, it would be much easier to do a simple extraction of the numerical
value.  With a separate numerical value, a processor can just get the
numericalValue property.  The other way, it has to test each property to see
if it is a subtype of "lengthMeasurementValueProperty" before it can
retrieve the number.  Score one for a separate units spec.

Second, with a separate units spec you can define all those dimensional
things we have talked about, and the transforms between them, just by
working with the units specs themselves, which is conceptually clean.  The
other way, each different property like milesProperty, kilometersProperty
somehow has to be able to have these things specified.  This sounds a lot
more complex, although we can't be sure until we actually work it out in
more detail.  Score a weaker one for a separate units spec.

Third, what about a unit spec for which there is no established name?  With
a separate unitsSpecification, you could actually have the units be a
bnode - it does not have to be a globally identifiable resource.  So you
could build one on the fly for special cases.  But what will you call the
property for the combined approach?  Very unwieldy.  Score a third for a
separate units spec.

So far the separate unit spec is winning by about 2 1/2 to 1.

OTOH, I bet that it would be possible to state that the milesProperty-style
statement is equivalent to the full design, and so for a particular
collection of data you could still use it as a more convenient shorthand.  I
do not know how to do that in OWL/RDF, but I am sure that it would be quite
feasible with Conceptual Graphs, so I imagine that it can be done with OWL
as well.

I'm convinced, I do not know about you!

Cheers,

Tom P

Received on Tuesday, 8 July 2003 10:06:48 UTC