Re: Specifying units of the RDF geo:alt property

Hi all.  Some comments below:

Charles McCathieNevile wrote:
> 
> Hi Kjetil,
> 
> On Tue, 01 Nov 2005 23:54:44 +0100, Kjetil Kjernsmo 
> <kjetil@kjernsmo.net>  wrote:
> 
>> Currently, it is undefined what it is...
>>
>> In a recent chat on #swig on irc.freenode.net, Dan Brickley suggested I
>> should take the issue to these list, and he would implement any
>> consensus that is formed here.
> 
> ...
> 
>> I would personally tend to favour that the geo:alt property is specified
>> as "The altitude above the local WGS 84 ellipsoid in meters", but
>> clearly, this is problematic if there is allready a lot of data in the
>> wild where it is given in e.g. feet. Then, I guess, the only hope is to
>> use rdf:value, as seen in the example
> 
> 
> I'd like to see people using datatypes to do this. In the SWAD-E 
> geoInfo  workshop in Budapest we came up with a couple of simple 
> approaches to  describing what floor of a building you are on [1] - 
> something that is  available to many people who don't have a GPS and 
> rely on looking up their  wgs84 points on some map. (I have no idea what 
> the altitude of my office  is in any unit except floors).
> 
> I know that implementors get upset if there are tags required that are  
> long, but it is not actually terribly complex to use a datatype, except  
> that with no clear mechanism for defining them in a machine-readable 
> way  you currently rely on some magic mechanism for dealing with them.

Using datatypes for *some* of this is reasonable.  However, using 
datatypes of *all* of this may create problems, relating to the general 
lack of the "magic mechanism" you mention.  It seems to me that the more 
semantics are made explicit, in the form of RDF properties and their 
values (such as separate properties for the value and the units) 
describing instances of classes, the more arbitrary software can 
potentially do with it.  On the other hand, when too much of the 
semantics of the value is bundled up in the defintion of the datatype, 
software either knows the datatype or it doesn't.

For instance, in [1] you define a property "height" with values from a 
datatype "etage".  I can see the arguments for that, but a pretty basic 
thing that using "etage" doesn't explicitly tell a program is the fact 
that the value is an integer (the comment says that it is, but that's 
not all that visible to a program).

In his original post, Kjetil made the comment:

> I'm a physicist, and I generally dislike seeing quantities with a 
> dimension as a number without a unit, but in this case, I think we 
> might be better off just defining it in terms of the meter. If anybody 
> used feet, they will have to update.

I share this dislike, and my preference would be to use the datatypes 
more for the computer-representational stuff (like "integer), and use 
properties for the more "semantic" stuff (like the units).  (I'd also 
prefer to have the units defined as classes in a measurement ontology, 
so I could also record the relationship between units like meters and 
feet, but that's another story;  it does help with interoperability 
though).  Admittedly, this (at least at the moment), is more complicated 
to represent.

Also, simply defining a property like "altitude" as having a certain 
unit built in works better in some cases than in others.  As a simple 
example, aircraft fuel capacities are often represented using either 
units of volume (gallons or liters) or units of weight (pounds or 
kilograms).  These measurements are useful for different purposes (the 
volume is limited by the size of the fuel tanks, the weight is limited 
by whether or not I can get the plane off the ground with that much fuel 
on board), depending on the application they aren't always directly 
convertable (the volume changes with temperature/altitude while the 
weight doesn't), and aircraft instruments sometimes use one and 
sometimes the other.

This whole business is worth a lot more discussion IMHO.  The RDF Core 
Working Group spent a *whole lot* of time on datatypes.  What's in the 
specs now is (I think) a reasonable start, but it represents a 
compromise, there were a number of issues left for future work, and it'd 
be nice to see more work done on this.

--Frank

> 
> cheers
> 
> chaals
> 
> [1] http://www.w3.org/2001/sw/Europe/200409/geox/hi.rdf
>

Received on Wednesday, 2 November 2005 22:37:21 UTC