Re: (Round 2) Proposed Extensions to OWL

[Roger L. Costello]

> A very good question Tom!  Your question has helped me to clarify things
in my
> mind.
>
> Initially, my objective was to determine what extensions would be needed
in OWL
> to be able to assert that these two instances are equivalent:
>
> <LengthValue>
>           <numericalValue>3914</numericalValue>
>           <unitSpecification rdf:resource="#Miles"/>
> </LengthValue>
>
> <LengthValue>
>           <numericalValue>6300</numericalValue>
>           <unitSpecification rdf:resource="#Kilometer"/>
> </LengthValue>
>

I think that what is needed is a predicate that indicates that the two
values are equivalent (but see below for more on that).  I suggested a name
for such a property, equivalentTransformTo, but that may not be the best
name.  Maybe equivalentValue would be better.

I do not think that OWL per se needs to be extended to include this, because
it is a domain-specific notion (although its domain might be pretty broadly
inclusive).

Defining the intended meaning of this property in prose is fairly easy, but
how to do it with the help of OWL + RDF is another story.  I do not have an
answer ready to go.  But even without it, the property could be used in RDF
statements and an aware processor would know what to do with it.

> Recently, I have come to realize that it would also be very useful to
simply
> provide in an ontology statements of units and how they relate.  Then
given such
> statements, applications could determine at run-time if two instances are
> equivalent.  I believe that this capability would fall into this category:
>
> > 2) Provide a means by which a processor could infer the equivalence of
two
> > values (with their units included, of course)
>

Well, an RDF-ish way to do this would be to take the two values, construct
the equivalence resource for them (the form that I illustrated a few days
ago and that you summed up nicely yesterday), and then see whether the
result is consistent within the required tolerance with a cononical
statement of equivalence.

Of course there are pleny of procedural ways as well, if the processor
understands the subject.  Again, see below for more on equivalence.

> I am excited by the first category you mention:
>
> > 1) Make a statement of such equivalence without having to create a
specific
> > instance of a transformation for each case.
>
> This would be the ultimate!  Do you have ideas on achieving this?  /Roger
>

Not yet, because I do not yet know how to move from the concrete instance
examples to abstract constraints.

There are many kinds of equivalences.  Here are some -

1) The units are dimensionally identical.
2) The numerical values are equal.
3) The numerical values match to within some tolerance.
4) The numerical values match what the transform says they should be within
a specified tolerance.
5) The numerical values match what one transform says they should be but not
what another says they should be.

1) can be crucial for some purposes - it is part a dimensional analysis, and
could be used to decide whether to continue looking at a piece of data or
not.

2) and 3) seem odd, because we expect the transform to crank out different
values, not the same values.  But someone might want to make some point
(maybe for teaching purposes, I don't know - like -40 deg F being the same
temperature as -40 deg C, an mildly interesting fact that might figure in an
accident investigation sometime).  So they are at least conceivable, even if
they would not often come up.

4) is what we usually have in mind.

5) might apply when there are several standards that are not quite
interchangable, like different reference surfaces for the Earth.

Ideally, what we come up with should be useful for all these cases (and
there may be more),  and especially should support some degree of
dimensional analysis.  Now this last is something that we could bring in
later, but I would like to see that what we start with is would be
compatible with such extensions.

So the notion of equivalence is more complex than it looks.  At least we
have to choose what we mean by it, then we can proceed.

One thing is clear - the definition of equivalence has to include the
allowed tolerance.  That means constructing a special predicate that
includes or is constrained by the desired tolerance, like 1 km or 5%.  Of
course, you would reuse it when possible.  Something like this -

{rogersSpecialEquivalenceProperty
    {owl:subPropertyOf #genericMilesToKilometersEquivalenceProperty}
    {allowedTolerance
        {value 5}
        {unitSpec #Miles}
     }
}

{#ValueA rogersSpecialEquivalenceProperty #ValueB}

I am assuming that you can assign properties to properties, since a property
is a kind of resource, but I am not sure if OWL lets you do this or not.
If not, then here would be the first case we would have identified where you
would need an OWL extension.  But I presume that full OWL does allow it,
because all RDF statements are compatible with full OWL, and it is certainly
can be a legal RDF statement.

This scheme is very simple.  Again, any complexity is localized to the
generic equivalence properties.

Cheers,

Tom P

Received on Thursday, 10 July 2003 09:55:13 UTC