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

Thanks, Frans,

I would be interesting to see if other use cases exist, besides INSPIRE,
motivating the definition of a specific class in the LOCN voc for
geographical names / named places. In any case, it may be worth
investigating possible re-use of work carried out in other groups (as the
Places [1] and the BPMLOD [2] CGs).

Another issue that may be of interest is how to define the "context" of a
geographical name - if I understood correctly, Gannon, your considerations
are about this. Besides temporal evolution, another use case is about,
e.g., the inconsistent use of geographical names in public administrations
- local, regional and national administrations may denote different regions
with the same geographical name, and this may also happen in different
sectors. Probably the PROV ontology can help here.

Andrea

----
[1]http://www.w3.org/community/places/
[2]http://www.w3.org/community/bpmlod/


On Mon, Dec 23, 2013 at 4:30 PM, Gannon Dick <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> 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
>
>
>
>
>


-- 
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.