RE: A proposal for two additional properties for LOCN

Frans Knibbe wrote:

Ø  So now I tend to agree that using a value and a unit to specify the spatial resolution could be the best solution. Perhaps we can make the unit default to meter, if it is not specified?

Lets not allow defaults. The burden of supplying an explicit uom on small numbers of values is not enough to justify the risk.
OTOH - it often makes sense to specify units for a complete data set (or a column in a table), rather than having to treat each item as a tuple.


Ø  In some experiments I had the need to denote particular units of measurement. I used the QUDT vocabulary (http://qudt.org) for that. Is that a good (the best?) ontology for units to be used in this case? I think it is preferable to let the unit be a resource instead of a string.

We adopted QUDT for some environment projects in Oz. It is easy to add new ones in your own namespace, though you do have to manage their publication and persistence - see http://environment.data.gov.au/def/unit/ for some that we found missing from QUDT. But we still used the QUDT types in their definitions.

For a fully scalable system, nothing beats UCUM, but it is not delivered as RDF :(

Simon