[
Lists Home |
Date Index |
Thread Index
]
Alaric B Snell wrote:
> Roger L. Costello wrote:
>
> > This is quite a radical approach. I am surprised that there
> > aren't more comments, since the "conventional wisdom" is
> > not to treat kilometer as a property/relation/function, but rather
> > to treat it as the value of a property, e.g.,
> >
> > <River id="Yangtze">
> > <length unit="kilometer">6300</length>
> > </River>
>
> The advantage of "<kilometres>6300</kilometres>" as opposed to <length
> unit="kilometre"> is in modularity of type definition.
I believe that the key advantage of this approach:
<River id="Yangtze">
<length>
<kilometer>6300</kilometer>
</length>
</River>
is the capability to state the relationship to a length value expressed
using a different unit-of-measure, e.g.,
<River id="Yangtze">
<length>
<mile>3914</mile>
</length>
</River>
Namely, the relationship is:
"a kilometer property is equal to a mile property times 1.62".
A very compelling example of this capability is to determine that
two documents, which express a location using different
units-of-measure, are referring to the same location, e.g.,
<Map id="M1">
<location>
<cartesian-coordinate>
...
</cartesian-coordinate>
</location>
</Map>
<Map id="M21">
<location>
<polar-coordinate>
...
</polar-coordinate>
</location>
</Map>
Namely, the relationship is:
"a cartesian-coordinate property is equal to a polar-coordinate
property ...". (If someone can complete this sentence I would be very
interested. I have long forgotten how to convert coordinate systems.)
I don't believe that with the other approach:
<River id="Yangtze">
<length units="kilometers">6300</length>
</River>
it would be possible to make such relationship statements, and that's a
show-stopping disadvantage.
Thoughts? /Roger
|
