RE: [ciq] Identifiers in CIQ schemes

[Max Voskob <max.voskob@paradise.net.nz>]

 I started some work on the test cases back in 2004, but then stopped due to a lack of support and
information.

UPU provides only very simple addresses for all countries. If we followed that then xNAL would have
~ 10 elements at most.

I also attempted to write requirements for xNAL, but there was not much of a discussion around them.

I fully support the idea that a standard should be fit for the purpose and should not go beyond that
to keep it all simple.

Addresses have many various usage scenarios. Those scenarios require different level of
detailisation and presentation.
It would be good to formalise the scenarios and then try to compile a diverse set of test addresses
from all over the world.

Cheers,
Max



-----Original Message-----
From: Fulton Wilcox [mailto:fulton.wilcox@coltsnecksolutions.com] 
Sent: Saturday, 12 February 2005 07:52
To: 'John D. Putman'; 'David Webber (XML)'; colin.wallis@ssc.govt.nz
Cc: 'Max Voskob'; ciq@lists.oasis-open.org
Subject: RE: [ciq] Identifiers in CIQ schemes

All:

Are there formal "use cases" to do scenario-testing of CIQ's products?

Success is "fitness for intended purpose(s)" - i.e., that the XML artifacts defined, if properly
populated with payload content, meet the envisioned needs. 

As an observer, I recall several use cases being cited - feeding appropriate data to postal
delivery, similarly feeding private delivery routing processes (such as Fedex or freight common
carrier) and supporting marketing and other demographic studies. Previously, I injected the notion -
not exactly a use case - that there be a realistic integration scenario with ERP's such as SAP and
other business systems.

Are you already at the point of success with respect to those use case scenarios?


                                   Fulton Wilcox
                                   Colts Neck Solutions LLC
                                   

-----Original Message-----
From: John D. Putman [mailto:jdputman@scanningtech.fedex.com]
Sent: Friday, February 11, 2005 1:25 PM
To: David Webber (XML); John D. Putman;
fulton.wilcox@coltsnecksolutions.com; colin.wallis@ssc.govt.nz
Cc: 'Max Voskob'; ciq@lists.oasis-open.org
Subject: RE: [ciq] Identifiers in CIQ schemes

I will only say that we have and are "trying it" and have and are finding that the conjunction of
address and geocodes is better than assuming that geocode provides a unique key and "good enough"
location identifier.  But that IS due to our paramount needs (for various operational and customer
service purposes) to not falsely or imprecisely identify a location - to either our couriers OR
customers.  If one doesn't have such stringent needs, then you are probably right.

Thank you,
David Putman

-----Original Message-----
From: David Webber (XML) [mailto:david@drrw.info]
Sent: Friday, February 11, 2005 12:16 PM
To: John D. Putman; fulton.wilcox@coltsnecksolutions.com;
colin.wallis@ssc.govt.nz
Cc: 'Max Voskob'; ciq@lists.oasis-open.org
Subject: Re: [ciq] Identifiers in CIQ schemes

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


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.