Re: LOCN and DGGS

Frans,

The US Government uses text isomorphs of 9 digit numbers extensively.

When assigned "at random" they are recognized as identifiers for conceptual purposes:

Social Security Purposes : DDD-DD-DDDD    (Government Benefits for persons)
Zip Code + 4 (route)         : DDDDD-DDDD     (Location - Address)
Tax* (EIN)                      : DDDDDDDDD       (zero filled)
Place (area)                    : DDDDDDDDD       (zero filled also called Feature Name <=> Feature_ID)
Long Distance Telephony : The Phone Numbers in North America are a Harmonized Format with 3 digit Area Code and 3 Digit Exchange Number and 4 digit Route.  This is a legacy of Mechanical Telephony switches prior to the invention of digital computers. 

* Tax Exempt Organizations (Charities, etc.) are distributed sorted by EIN. The file includes a Zip Code +4.  This parameter is independently arrived at and not related to EIN.  There is no telephone number given, which would constitute a third identifier value for triangulation.

Think as you may about Americans - we are file clerks of metaphysical competence.

I like to think we got this from Einstein who as you probably know had a day job at the Swiss Patent Office :)

I fear however we got it from Einstein's irreverent colleague ...
"Any one who considers arithmetical methods of producing random digits is, of course, in a state of sin."  -- John von Neumann (J. von Neumann was Jewish, precisely why he chose the term "state of sin".  It was a warning to his fellow Mathematicians to stay away from Technocratic Governance .)

--Gannon
                  
--------------------------------------------
On Tue, 11/22/16, Frans Knibbe <frans.knibbe@geodan.nl> wrote:

 Subject: Re: LOCN and DGGS
 To: "Andrea Perego" <andrea.perego@jrc.ec.europa.eu>
 Cc: "public-locadd@w3.org Mailing list" <public-locadd@w3.org>
 Date: Tuesday, November 22, 2016, 9:05 AM
 
 Hi
 Andrea,
 I wonder if a DGGS
 code should be regarded as an identifier. I would say its
 primary purpose is not to identify something, but to tell
 where something is located. It seems to me that as a
 specification of location, it is something akin to geometry
 or address. LOCN has special classes for those two. So if
 indeed a DGGS code is a specification of location, could or
 should an extension of LOCN be made to accommodate DGGS? Or
 could it be sufficient to say that a resource is a
 locn:Location and therefore any rdfs:seeAlso properties
 could be DGGS codes? That would require the DGGS reference
 to be a single URI, and it would require a certain amount of
 reasoning for the consumer. 
 Regards,Frans
 
 
 
 On 18 November 2016 at
 18:42, Andrea Perego <andrea.perego@jrc.ec.europa.eu>
 wrote:
 Hi,
 Frans.
 
 
 
 Just for our records: The notion of "geographic
 identifier" and the use of rdfs:seeAlso in LOCN was
 thoroughly discussed back in 2014, in a long thread -
 starting at [1] and continuing at [2]. Basically, the point
 is that "geographic identifier" is meant to model
 alternative / secondary identifiers for a spatial thing,
 that are preferably specified with HTTP URIs - for a more
 detailed explanation, see [1] and then [3].
 
 
 
 Coming to the issue you raise, Frans, I see it as a more
 general one on how identifiers (not only geo ones) are
 modelled in the RDF world.
 
 
 
 As far as I know, there is currently no consistent practice.
 One of the solutions is to define specific properties - as
 in Schema.org, or PRISM and the Bibo ontology in the
 publishing domain. On the other hand, ADMS provides a more
 generic approach via adms:identifier / adms:Identifier.
 
 
 
 IMHO, the point is what you want to use the identifier for.
 For instance, if I use DGGS just for specifying the location
 of a resource you can use it with locn:location /
 rdfs:seeAlso. Another case is whether, you want to know the
 identifier "type" - e.g., for a publication, I may
 need to know which is the DOI, ISBN, etc.
 
 
 
 Andrea
 
 
 
 ----
 
 [1]https://lists.w3.org/Archiv
 es/Public/public-locadd/2013De c/0043.html
 
 [2]https://lists.w3.org/Archiv
 es/Public/public-locadd/2014Ja n/0008.html
 
 [1]https://lists.w3.org/Archiv
 es/Public/public-locadd/2014Ja n/0076.html
 
 
 
 
 
 On 18/11/2016 17:09, Frans Knibbe wrote:
 
 
 Hello,
 
 
 
 A while ago we had a thread about Open Location Code
 
 <https://lists.w3.org/Archives
 /Public/public-locadd/2015Aug/ 0000.html>,
 
 which is an example of a Discrete Global Grid System
 (DGGS)
 
 <https://en.wikipedia.org/wiki
 /Discrete_Global_Grid>. There is an OGC
 
 Standards Working Group dedicated to the topic, the DGGS
 SWG
 
 <http://www.opengeospatial.org
 /projects/groups/dggsswg>.
 
 
 
 I wonder if the Location Core Vocabulary is already equipped
 to work
 
 with DGGS references. It is imaginable that people will want
 to use a
 
 DGGS code to identify a location, perhaps as the only way to
 locate a
 
 thing on Earth. Could such a code be expressed with LOCN?
 
 
 
 The most appropriate property for doing that seems to be the
 geographic
 
 identifier <https://www.w3.org/ns/locn#rd
 fs:seeAlso>, for which
 
 rdfs:seeAlso is taken to be the appropriate term. So would
 rdfs:seeAlso
 
 be a good way to refer to a DGGS location? Two questions
 come to mind:
 
 
 
  1. I have not studied all DGGS, but in the general case I
 think a DGGS
 
     reference consists of a code and an indication of a
 DGGS scheme,
 
     which is needed to decipher the code. Does that mean a
 DGGS
 
     reference needs two semantic elements? Or is it all
 right to assume
 
     that all DGGS references can always be expressed as a
 single URI
 
     (e.g. https://map.what3words.com/mon
 orail.section.trespass
 
     <https://map.what3words.com/mo
 norail.section.trespass>)?
 
  2. Will it be obvious to agents looking voor location data
 that
 
     rdf:seeAlso can be used for an indication of location?
 I mean,
 
     rdfs:seeAlso is also used for other types of relations
 (I realise
 
     that this is actually not only about DGGS, but about
 the
 
     discoverability of location information in general,
 where an
 
     unspecific term like rdfs:seeAlso is used).
 
 
 
 So what do you think?
 
 
 
 Greetings,
 
 Frans
 
 
 
 
 
 
 
 
 -- 
 
 Andrea Perego, Ph.D.
 
 Scientific / Technical Project Officer
 
 European Commission DG JRC
 
 Directorate B - Growth and Innovation
 
 Unit B6 - Digital Economy
 
 Via E. Fermi, 2749 - TP 262
 
 21027 Ispra VA, Italy
 
 
 
 https://ec.europa.eu/jrc/
 
 
 
 ----
 
 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, 22 November 2016 18:37:01 UTC