RE: Core Components aggregate Analysis

[Bob Haugen <linkage@interaccess.com>]

<David Welsh>
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 !!
</David Welsh>

The first paragraph above is about type definitions.
The second paragraph illustrates the difference between
type and instance that I wrote about below:  the particular
container used to carry onions would not be a good choice
for new clothes, although it may be the correct container
type in terms of top, size, etc.

(Whether ebXML will get into these container constraints is
another question, but manufacturing component replenishments
often get into serial or lot numbers in shipments or returns.)

-Bob Haugen

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