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

Hi Simon & Krzysztof,  You both ask the same question.  Sadly I was not gifted with excessive clarity.

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

It is not clear to me what you are trying to say. Can you explain this
in more detail?  Krzysztof
=====

Yes, Simon you would miss a lot of named places.  For an agnostic view of Cultural Heritage sites,  the low concentration of people there - named, nice or otherwise - is a tangential issue for data.

For example, Ningaloo[1] has perfectly good astronomy, weather, scenery, etc. but few people:
http://www.rustprivacy.org/2011/phase/ningaloo-au.jpg

Take-Away: A search for people is irreversible, but a search for Geographical names should not be so.

There are two facets to a "search": 1) Can you do it ? 2) Do you want to influence associative behavior of species or classes or dissociative behavior of species or classes ?

For example, Australian sharks are tagged and tweet locations when near swimming humans.  It is really quite ingenious.  The point of the mashup is to influence associative behavior (a shark's choice of meals, never mind they are always hungry).  That is the intersection point of this "Hyperquad" speciation (service) curve[2,4]. 

Take-Away: For either RDF or GNIS to be useful, you only *must* only tag one class (species).

It should be relatively simple to keep a small number of sharks away from a small number of humans in a big ocean.  The inverse, associating a large number of people with a Cultural Heritage site like Ningaloo is a matter of intention[3] not arithmetic, you are still trying to influence associative behavior.  The only tag you need reads "Ningaloo".

The math and analytical graph application are freeware[5] btw.  I have no association with these people, I just use their stuff :-)

--Gannon  

[1] The name "Ningaloo" sounds odd to America/Texas ears.  Perhaps if we spoke English ... ;-)
[2] http://www.rustprivacy.org/2011/phase/sharks.jpg
[3] http://xml.fido.gov/stratml/index.htm
[4] http://www.rustprivacy.org/2011/phase/service-curve.jpg
[5] http://www.hyperquad.co.uk/hyss.htm







--------------------------------------------
On Mon, 1/6/14, Simon.Cox@csiro.au <Simon.Cox@csiro.au> wrote:

 Subject: RE: Geographical names in locn (was: ISA Core Location Vocabulary)
 To: andrea.perego@jrc.ec.europa.eu, gannon_dick@yahoo.com
 Cc: frans.knibbe@geodan.nl, public-locadd@w3.org
 Date: Monday, January 6, 2014, 5:33 PM
 
 
 
  
  
 
 
 
 
 Ø 
 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>
 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.

Received on Tuesday, 7 January 2014 18:37:12 UTC