- From: Jon Hanna <jon@spin.ie>
- Date: Tue, 1 Jul 2003 13:14:14 +0100
- To: <www-rdf-interest@w3.org>
> 3. Getting back to the original problem ... Suppose that Document #1
> contains this description:
>
> <rdf:Description>
> <length>
> <LengthMeasure>
> <transform rdf:resource='#LengthInKilometers'/>
> <number>6300</number>
> </LengthMeasure>
> </length>
> </rdf:Description>
>
> And Document #2 contains this description:
>
> <rdf:Description>
> <length>
> <LengthMeasure>
> <transform rdf:resource='#LengthInMiles'/>
> <number>3906</number>
> </LengthMeasure>
> </length>
> </rdf:Description>
>
> An application that receives these two documents should be able to
> recognize that the two resources have the same length value, just
> expressed using different transforms. What role should an OWL ontology
> play in assisting the application in understanding the relationship
> between these two length values?
Typing as I'm thinking, please excuse untidy thought processes.
First off, let's merge the graphs:
<rdf:Description>
<length>
<LengthMeasure>
<transform rdf:resource='#LengthInMiles'/>
<number>3906</number>
</LengthMeasure>
</length>
<length>
<LengthMeasure>
<transform rdf:resource='#LengthInKilometers'/>
<number>6300</number>
</LengthMeasure>
</length>
</rdf:Description>
A river can have only one length. OWL can state this cardinality. Since we
have two resources given for a property which can only exist once we know
that the two <length> predicates refer to the same object, and hence the two
LengthMeasure objects are the same:
<rdf:Description>
<length>
<LengthMeasure>
<transform rdf:resource='#LengthInMiles'/>
<number>3906</number>
<transform rdf:resource='#LengthInKilometers'/>
<number>6300</number>
</LengthMeasure>
</length>
</rdf:Description>
This is clearly problematic, especially if we then take the following,
obviously incorrect, subgraph:
<rdf:Description>
<length>
<LengthMeasure>
<transform rdf:resource='#LengthInMiles'/>
<number>6300</number>
</LengthMeasure>
</length>
</rdf:Description>
We are going to need another level of indirection:
<rdf:Description>
<length>
<Distance>
<measurement>
<MilesLength number="3906"/>
</measurement>
<measurement>
<KilometerLength number="6300"/>
<measurement>
</Distance>
</length>
</rdf:Description>
I've chosen to use rdf:type to simplify the RDF/XML somewhat to compensate
for this, and also because a MilesLength is quite clearly a "thing" and
hence a type of resource, and hence best described using a class.
So a river has a single length, which is of a single distance which can have
multiple measurements. No incorrect subgraphs can be obtained.
It's worth noting that this is compatible with:
<rdf:Description>
<length>3906 miles</length>
</rdf:Description>
While the above has obvious flaws, it *is* going to occur, especially in
applications where length measurements serve no purpose other than being
"blindly" handed to users. While any attempt to produce something richer out
of this last RDF/XML example is fraught with the potential for error,
producing this last example out of the one preceding it is trivial, so we at
least have a one-way transformation between applications available to us.
Now, as for conversion between one and the other.
With what I've ended up with above I've moved away from Thomas' suggestions
a bit, so I think I'm gong to have to look at conversion again from scratch
to justify what I have so far.
Ignoring OWL for the moment, let's have a (rough, not even strawman)
conversion application that allows us to say something like:
<owl:Class rdf:ID="MilesLength">
<con:conversion>
<con:ConversionFunction>
<con:target rdf:resource="#KilometerLength"/>
<con:transform>{something meaning multiply by 1.609344}</con:transform>
</con:ConversionFunction>
</con:conversion>
<owl:Class>
A few things are noteworthy here.
First 6300km isn't 3906 miles! It's more like 3914 (are we using different
miles perhaps?).
Second we have the problem of how we describe conversion functions. Ideally
we would want to allow for different strategies to be used (to allow for
expansion and improvement) but to also have a good default so people
wouldn't expand and improve unless they really needed to.
Must conversions can be described as a factor by which one multiplies or
divides, but not all. All conversions can be described as a mathematical
equation, an ECMAScript function or one or more XPath functions. That brings
a parsing burden, and possibly a security risk (in the ECMAScript option).
OWL comes into this only in the use of owl:Class. What we'd really like to
have is something which tied MilesLength and KilometerLength together in
owl, if only to say that they had a conversion function available. The best
I can think of right now is something like:
<owl:Class rdf:ID="MilesLength">
<con:convertibleTo rdf:resource="#KilometerLength"/>
<con:conversion>
<con:ConversionFunction>
<con:target rdf:resource="#KilometerLength"/>
<con:transform>{something meaning multiply by 1.609344}</con:transform>
</con:ConversionFunction>
</con:conversion>
<owl:Class>
or
<owl:Class rdf:ID="MilesLength">
<con:conversion>
<con:ConversionFunction>
<con:origin rdf:resource="#MilesLength"/>
<con:target rdf:resource="#KilometerLength"/>
<con:transform>{something meaning multiply by 1.609344}</con:transform>
</con:ConversionFunction>
</con:conversion>
<owl:Class>
con:origin is obviously the owl:inverseOf con:conversion, and could be
deduced from the first attempt.
con:convertibleTo is pretty much orphaned from the actual conversion, but
has the advantage of directly tying the two resources involved. At first
glance con:convertibleTo would appear to be an owl:SymetricProperty, though
I'm not sure that would hold for all conversions.
Other properties would allow us to know the names and abbreviations of the
units involved in various languages for presentation to human users:
<owl:Class rdf:ID="KilometerLength">
<con:unit>
<rdf:label xml:lang="en">kilometer</rdf:label>
<con:abbreviation xml:lang="en">km</con:abbreviation>
</con:unit>
<!-- yadda yadda -->
</owl:Class>
Received on Tuesday, 1 July 2003 08:12:28 UTC