RE: Representing_parts C002 Issue RBN-9 (the last one for C002!)

[Tim Turner <tjt@lsc.co.uk>]

Title: RE: Representing_parts C002 Issue RBN-9 (the last one for C002!)

A slight correction to my earlier response:-

the line after item b) should read...

"The latter fact is established through an additional product_related_product_category & related to the first through a product_category_relationship entity."

Note, the product_related_product_category is a subtype of product_category having the additional attribute to relate directly to the Product/Part. In PLCS we do not have this subtype, but instead the product_category is related to the  Product/Part through the product_category_assignment. In addition, the product_category_relationship refered to above is replaced (currently) by the entity product_category_hierarchy.

Hence we may reproduce the basic information by assigning two product_category instances to the Part, one classed as 'Part_category' and the other 'Detail', or 'Assembly'.

I am not aware of any significance of the hierarchy relationship between 'part' and 'detail', other than the fact that 'part' should always the super category rather than the sub category. Currently, there is no way to establish this in PLCS unless the reference data reflects this class hierarchy. e.g. 'Detail', 'Assembly' and 'Standard' (from PDM Schema Usage Guide) should all be subclasses of 'Part_category'.

Comments on this approach?

regards,
Tim

 -----Original Message-----
From:   Tim Turner 
Sent:   16 August 2005 15:35
To:     DEXS-PLCS-OASIS (E-mail)
Subject:        Representing_parts C002 Issue RBN-9 (the last one for C002!)

In the interest of visibility my response & comments to the issue are provided below;

Issue: RBN-9 by Rob Bodington (05-01-13) minor_technical issue

The capability should emphasize that product_category is only used to distinguish between the different subtypes of Product defined in AP239. and that the value of product_category should be 'part' in this capability. More specific types of products, such as Oil filter as a type of Part should be specified by means of Classification_assignment, thus allowing the use of a class library via External_class. The External_class is "part_category" for which there are sub classes specifying "Oil filters" etc. Given the use of an external class library for the representation of product categorization, there is no role for the product_category_hierarchy entity and it should be removed from the capability.

Editor's Response: Product_category is required by the model for compatibility with the PDM schema. I have no problem in removing product_category_hierarchy from the model, nor using the External_class to represent "part_category" or sub classes thereof, provided I can ascertain the same level of information without them.

I would like to point out (IMHO) that the accepted practice in the use of Product_category has been to;
a) categorise an item to be a 'part' - which is covered by the discussion above, but
b) to also indicate whether the part is an 'assembly' or a 'detail' (i.e. not having parts of it's own).
The latter fact is established through an additional Product_category & related to the first through the product_category_hierarchy relationship.

In order to achieve the same level of information, we either have to *assume* that this will be specified explicitly using an assembly structure, or we need to add a second classification to indicate this fact.

We should like to know whether a part is actually an assembly itself, or a single piece part, without recourse to the full explicit representation of the assembly model (if present or provided).

Else (IMHO) we have to create some guidance to state that a part is always to be regarded as a single piece-part (detail) unless there is an assembly model defined for it (in which case it ceases to be a single part). My point is that we may not always have the assembly model of a part.

Comments?

regards,
Tim




*************************************************************************
*
* Mr. Timothy J. Turner BSC(Hons) MSc, MBCS
* Executive Consultant, Enterprise Integration Technologies
* LSC Group, Lincoln House, Wellington Crescent, Fradley Park, LICHFIELD, Staffordshire WS13 8RZ, ENGLAND
* UK Switchboard: +44-1543 446800 Fax: +44-1543 446900
* US Direct telephone: +1-803-327 2829 (Rock Hill)
* Mobile (US) telephone: +1-843-4759179
* Mobile (UK) telephone: +44-7885-393225
* e-mail: tjt@lsc.co.uk <mailto:tjt@lsc.co.uk> Internet: <http://www.lsc.co.uk/>
*
*************************************************************************

DISCLAIMER: ***SECURITY LABEL: NOT PROTECTIVELY MARKED***   The information in this message is confidential and may be legally privileged. It is intended solely for the addressee.  Access to this message by anyone else is unauthorised.  If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful.  Please immediately contact the sender if you have received this message in error. This e-mail originates from LSC Group. Registered in England & Wales No 2275471 Registered Office: Devonport Royal Dockyard, Devonport, Plymouth, PL1 4SG