Re: [ciq] Identifiers in CIQ schemes

["David Webber \(XML\)" <david@drrw.info>]

John,

No doubt!  I never said it was perfect ; -)

But is it close enough for government work, mostly?

And - more to the point - seems to be about the
only alternative right now...

That's why I was suggesting the GPS+five - since
then you have a way of avoiding the same GPS
referencing 2,000 occupants of some high-rise
tower block!  But the GPS on its own should
get you outside the twin towers - then you can use
the +five bit to figure out which tower - and which
floor, etc.

DW

----- Original Message ----- 
From: "John D. Putman" <jdputman@scanningtech.fedex.com>
To: "David Webber (XML)" <david@drrw.info>;
<fulton.wilcox@coltsnecksolutions.com>; <colin.wallis@ssc.govt.nz>
Cc: "'Max Voskob'" <max.voskob@paradise.net.nz>; <ciq@lists.oasis-open.org>
Sent: Friday, February 11, 2005 11:36 AM
Subject: RE: [ciq] Identifiers in CIQ schemes


> Unfortunately, more than God is involved in GPS coordinates as mentioned
(as
> a referent for a recipient and/or address those DO change).  The below is
> extracted from an analysis done to compare addresses and geocodes (full
> analysis attached) and covers several other aspects of the actual
real-world
> imprecision of geocodes and their variability.  This makes geocode as an
id
> key susceptible to some problems and update requirements.
>
> Briefly -
>
> o Geocodes as they relate to address/location are sometimes "munges"
> ("best guess" calculations!).
>
> o Geocodes as they relate to a building, recipient, or delivery points
> for those DO REQUIRE updates!
>
> o Geocodes may not be precise enough ("munges"), OR their precision
> may not be evident to / easily applied by a user - for instance, a
delivery
> courier (not even if supplied with a GPS unit)!
>
> o Geocodes are NOT always equivalent to, do NOT always "contain" or
> "mark", or do NOT always adequately identify an address/location OR a
> recipient/customer.
>
> o Addresses can suffer similar problems -
> + No streets, only street names, or street range "munges" can
> occur in reference data.
> + Addresses and their elements are often updated.
> + Entry doors OR delivery docks to the SAME large building can
> be on multiple streets OR at non-street locations (alleys, "back lots", or
> warehouses / delivery "yards").
> + Addresses can also REQUIRE additional recipient related
> information.
> + Some postally valid addresses can be location opaque or
> NON-SPECIFIC!  AND there are some addresses that are NOT represented in
> reference data (sometimes NOT in any data!).
>
> o As a result, address and geocodes may be complementary to each
> other; BUT
> + They should NOT be viewed as either reducible to or
> "subservient" to the other.
> + Certain recipient related data may be required over and
> above BOTH geocode and address.
> + Standards bodies recognize and agree that recipient data,
> primary address data, and geocode data are EITHER separate but
complementary
> domains OR should all be considered attributes or types of ADDRESS.
> + Geocodes ARE good for "getting close" AND recognizing likely
> co-location / closeness.
> + Addresses ARE good for easily user applicable referents and
> recipient directed delivery.
> + Geocode and address complementary use IS STILL superior to
> abstract "unique" keys for a many purposes - getting to an
address/location
> chief among those.
>
> o Generally, there ARE "HOLES" in almost any schema - address and
> geocodes included, with regard to their "real world" referents and the
> schemas themselves.  These can be and ARE caused by
> + "illogical" or inconsistent "real-world" conditions /
> decisions,
> + update anomalies,
> + imprecision in identification,
> + outright mistakes,
> + actual lack of consistent or complete data.
>
> Thank you,
> David Putman
> -----Original Message-----
> From: David Webber (XML) [mailto:david@drrw.info]
> Sent: Friday, February 11, 2005 9:49 AM
> To: fulton.wilcox@coltsnecksolutions.com; colin.wallis@ssc.govt.nz
> Cc: 'Max Voskob'; ciq@lists.oasis-open.org
> Subject: Re: [ciq] Identifiers in CIQ schemes
>
> Fulton,
>
> I suggest using the GPS coordinates.
>
> Only God has control over how those get assigned...
>
> But you would have to separate the owner entity ID from
> the GPS ID - because people and companies move.
>
> And you do need a system for labelling large tall buildings
> to make the GPS + five or similar - unique to a location
> inside it!
>
> DW
>
> ----- Original Message ----- 
> From: "Fulton Wilcox" <fulton.wilcox@coltsnecksolutions.com>
> To: <colin.wallis@ssc.govt.nz>
> Cc: "'Max Voskob'" <max.voskob@paradise.net.nz>;
<ciq@lists.oasis-open.org>
> Sent: Thursday, February 10, 2005 10:15 PM
> Subject: RE: [ciq] Identifiers in CIQ schemes
>
>
> > Colin,
> >
> > Giving every address what amounts to a serial number sounds harmless
> except
> > that doing so is quite a bit of work.
> >
> > Perhaps one question to be addressed (no pun intended) is what happens
> over
> > time? In the U.S., the postal service reorganizes ZIP codes for locales
> that
> > are experiencing rapid growth. Companies buy and sell each other and
> > properties are subdivided or sometimes reunified. There are short-lived
> > addresses such as PO Boxes and "care/of" arrangements. Addresses are
> highly
> > perishable.
> >
> > To make serialization useful, would you maintain successor and
predecessor
> > tables of all these changes? How would you propagate and retire serial
> > numbers across impacted databases?
> >
> > In return for this work, what is the payback?
> >
> >
> >                                     Fulton Wilcox
> >                                     Colts Neck Solutions LLC
> >
> > -----Original Message-----
> > From: Max Voskob [mailto:max.voskob@paradise.net.nz]
> > Sent: Thursday, February 10, 2005 9:36 PM
> > To: colin.wallis@ssc.govt.nz; ciq@lists.oasis-open.org
> > Subject: RE: [ciq] Identifiers in CIQ schemes
> >
> > Hi Colin,
> >
> > In fact, NZ xNAL already has the ability to store ID for almost anything
> and
> > use IDs instead of the actual address elements.
> >
> > Shared IDs are good when there is some aurotitave source of them.
> > There is no problem in assigning an ID to an address or location or just
a
> > geographical name. The problem starts when you get the ID and want to
know
> > what it means.
> >
> > The infrastructure needed to convert addresses into IDs and vice versa
> might
> > be a show stopper.
> >
> > E.g. IDs can be sourced from LINZ BDE, but again, the infrastructure to
do
> > just that is undefined.
> >
> > Would be interesting to know what your thoughts are.
> >
> > Cheers,
> > Max
> >
> >
> > -----Original Message-----
> > From: colin.wallis@ssc.govt.nz [mailto:colin.wallis@ssc.govt.nz]
> > Sent: Friday, 11 February 2005 15:11
> > To: ciq@lists.oasis-open.org
> > Subject: [ciq] Identifiers in CIQ schemes
> >
> > Dear TC
> >
> > We have been having some debate here in NZ Government circles about the
> need
> > to develop a unique identifier for each address.  This would be in
> addition
> > to using, say, Customer ID in xCIL.  This idea is to be able to link the
> > various types of address (physical, geospatial, emergency, rural) held
in
> > government through the use of an id which all agencies can map back to
> their
> > own records.  We would also need to validate that with fields like:
> authors
> > name, last updated date and reason for update.  There are several issues
> > around this but a key one, is how we might handle it in XML address
files.
> > 1) Should we consider an address identifier for future releases?
> > 2) Should this be part of the actual xAL address file or remain outside
> it?
> >
> > What re-ignited my thinking on this was this release from W3C:
> > http://xml.coverpages.org/ni2005-02-09-a.html
> >
> >
> > To unsubscribe from this mailing list (and be removed from the roster of
> the
> > OASIS TC), go to
> >
>
http://www.oasis-open.org/apps/org/workgroup/ciq/members/leave_workgroup.php

> > .
> >
> >
> > To unsubscribe from this mailing list (and be removed from the roster of
> the OASIS TC), go to
>
http://www.oasis-open.org/apps/org/workgroup/ciq/members/leave_workgroup.php
> .
> >
> >
> >
>
>
>
> To unsubscribe from this mailing list (and be removed from the roster of
the
> OASIS TC), go to
>
http://www.oasis-open.org/apps/org/workgroup/ciq/members/leave_workgroup.php
> .
>
>