- From: Roger L. Costello <costello@mitre.org>
- Date: Wed, 02 Jul 2003 06:33:24 -0400
- To: www-rdf-interest@w3.org
- CC: Jon Hanna <jon@spin.ie>, tpassin@comcast.net, "Costello,Roger L." <costello@mitre.org>
An excellent analysis Jon! I believe that your conclusion is correct
that another level of indirection (i.e., another nesting level) is
required.
At the moment I have just one comment (I am still working through your
ideas on expressing conversions, as well as Tom's most recent
comments). Here is the form that your analysis produced:
<River rdf:ID="Yangtze">
<length>
<Length>
<measurement>
<LengthInMiles>
<number>3914</number>
</LengthInMiles>
</measurement>
</Length>
</length>
</River>
(I made a few small changes. Let me know if they are not acceptable.)
Here is an alternate form, which is inline with Tom's proposal:
<River rdf:ID="Yangtze">
<length>
<Length>
<measurement>
<LengthMeasure>
<transform rdf:resource="LengthInMiles"/>
<number>3914</number>
</LengthMeasure>
</measurement>
</Length>
</length>
</River>
Which of these two forms is preferred? Are there advantages of one over
the other? /Roger
Jon Hanna wrote:
>
> > 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 Wednesday, 2 July 2003 06:35:21 UTC