- From: Thomas B. Passin <tpassin@comcast.net>
- Date: Tue, 8 Jul 2003 10:10:51 -0400
- To: <www-rdf-interest@w3.org>
- Cc: "Costello,Roger L." <costello@mitre.org>
[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