Party objects - code lists - metadata registries - harvesting maps

[Todd Boyle <tboyle@rosehill.net>]

Kammerer said, 
> W3C's Platform for Privacy Preferences (P3P), Section 5.3.5.1 
> (Postal) describes a simple structure for postal mailing addresses 
> for consideration in modeling ebXML's own Address core component. 

My company has considered dozens of party schemas as our native 
party schema and where we are at now, is the code/code list
object, having a code details element that describes the party
schema for a particular code version of a codelist provider.  The
codelist provider will usually be the web application provider
itself, or, the trading partner's provider.  Sadly this will require
mapping.  Costs must be recovered.  We have considered allowing users
to maintain no party natively, but instead, adopting the trading 
party's party schema natively, since we don't do much automation 
around the party. "Click here to adopt my customers' party record
schema."  Then they could view that data anytime but only in 
barebones name:value lists.  We have considered allowing users to
do the mapping from these diverse schemas to Netaccount's schema.
Netaccount would then store these valuable mapping transformations, 
and other users would never need to do that particular schema again.

Is RegRep supposed to be the central repository of metadata mapping? 
Or just a storage locker for data elements and aggregates?

The code/codelist object may be reusable in a number of other dimensions
in an accounting system, such as the product and the ledger name.  
This problem arises for every element where you need to communicate 
with 3rd parties.  You need a global namespace or codelist. 

It seems to me, the world is not about to converge around any 
particular party or product schema. Therefore the only question is
how to cheaply and efficiently store snapshots of many, diverse, 
proprietary party layouts in metadata registries, and produce 
mapping transformations.  While waiting for everybody to store 
them in UDDI or even longer for ebXML registries, we need to store 
them today.  Hopefully, to store them on sight.  You can do this 
the hard way (reinvent wheels, write text parsing codes, user 
interfaces, etc.) or implement code that recognizes the party and
address and product structures, somehow, and stores them in metadata 
registries.

It seems to me, once you accept the reality of metadata registries, 
there must be generic, open source models and software for moving
metadata from instance documents into ISO 11179 or other metadata 
registries.  Any decent perl hacker should be able to find the 
word "customer", "party", "partner" etc. at least some of the time.
If human experts can read party data from XML instance documents, 
99% of the time, then machine intelligence can too.

ISO 11179 is destiny.  Resistance is futile. Everything
will be assimilated. 
http://groups.yahoo.com/group/decentralization/message/2276

Todd

> -----Original Message-----
> From: William J. Kammerer [mailto:wkammerer@foresightcorp.com]
> Sent: Monday, April 30, 2001 11:43 AM
> To: ebXML Core
> Subject: RE: What do people really expect from ebXML? - Is CC really a
> set ofLegos?
> 
> 
> Betty Harvey bemoaned the demise of the IETF DTD VCard specification,
> since having a standard for personal information would keep you from
> having to fill in the same damn information over and over again on web
> forms.  Though VCard smacks of B2C, it does have some carryover into
> ebXML I suppose, and I just wanted to remind Betty of the W3C's Platform
> for Privacy Preferences (P3P), at http://www.w3.org/P3P/, which looks
> like a successor to VCard.
> 
> I previously brought P3P to our attention last month, at
> http://lists.ebxml.org/archives/ebxml-core/200103/msg00099.html, to show
> that its Section 5.3.5.1 (Postal) describes a simple structure for
> postal mailing addresses - for consideration in modeling ebXML's own
> Address core component.  Of course, Mike Conroy also showed other
> examples from ERP file layouts giving simple address structures.  I
> wanna know what sort of "top-down" analysis starting with the business
> model gave us the "postal address.details" aggregate shown in Initial CC
> Structure v1-03.xls. Anybody??
> 
> William J. Kammerer
> FORESIGHT Corp.
> 4950 Blazer Pkwy.
> Dublin, OH USA 43017-3305
> +1 614 791-1600
> 
> Visit FORESIGHT Corp. at http://www.foresightcorp.com/
> "accelerating time-to-trade"

> -----Original Message-----
> From: William J. Kammerer [mailto:wkammerer@foresightcorp.com]
> Sent: Monday, April 30, 2001 11:43 AM
> 
> Betty Harvey bemoaned the demise of the IETF DTD VCard specification,
> since having a standard for personal information would keep you from
> having to fill in the same damn information over and over again on web
> forms.  Though VCard smacks of B2C, it does have some carryover into
> ebXML I suppose, and I just wanted to remind Betty of the W3C's Platform
> for Privacy Preferences (P3P), at http://www.w3.org/P3P/, which looks
> like a successor to VCard.
> 
> I previously brought P3P to our attention last month, at
> http://lists.ebxml.org/archives/ebxml-core/200103/msg00099.html, to show
> that its Section 5.3.5.1 (Postal) describes a simple structure for
> postal mailing addresses - for consideration in modeling ebXML's own
> Address core component.  Of course, Mike Conroy also showed other
> examples from ERP file layouts giving simple address structures.  I
> wanna know what sort of "top-down" analysis starting with the business
> model gave us the "postal address.details" aggregate shown in Initial CC
> Structure v1-03.xls. Anybody??
> 
> William J. Kammerer
> FORESIGHT Corp.
> 4950 Blazer Pkwy.
> Dublin, OH USA 43017-3305
> +1 614 791-1600