[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ciq] Identifiers in CIQ schemes
Fulton,
What you describe are usage scenarios.
To me they look like "POSTAL DELIVERY" use case.
ShipTo
BillTo
SoldTo
Cheers,
Max
-----Original Message-----
From: Fulton Wilcox [mailto:fulton.wilcox@coltsnecksolutions.com]
Sent: Tuesday, 15 February 2005 04:34
To: 'Max Voskob'; ciq@lists.oasis-open.org
Subject: RE: [ciq] Identifiers in CIQ schemes
All:
All:
With respect to use cases, perhaps my little matrix below helps. Note that fleshed out "use cases"
can serve two roles: 1) to validate the CIQ design, and 2) perhaps more importantly, to set the
stage for "selling" the design of CIQ. Note that both prioritization and scientific sampling suggest
that one does not have to be exhaustive in trying every use case, but it is helpful to have a
comprehensive overview in mind.
Below I have listed down the left what I term "entities," and I expressed these in terms of the
principal customer entities in SAP R/3 (and of course these entities are found, if in somewhat
different terms, in other ERPs, so I cite SAP merely as a benchmark.).
Also, I have shown across the top a list of terms of the roles/processes in which those entities may
be the actors, the subjects, or may interact. With respect to addresses, "physical" is certainly a
high priority, because it has to do with mailing, emergency services routing, etc. However, the
others are often very important, and "workflow" is of growing importance.
Physical Logical Business Relationship
Workflow Jurisdictional
"Entities"
Sold-to
Group-to
Ship-to
Bill-to
Payer
"Quasi-entities"
Contracts
Purchase orders
Licenses
Certifications
People (attention: Sam Smith)
Legal notice addressees
Etc.
In SAP, Sold-to is the lowest level customer entity - e.g., that can hold pricing, Ship-to is the
lowest level physical customer entity (and for many situations sold to and ship to are effectively
synonym entities), group-to is a specialized sold-to entity that can hold pricing and other data
relevant to multiple sold tos, Bill-to is the customer entity that receives the invoices (and with
outsourcing common, could be in another company and another country), and Payer is the entity that
issues the payment (again perhaps outsourced). My presumption (perhaps worth testing with some
friendly SAPites) is that CIQ has the "right stuff" (and more) for suitably defining these entities
in typical uses.
Typical is of course gradually escalating in complexity. If a major company (XYZ, inc.) using SAP
R/3 internally has to implement a new major, multi-country trading relationship with, say, Toyota,
the "use case" becomes whether CIQ has the "right stuff" to serve as the overarching template for
defining "Toyota" within the supplier's information infrastructure. There are of course two further
questions, - 1) given that CIQ probably has the "right stuff," will the IT practitioners involved
recognize that fact and figure how to match CIQ to SAP and vice versa, and 2) does SAP R/3 itself
have the right stuff to accommodate the CIQ templates and data (which of course will have to be
significantly torqued to go into SAP's relational database structures). Points 2 and 3 have to do
with CIQ adoption - i.e., will practitioners even try to leverage CIQ and if so will they be
defeated by limitations of their IT vehicles?
Note that SAP's own architecture is significantly changing, but the present test is probably against
SAP R/3 "classic" (e.g. R/3 4.6c) as opposed to the new more componentized SAP's.
What I list as quasi-entities are from a CIQ aspect a mixture of physical and abstract entities. As
an example, in various jurisdictions one has to be licensed to do business and may also need special
certificates. The address to which the license pertains often need to be aligned with entities such
as sold-to-addresses. The licenses and certifications typically have both physical components (e.g.,
applying to 155 Highstreet, your town, your
country) and a legal entity component (XYZ silicon fabrication LTD).
For certain hazardous materials, the customer may have a permit that allows up to 10 kilograms of a
certain substance, and that limit may pertain to multiple ship-to's within a facility. Some
customers in part or in whole outsource tracking to the supplier, and in other contexts (vendor
managed
inventory) the supplier may need to incorporate customer entities (inventory holding points) into
the supplier's roster of "entities').
Contracts and PO's are particularly nasty use cases, primarily because the people creating them are
often entirely unaware of the difficulties they cause by their choice of entity "model" and
reference points. Therefore, pricing a transaction in conformance with a contract may require tests
based on physical, abstract (e.g., customer "business unit" or,even worse, supplier and customer
business unit) and perhaps date aspects (which might involve predicting arrival time if the price is
"when delivered").
Similarly, there are legal addresses for notices - in the U.S. that may mean sending notices of
pricing changes or whatever to some office in the State of Delaware even though neither buyer nor
sellers have any physical facilities in or even near Delaware.
CIQ clearly does not "own" all the questions and issues involved in exploiting the fruits of CIQs
labors. On the other hand, it may be that a bit of work to try out use cases will both avoid future
rework and set the stage for quicker adoption.
Fulton Wilcox
Colts Neck Solutions LLC
Colts Neck, New Jersey USA 07722
-----Original Message-----
From: Max Voskob [mailto:max.voskob@paradise.net.nz]
Sent: Sunday, February 13, 2005 9:58 PM
To: ciq@lists.oasis-open.org
Subject: RE: [ciq] Identifiers in CIQ schemes
Colin,
I think even if the usage scenarios are numerous they can be nicely generalised to 2 or 3 use cases.
1) Attending an address (postal delivery, fire engine, etc.)
2) Conversion to geocodes for further processing
3) Data matchning
Can you add any other use cases that stand out?
Cheers,
Max
-----Original Message-----
From: Colin.Wallis@ssc.govt.nz [mailto:Colin.Wallis@ssc.govt.nz]
Sent: Monday, 14 February 2005 14:57
To: max.voskob@paradise.net.nz; ciq@lists.oasis-open.org
Subject: RE: [ciq] Identifiers in CIQ schemes
Quite correct Max...
When you talk to emergency services, the local council/city hall, the courier company, the Post
Office, the land registry..they all have different needs and uses. While we could get
representative usage scenarios, they will vary from country to country. It would be a big ask to do
a 100% "one size fits all" on this. Great if we can even get close though.
Cheers
Colin
-----Original Message-----
From: Max Voskob [mailto:max.voskob@paradise.net.nz]
Sent: Saturday, 12 February 2005 8:47 a.m.
To: ciq@lists.oasis-open.org
Subject: RE: [ciq] Identifiers in CIQ schemes
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
.
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]