The following issue against capability representing_parts
has now been closed, since I received no further comments to help me understand
why the current solution would not suffice. IMHO, the issue needs no further
changes.
Issue: RBN-9 by
Rob Bodington (05-01-13) minor_technical issue
Resolution: Accept. Status: open
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.
Comment: (Tim Turner Dec 13th 2006)
Comment: (Tim Turner Dec 13th 2006)
A where rule in the EXPRESS requires the use of product_cateogry. This was
intended both for part categorisation and assembly/detail information. The
latter is useful within exchange sceanrios when a complete
assembly/decomposition view of the product is not available - just the part.
Resolution: The value of product_category.name attribute shall be 'part' (Note:
lowercase is mandatory). The base reference data for instances of Part using
External_class shall be "part_category" for which sub classes can
specify different types of parts. In order to infer whether the part is itself
decomposable, or a component within a larger assembly, we either need to split
the base reference data "part_category" into
"part_assembly_category" and "part_detail_category", so
that all classifications shall fall into one or other categories; Or, alternatively,
we can recommend a second, additional classification which provides the same
level of information but is separate from the sub-classification hierarchy. I
favour the use of a second, independant classification. This allows us to
deprecate the use of product_category_hierarchy entity By default, I recommend
that every Part is inferred to be a detailed, individual part that is not part
of any defined assembly structure or defined decomposable structure. Where this
is not the case, and in addition to the mandatory instance of product_category
('part'), the product_category should be classified using External_class -
which shall be set to "assembly".
Comment: (Tim Turner Aug 16th 2005)
Resolution: Correspondance:- -----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
Comment: (Peter Bergström 2007-03-28)
I have been editing the representing_parts capability, and made a lot of
changes. Most of these are (I hope) not significant for what the capability
specifies, but more in line with updating it with the development of DEXlib
over the years – templates and so on. However, I did not include anything
about a part being identified as an “assembly” or
“detail”.
I have tried to catch up with previous discussions in this matter, and I think
what I have done now boil down to the fact that if you see a part that is not a
parent (through Next_assembly_usage), you treat it as “detail”
until you find a Next_assembly_usage that relates to it as
“relating”, and then you change your mind. I have asked the people
I have contact with, and none of them see any need to know whether a Part is an
assembly or a detail until you start building structures, and then it is
obvious. And even if you don’t have the constituents of a Part that is
really an assembly, what good does it make to you to know that somewhere else
an assembly ought to exist for this part, but I don’t have it? Therefore,
I kind of have avoided the entire discussion, and it seems to work.
I just wanted you to look at this specifically, since you (as far as I can see)
is the one that have advocated the need for this categorization of parts the
most. Is this categorization really something that we must have? What happens
if we just ignore it, and assume that all parst are details until we find out
the contrary? There is still an open issue regarding this, and I would like to
close it, so if there is such a real need somewhere, I would like to understand
that now by an example.
Peter Bergström