- From: Thomas B. Passin <tpassin@comcast.net>
- Date: Sun, 6 Jul 2003 13:09:26 -0400
- To: <www-rdf-interest@w3.org>
- Cc: "Costello,Roger L." <costello@mitre.org>
[Roger L. Costello]
> I have incorporated Benja's and Tom's comments, and added a few of my
> own. Comments? /Roger
>
> -----------------------------------------------------------------
> Conceptual Model:
>
> TangibleObject
> physicalProperty
> PhysicalProperty
> measurement
> Measurement
> measurementValue
> MeasurementValue
> numericalValue
> unitSpecification
> precision
> source
> ... (any other measurement metadata)
>
> -----------------------------------------------------------------
Almost there. A general measurement might be characterized by something
more complex than a (value, units) pair. That pair applies to a
lengthMeasurement but not to a Measurement in general. So the general case
has to avoid having any details about the measurementValue, like this -
TangibleObject
physicalProperty
PhysicalProperty
measurement
Measurement
measurementValue
MeasurementValue
precision
source
... (any other measurement metadata)
> Conceptual Model Applied to a TangibleObject which has a length:
>
> TangibleObject
> length
> Length
> measurement
> LengthMeasurement
> value
> LengthValue
> number
> units
> precision
> source
> ... (any other measurement metadata)
>
This is not quite synchronized with the general form above. I think it
should be -
TangibleObject
length
Length
measurement
LengthMeasurement
measurementValue // instead of "value"
LengthValue
numericalValue // instead of "number" (see below)
unitSpecification // instead of "units"
precision
source
... (any other measurement metadata)
> -----------------------------------------------------------------
> Conceptual Model Property Hierarchies:
>
> physicalProperty
> |
> ---------------------------------
> | |
> lengthProperty areaProperty
> | |
> ------------------------- -------------
> | | | | | |
> length width height thickness area size
>
> and:
> numericalValue unitSpecification
> | |
> number units
>
So far I do not see value in specializing numericalValue to number, and
unitSpecification to units. I think that any one numerical value will have
some unit spec, but the form of a unit spec will be the same for all values.
If that is correct, no specialization is needed. In the interest of As
Simple As Possible, I would like to see them go away. I favor the name
"numericalValue" over "number" for the more general case just because the
notion of "number" might tend to arise in other places, other ontologies,
and carries a lot of connotations tha we don;t want here.
> -----------------------------------------------------------------
> Conceptual Model Class Hierarchies:
>
> PhysicalProperty Measurement Value
> | | |
> ---------------- LengthMeasurement MeasurementValue
> | | |
> Length Area LengthValue
>
> -----------------------------------------------------------------
> Concrete Example that Conforms to the Conceptual Model:
>
Subject to resolution of my suggestions above ...
> <River rdf:ID="Yangtze">
> <length>
> <Length>
> <measurement>
> <Measurement>
> <value>
> <Value>
> <number>6300</number>
> <units rdf:resource="#LengthInKilometers"/>
> </Value>
> </value>
> <precision>(+/-)10km</precision>
> <source>OGC</source>
> </Measurement>
> </measurement>
> </Length>
> </length>
> </River>
>
In practice, "source" would probably be a URI - that is, an RDF resource.
"precision" probably will need some modeling as well, but OK for now. As it
stands, it is only human-readable and we will want it to RDF-interpretable
at some point. Maybe something like this would be a start -
MeasurementPrecision
precisionType
StdError
precisionValue
NumericalValue
number // units are "%" by definition of StdError
Cheers,
Tom P
Received on Sunday, 6 July 2003 13:05:35 UTC