Re: Geographical names in locn (was: ISA Core Location Vocabulary)

Hi All,

I agree with Frans, but would go further to say that a Geographic Name is not a blood line.  For interoperability, it can be defined in terms of a Population Clock[1] continually turning over from generation one to generation two.  In the US this happens about every 16 seconds.  That is a coincidence.  The point about a Population Clock is that it takes into account immigration and emigration also [2].

Notation like this should work fine
<locn:adminUnitL1>./united_states/union/hawaii/honolulu/#ID</locn:adminUnitL1>

A business customer list *is* a blood line and not a Population Clock.
If you attempt to separate the name tokens (even for spelling purpose) then you unwittingly create a blood line and this leads to difficulty with geometries.

--Gannon
[1] http://www.census.gov/popclock/
[2] http://www.census.gov/population/international/data/idb/estandproj.php
--------------------------------------------
On Mon, 12/23/13, Frans Knibbe | Geodan <frans.knibbe@geodan.nl> wrote:

 Subject: Geographical names in locn (was:  ISA Core Location Vocabulary)
 To: "Andrea Perego" <andrea.perego@jrc.ec.europa.eu>
 Cc: "LocAdd W3C CG Public Mailing list" <public-locadd@w3.org>
 Date: Monday, December 23, 2013, 6:11 AM
 
 
   
     
   
   
     On 2013-12-21
 0:56, Andrea Perego
       wrote:
 
     
     
       
 
         
           
             
                
               I
                 recognize the terms from the INSPIRE themes,
 but I also
                 notice that semantic interoperability is not
 complete.
                 Take for example the geographical name. In
 INSPIRE it is
                 a complex class, but although its data type
 is not
                 defined in the vocabulary, it seems that the
 concept is
                 reduced to a single text string.
 
               
               
 
               
               This was in version 1.00. In the current
 one, the
                 range of locn:geographicName is
 intentionally
                 undefined. 
               
 
               
               About why there is no class for
 geographical names,
                 please take into account that the purpose of
 this
                 vocabulary was to define just a small set of
 terms that
                 could be used across sectors of the public
                 administration to support interoperability.
 Differently
                 from the notion of "address",
 there was no use case
                 requiring a more detailed definition of
 geographical
                 names, so it was let undefined.
               
 
               
               Of course, we can work on this, if the
 LOCADD CG
                 thinks otherwise.
               
 
             
           
         
       
     
     
 
     It seems to me that leaving the data type of
 locn:geographicName
     undefined is like leaving locn:geometry undefined: It
 may be good
     for adaptability, but I am not sure it helps
 interoperability.
     Wouldn't it help to just add the the property
 SpellingOfName, with
     data type xsd:string?  That way there would be a clear
 link with the
     INSPIRE specification, helping interoperability with
 INSPIRE-based
     data. 
 
     
 
     Regards,
 
     Frans

Received on Monday, 23 December 2013 15:33:48 UTC