[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]