From: Jeremy Carroll <jjc@hplb.hpl.hp.com>

Date: Fri, 27 Jun 2003 20:26:43 +0100

Message-ID: <3EFC9A73.90107@hplb.hpl.hp.com>

To: "Thomas B. Passin" <tpassin@comcast.net>

CC: www-rdf-interest@w3.org

Date: Fri, 27 Jun 2003 20:26:43 +0100

Message-ID: <3EFC9A73.90107@hplb.hpl.hp.com>

To: "Thomas B. Passin" <tpassin@comcast.net>

CC: www-rdf-interest@w3.org

I think I like this treatment. Jeremy Thomas B. Passin wrote: > [Roger L. Costello] > >>2. There is a relationship between >> >> concat(rdf:value, units) in resource #1, and >> concat(rdf:value, units) in resource #2. >> >> "There is a relationship between the concatenation of the >> value of the rdf:value property with the value of the units >> property in resource #1, and a similar concatenation of >> values in resource #2." >> >> The relationship is: >> >> 1.0 inch = 2.54 centimeter >> >>Do you agree that this is the relationship between the two >>anonymous resources? >> > > No, I do not. Trying to stick close to the way you have set this out, there > is not a direct relationship between the __concatenations__ of unit and > value. You could say there is a relationship between the __tuple_s_ (1.0, > inch) and (2.54, cm), but that is still superficial because it depends on > the number of significant figures and the round-off strategy. I would > rather have it be more fundamental. > > Here is what we know, it seems to me - > > 1) Both resources are length measures. > 2) The value of a length measure can be expressed numerically in different > units. > > (This is a scalar quantity. A more complex quantity, like a vector or > tensor, would have to be expressed as some structured value). > > We know a few other things, but they can be formulated in various ways. > Here is one way. > > 3) The numerical value of a length measure may be obtained by applying an > operator (or a transformation) to it. That is, conceptually > length-in-inches = L1 * M, where L1 is the operator for getting the length > in inches, and M is the measure. > > 4) A measure may have any number of such operators or transforms, one for > each different unit of measure. > > Here is a set of triples (minus namespaces) for your two resources that > captures, I think, the essence of these points - > > {resource > {type:length-measure} > {value: > transform: > { > type:length-in-inches} > number: 1 > } > } > } > > {resource > {type:length-measure} > {value: > transform: > { > type:length-in-cm} > number: 2.54 > } > } > } > > I think that these are admirably simple, and I doubt that you can simplify > them any more without losing their essence. > > The resource type can obviously be stated in OWL as part of an ontology, and > so can the transform type. If we had a standard way to make math statements > with OWL, we could make an OWL statement that the two transforms (inch and > cm) had some kind of "equivalentValueTo" relationship. > > This approach takes the matter of the relationship between length in cm and > length in inches away from the individual resources and puts in onto the > expression of the relationship between the transform types. I think this is > very appropriate. > > The upshot is that you need to come up with some convention for expressing > the relationship between the transforms - or of testing for equivalence - > and then everything else can be handled in OWL. > > Cheers, > > Tom P > > >Received on Friday, 27 June 2003 15:27:24 UTC

*
This archive was generated by hypermail 2.3.1
: Wednesday, 7 January 2015 15:07:46 UTC
*