AW: Core Components aggregate Analysis

[Hermes Hartmut <Hartmut.Hermes@MCH11.siemens.de>]

	Sorry David you should have checked the EDIFACT PRODAT message type
prior to saying that there is "been a bit of a shortcoming in
	the trad EDI world, when it comes to product 'classification &
identification'". Indeed There is a very well working capability to classify
and identify products and their Characteristics. Maybe you shoul have a look
at this message type. The EWG wMsub working group Materials Management dealt
quite a long time in these issues and developped a message type which even
wirks in the provision of complexSystem's masterdate including "physical
	product/service descriptions/attributes," AS WELL AS "descriptive
latitude (which may be more of a code list-s- issue) towards allowing for
the 'market
	aspects' of a product".

Kind regards / Mit freundlichen Gruessen
Hartmut Hermes     
Siemens AG GPL GLO LE	D-80286 Muenchen     
Tel: +49 89 9221 4564     	Fax: +49 89 636 718 580
Tel: +49 8233 600 222     	Cellular phone: +49170 22 97 606  
Project Omega Information may be found at:
http://www.el.siemens.de/cgi-bin/index.pl?href=/new/logistik/geschabw/omega/
uebersicht.en.htm
If you want to get information on the Basic Semantic Register please visit:
http://forum.afnor.fr/afnor/WORK/AFNOR/GPN2/TC154WG1/index.htm

	-----Ursprüngliche Nachricht-----
	Von:	Welsh, David [SMTP:David.Welsh@nordstrom.com]
	Gesendet am:	Dienstag, 2. Januar 2001 19:09
	An:	'Bob Haugen'; ebxml-core@lists.ebxml.org
	Betreff:	RE: Core Components aggregate Analysis

	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
	>