RE: Core Components aggregate Analysis

["Welsh, David" <David.Welsh@nordstrom.com>]

Bob,
I don't know if this will help but there's been a bit of a shortcoming in
the trad EDI world, when it comes to product 'classification &
identification', that I hope will be a bit better in the ebXML world. 
Specifically there's been a good degree of attention in the past to physical
product/service descriptions/attributes, and not enuf descriptive latitude
(which may be more of a code list-s- issue) towards allowing for the 'market
aspects' of a product.

For example, for years in the container transport world there's been
discussions on the concept of container type/size codes which have largely
been literally about the combination of container type, -ex. open top or
high cube or ..-, and container size -40' or 20' or ..-. 
All the type/size codes are workable to a degree but in the operational
dispatching & planning of containers, the shipping lines tended to also have
to include the important marketing aspects of a container; ex. never send a
container which is used to regularly carry onions to a big customer carry
new clothes on a 6 week journey !!

I'm sure there's examples of this in other industries, and it sounds like
EconomicResource***** concepts are more flexible ?
Thanks
Dave Welsh


> -----Original Message-----
> From: Bob Haugen [mailto:linkage@interaccess.com]
> Sent: Tuesday, January 02, 2001 4:41 AM
> To: ebxml-core@lists.ebxml.org
> Subject: RE: Core Components aggregate Analysis
> 
> 
> A couple of comments on what I think might be the current
> core component definitions, as evidenced by the spreadsheet
> sent by Marianne Cockle with finance group comments.
> 
> I think the definition of Product/service may suffer from a common
> conceptual problem, the lumping together of product definition and
> product instance.  For example, the definition of an automobile
> model (e.g. Flapmobile Deluxe Roadster) vs a particular instance
> with a Vehicle Identification Number sold to a particular customer.
> Or the definition of a food product with a SKU vs a particular
> bunch of products on grocery shelves with Lot IDs.
> Or a flightnumber vs a seat on a particular leg of a particular trip.
> Or a room number vs a particular stay.
> 
> The BP Metamodel makes this distinction as 
> EconomicResourceType vs EconomicResource (instances of
> the type).  EconomicResource may be too abstract for
> core components, but the distinction between type and 
> instance may be necessary.  All ERP systems make the
> distinction in one way or another - the type level is often
> called "Master", e.g. "ProductMaster" vs "Inventory" or
> "Lot".
> 
> Also, I fully agree with the finance group's comment about
> differentiating Duration (a length of time) from DateTime,
> a point in time.
> 
> Respectfully,
> Bob Haugen
>