I’m tempted to advocate removing the
rule all together.
The point of Part is to “semantically”
separate it from other sub types of product such as Requirement.
At the ARM level I don’t see why
there has to be a product category that is ‘Part’
I can live with Tom’s suggestion
though as it probably less contentious.
So, perhaps we do need product category in
the capability.
We should make it clear the categories are
in the Reference Data, i.e. there is one category “Part” that is
classified. The RDL will contain all other classes of Part.
-----Original Message-----
From: Hendrix, Thomas E
[mailto:thomas.e.hendrix@boeing.com]
Sent: 23 March 2004 00:53
To: tjt@lsc.co.uk;
PLCS-MODELERS-L@ATICORP.ORG; plcs-dex@lists.oasis-open.org
Subject: [plcs-dex] RE: Parts
& categories
This module is a child of the shotgun
wedding between AP214 and PDM schema UG. Best not to read the fine print in the
vows.
I think an issue should be written to
modify the WR thus:
WR1: The Part shall belong to exactly one
Product_category that is not a related to another as subcategory, and it
shall be named 'part'
This is consistent with the PDM schema UG
Revsion 4.3 1.1.3.1. You could just remove the rule, but then, what would
be the purpose of Part?.
non-countable material, raw
material, detail, passembly, standard par
ts, are then modeled as subcategories,
using Product_category_relationship.
Anything else can be a product. This
will not please AP214 which seems to permit raw material as a top category
of product, but then you cant please everyone ;-)
Regards,
Tom
Thomas E. Hendrix
Phone: 206-544-5276
thomas.e.hendrix@boeing.com
-----Original
Message-----
From: tim turner [mailto:timturner11@BELLSOUTH.NET]
Sent: Monday, March 22, 2004 1:50
PM
To: PLCS-MODELERS-L@ATICORP.ORG
Subject: Re: Parts &
categories
I think we have been ignoring a where Rule
attached to the Part entity which states
"WR1: The Part shall belong to a product category
named 'part' or to a product category named 'raw material'."
ENTITY Part
SUBTYPE OF (Product);
WHERE
WR1: SIZEOF(['part', 'raw material']*types_of_product(SELF))=1;
END_ENTITY;
Note, the
types_of_product is a function that verifies the existence of an instance of
product_category_assignment that relates the Part to a product_category
whose name attribute is equal to either 'part' or 'raw material'.
The notes for the module also state that
"If the Part represents a non-countable material that is used as a
component in an assembly, the Part
shall be, in addition, referred to by a Product_category_assignment and the
associated category shall have the name 'non-countable material'."
In the light of this, I observe 2 things;
a) there is no choice regarding the use of
product_category, so it may as well be brought in here as it currently is.
b) the term 'non-countable material'
probably needs to be added to the rule in the express & should therefore be
logged as an issue.
Hence, I intend to leave Product_category
within the representing_parts capability.
-----Original Message-----
From: PLCS Team Data Model Group
Exploder [mailto:PLCS-MODELERS-L@ATICORP.ORG]On
Behalf Of tim turner
Sent: 22 March 2004 13:46
To: PLCS-MODELERS-L@ATICORP.ORG
Subject: Re: Parts &
categories
I guess that it might be possible that it
may not be used by every Dex, or that another entity is added to the schema
& hence the size of a capability (& Dex) may increase (by 2
entities); but this is a moot point since PLCS will mean an explosion of
instance data anyhow...
Is not the real question whether this entity
is required to uniquely represent the Part concerned?
I have seen product_category used in other
capabilities and it is on the list of entities to be covered by this Dex (as
was setup originally)...
In the PDM schema it is an
optional requirement. However, in PLCS the same could be represented
through an instance of Classification_assignment, which would serve the same
purpose and require less entities to do it (since this is already being
used elsewhere by every Dex).
Is there a view on this from anyone? In
modelling terms the difference is that a Product_category can only be
assigned to a Product, whereas a Class can be assigned to many other entities
in addition to a Product.
-----Original Message-----
From: Rob Bodington
[mailto:rob.bodington@eurostep.com]
Sent: 22 March 2004 12:03
To: tjt@lsc.co.uk;
PLCS-MODELERS-L@ATICORP.ORG; plcs-dex@lists.oasis-open.org
Subject: RE: Parts &
categories
Hi Tim
I think that we discussed this in Bristol
and I think that the reason was that we were trying to limit the size of the
capabilities.
In this instance, I think the view was that
not every DEX would want the categorization of a Part.
-----Original Message-----
From: tim turner
[mailto:timturner11@bellsouth.net]
Sent: 22 March 2004 16:03
To: rob.bodington@eurostep.com;
PLCS-MODELERS-L@ATICORP.ORG
Subject: RE: Parts &
categories
Can you remind me why you think we need to
move it & create a new capability?
-----Original Message-----
From: PLCS Team Data Model Group
Exploder [mailto:PLCS-MODELERS-L@ATICORP.ORG]On
Behalf Of Rob Bodington
Sent: 22 March 2004 10:17
To: PLCS-MODELERS-L@ATICORP.ORG
Subject: Re: Parts &
categories
Hi Tim
I presume that it will be another
capability.
Does everyone else agree with the comment?
-----Original Message-----
From: tim turner
[mailto:timturner11@bellsouth.net]
Sent: 22 March 2004 14:28
To: rob.bodington@eurostep.com;
Tim Turner (E-mail)
Cc: plcs-dex@lists.oasis-open.org
Subject: Parts & categories
in one of your issues on the
representing_parts capability, you suggest removing product_category &
placing into another capability. Are you suggesting that we use something in
it's place or moving & referencing it from another? Which capability do you
suggest we move it to?
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
|