Subject: [Geopriv] URI in civic-lo

From: Andrew Daviel <[email-masked]>
Date: Wed, 09 Nov 2005 15:56:03 -0800 (PST)

I suggested adding an (optional) informational URI to
PIDF-LO to describe elements added in
draft-thomson-revised-civic-lo-01
and was asked to provide examples and/or justification

IMO there's no point in creating a structured record for something like
civil location unless everyone agrees what the fields mean and what is
valid content for those fields. Otherwise you might just as well use
a free-text field, because you can't do computation on them. (Yes there
are many applications which can somehow extract location from
free-text addresses; they work surprisingly well given a North American
grid-based urban address, where street numbers can be mapped into
East or North distances. They don't do so well outside this space)

Thanks to Internet top-level domains we have a pretty good idea of
what are acceptable values for a country field. And given
the country, we have some idea of valid values for state/province/county
fields (though even within a country, there is some variation in
e.g. abbreviation - W. York./West Yorkshire; Alberta/AB/Alta - which may
be readily understood by the Post Office but less so by software)

draft-thomson-revised-civic-lo introduces some distinctly local
fields, such as Building, Room and Seat. The format of these cannot be
guessed outside of the application, so it would be easy to generate
syntactically correct PIDF records that are nevertheless useless because
they use the wrong field values.
For instance, I maintain a network device database to answer the question
"where is 192.168.4.56 and who owns it?". To answer this, the value for
"building" must be taken from a list (the names are not written on the
buildings, and a building I define as "MOB" may variously be referred to
as "the administration building", "the main office building", "the office
building" etc.)

So I think there should be a mechanism provided within the PIDF document
to explain the fields and possibly enumerate allowed values.

Ideally, this would be a URI to a namespace that could be used to
create or validate a PIDF record to this level of detail. I don't know XML
well enough to define this, but I would think that XML with
inheritance could be used - the descriptor for the network database
inherits an organization-wide descriptor for buildings, which in turn
inherits a city or country-wide descriptor (Canada Post puts out a text
document describing how you are supposed to write street addresses..)
etc.

Failing some kind of structured document, anything is better than nothing,
so a text document describing (to a human) the fields would help
humans create or understand the PIDF records.

It's all very well to push the problem off to the application layer, but
if there are multiple applications all hoping to use the same records,
that will lead to chaos.

Andrew Daviel
Vancouver Webpages

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 09 Nov 2005 19:14:23 -0500

I admit being confused by this comment. The civic draft defines the 
meaning of the different elements, some specific to a particular country 
(identified by the country identifier). Clearly, this is within the 
precision limitations of the English language, so this relies on people 
agreeing what a "street", say, is. I don't see the need to repeat this 
information in a protocol, although an implementation of a data input 
interface may well want to cite the document definitions.

---

From: Andrew Daviel <[email-masked]>
Date: Wed, 09 Nov 2005 17:10:47 -0800 (PST)

On Wed, 9 Nov 2005, Henning Schulzrinne wrote:

> agreeing what a "street", say, is.

I guess within each country that there are usually postal guides that
people may or may not follow. Certainly in the UK there was some variation
of things like abbreviations of county names, short forms for
towns and villages that someone from elsewhere would have a hard time
parsing. It was more in relation to the organization-specific things
like unit that there needs to be a way to define them. I think James'
suggestion to expand the XLM schema would work for this.

NENA that you refer to in dhcp-civil seems rather US-centric, maybe even
US-urban-centric, though you do discuss other jurisdictions.

I was trying to figure if my mother's old address in the UK could be
described; I think so - it would have A2,A3,LMK and ZIP. Not so sure about
my recreational property - Lot nn, Helby Island - which does not have a
postal address, or a street. Or postal service. If it did have a box
number it would be elsewhere (Bamfield). I guess you covered that with
PCNp; good ..

I recall a magazine article by someone living in the Arctic. They ordered
something online, and the web app flatly refused to accept a box number.
So they invented a "street address" like "the blue tent, snowshoe avenue".
Normally they would fly into town a few hundred miles away to pick
up mail  marked "to be called for" but could not put that in the form

-- 
Andrew Daviel