RE: A proposal for two additional properties for LOCN

IMHO, "Units and Resolution" is an interdisciplinary interoperability problem for Linked Data better not handled peicemeal. Standards making bodies naturally want to stick to Best Practices rather than prohibitions, and I see no contributory negligence in that.  Some problems do not lend themselves to incremental solutions.

It is a Day of Rememberance in the US for 2001-09-11.  A major issue then was Radio Frequency Incompatibility (interoperability) between the responding Agencies.

Computer Engineering - Domain Authorities, Linked Data, and perhaps RDF - can potentially suffer from the same problem.  Not the format of the data delivered but rather incoherence from multiple delivery frequencies.

Planning and Strategy (StratML) is particularly sensitive in this regard.  The security issue around resources affects perimeter security and far pre-dates "Cybersecurity".  This is not dramatic innovation, but at worst avoids tedious typing.
http://www.rustprivacy.org/2014/balance/opers/

"Frequency" also plays a negative-pattern role in Work-Life Balance solutions as I mentioned the other day. http://lists.w3.org/Archives/Public/public-locadd/2014Sep/0024.html

--Gannon
--------------------------------------------
On Wed, 9/10/14, Simon.Cox@csiro.au <Simon.Cox@csiro.au> wrote:

 Subject: RE: A proposal for two additional properties for LOCN
 To: frans.knibbe@geodan.nl, andrea.perego@jrc.ec.europa.eu
 Cc: ocorcho@fi.upm.es, public-locadd@w3.org
 Date: Wednesday, September 10, 2014, 10:01 PM
 

 
 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
 L
  
 
   
 Simon

Received on Thursday, 11 September 2014 21:51:19 UTC