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

Ø  a Geographic Name is not a blood line.  For interoperability, it can be defined in terms of a Population Clock[1]

I doubt if I’m following all the nuances of this discussion, but this comment (and some of the subsequent discussion) seems to imply that geographic names are somehow tied to population, or populated places only. That would miss a whole lot of named places ...  Am I over-interpreting?

Simon


On Mon, Dec 23, 2013 at 4:30 PM, Gannon Dick <gannon_dick@yahoo.com<mailto:gannon_dick@yahoo.com>> wrote:
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<mailto:frans.knibbe@geodan.nl>> wrote:

 Subject: Geographical names in locn (was:  ISA Core Location Vocabulary)
 To: "Andrea Perego" <andrea.perego@jrc.ec.europa.eu<mailto:andrea.perego@jrc.ec.europa.eu>>
 Cc: "LocAdd W3C CG Public Mailing list" <public-locadd@w3.org<mailto: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






--
Andrea Perego, Ph.D.
European Commission DG JRC
Institute for Environment & Sustainability
Unit H06 - Digital Earth & Reference Data
Via E. Fermi, 2749 - TP 262
21027 Ispra VA, Italy

DE+RD Unit: http://ies.jrc.ec.europa.eu/DE


----
The views expressed are purely those of the writer and may
not in any circumstances be regarded as stating an official
position of the European Commission.