Issue raised against: representing_parts

Comment: (Tim Turner 19th Apr 2005)
Capability 1.19 was updated with the content from version 1.17

Comment: (Tim Turner June 2004)
Accepted. Done.

Comment: (Tim Turner June 2004)
Discussed. Rejected. Category to remain.

Comment: (Rob Bodington 04-09-30)
The categorization of products should be done using reference data, not product_category. There is a ballot comment against AP239 to this affect.

Comment: (Tim Turner Oct 18th 2004)
Issue NO 23 was discussed and rejected.

Comment: (Tim Turner June 2004)
Accepted. Completely re-worded all relevant sections.

Comment: (Tim Turner June 2004)
Accepted. Processor info removed.

Comment: (Tim Turner June 2004)
Accepted. Done.

Comment: (Tim Turner June 2004)
Accepted. Done.

Comment: (Tim Turner Oct 18th 2004)
There are many things that can be assigned to a part. However, these are not part of the representation of the part itself. This should instead be handled by the capability Assigning_approvals. Such aspects were removed from the early incarnations of this model.

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.

Comment: (Peter Bergström 2007-04-13)
Closed due to no further information.

Comment: (Tim Turner Aug 16th 2005)
Resolution: Yes, the classes shall be changed accordingly. Correspondance:- -----Original Message----- From: Tim Turner Sent: 16 August 2005 13:22 To: DEXS-PLCS-OASIS (E-mail) Subject: Representing parts Issue RBN-10 In the interest of visibility My response + comments to the issue are provided below; Issue: RBN-10 by Rob Bodington (05-02-16) minor_technical issue The classes have changed in the reference data. Part_type_code is now Part_identification_code Version_code is now Version_identification_code Id_owner is now Owner_of The classes used in the capability should either be changed as above, or the reference data should be updated. Editor Response: I agree, the classes shall be changed accordingly. regards, Tim

Comment: (Tim Turner Aug 16th 2005)
Resolution: Correspondance:- -----Original Message----- From: Tim Turner Sent: 16 August 2005 16:42 To: DEXS-PLCS-OASIS (E-mail) Cc: Gordon Robb Subject: RE: [plcs-dex] Representing parts - Issue: RBN-11 Hi Gordon, are saying that version relationships (aka product_version_relationships) are not necessarily the only mechanism needed to distinguish between versions? I just want to acertain whether you are raising an issue against adding version relationships to this capability. cheers, Tim -----Original Message----- From: Gordon Robb Sent: 16 August 2005 10:08 To: 'rob.bodington@eurostep.com'; Gordon Robb; Tim Turner; 'DEXS-PLCS-OASIS (E-mail)' Subject: RE: [plcs-dex] Representing parts - Issue: RBN-11 Rob, Your 1st para requires a slight amendment "All I am saying is that we need to (and can) be able to represent/model the fact that a part version can be related to another part version. In other words I want to run a query on a database along the lines of I have Part XYZ at version 3, What are the other versions of part XYZ?" This then caters for the fact that common items for multiple customers are identified by a means of identifying the correct version for each customer. e.g. 75A450123-2001 - FAIRING = AV-8B CUM 1 thru 125 ; 75A450123-2003 - FAIRING = GR5 CUM 1 thru 23; 75A450123-2005 - FAIRING = SAV-8B CUM 1 THRU 14 75A450123-2007 - FAIRING = AV-8B CUM 126 thru 167 My query to the 'database would be "Find all versions of 75A450123................ The dash number in this case is the means of versioning the fairing. I cannot ever remember seeing any Version 1 or 2 or 3 on drawing sets associated with the Aero world It should be noted that the PLCS TD in which we are supposed to be adhering to states " product identifier" Definition A name or alphanumeric identifier, used to designate a part or assembly, of the same configuration, and to differentiate it from all other products. Note These identifiers may include a supplementary identifier used to distinguish one of several sequentially created configurations of a product from the previous configuration of the same product (i.e. revision or version). Gordon -----Original Message----- From: Rob Bodington [mailto:rob.bodington@eurostep.com] Sent: 16 August 2005 09:09 To: 'Gordon Robb'; 'Tim Turner'; 'DEXS-PLCS-OASIS (E-mail)' Subject: RE: [plcs-dex] Representing parts - Issue: RBN-11 Gordon All I am saying is that we need to (and can) be able to represent/model the fact that a part version is related to a previous part version. In other words I want to run a query on a database along the lines of I have Part XYZ at version 3, What was the previous version of part XYZ? It is common practice not to version parts, but to renumber them. Hence we need to (and can) be able to represent/model the fact that a part is derived from a previous part. This information does not necessa[Gordon Robb] B rily require assembly information. That's all. Regards Rob -----Original Message----- From: Gordon Robb [mailto:gor@lsc.co.uk] Sent: 16 August 2005 07:36 To: 'Rob.Bodington@eurostep.com'; Tim Turner; 'DEXS-PLCS-OASIS (E-mail)' Subject: RE: [plcs-dex] Representing parts - Issue: RBN-11 Rob, You have to be careful in your statement 'fact that a version of a part follows on the previous version' - there can be occasions were there is concurrently several versions of the part in production dependent on the customer base. Gordon -----Original Message----- From: Rob Bodington [mailto:rob.bodington@eurostep.com] Sent: 15 August 2005 16:16 To: 'Tim Turner'; 'DEXS-PLCS-OASIS (E-mail)' Subject: RE: [plcs-dex] Representing parts - Issue: RBN-11 I don't believe that there is an issue in using an entity in more than one capability. -----Original Message----- From: Tim Turner [mailto:tjt@lsc.co.uk] Sent: 15 August 2005 15:54 To: 'Rob.Bodington@eurostep.com'; Tim Turner; 'DEXS-PLCS-OASIS (E-mail)' Subject: RE: [plcs-dex] Representing parts - Issue: RBN-11 Fair enough. But is there an issue with using product_version_relationship within more than one capability like this? If this would be an issue, I'd propose to move the subtype as well to rep_parts, else, I'd just move the super type. regards, Tim -----Original Message----- From: Rob Bodington [mailto:rob.bodington@eurostep.com] Sent: 15 August 2005 04:25 To: 'Tim Turner'; 'DEXS-PLCS-OASIS (E-mail)' Subject: RE: [plcs-dex] Representing parts - Issue: RBN-11 My motivation for writing the comment was that I want to represent the fact that a version of a part follows on the previous version. Initially this has nothing to do with an assembly of parts - it is just about the part. Similarly if a Part is derived from another part, I want to relate the two. Again, this has nothing to do with an assembly. Hence my suggestion that these representations should be in the rep_part capability. Regards Rob -----Original Message----- From: Tim Turner [mailto:tjt@lsc.co.uk] Sent: 12 August 2005 18:35 To: DEXS-PLCS-OASIS (E-mail) Subject: [plcs-dex] Representing parts - Issue: RBN-11 In the interest of visibility My response + comments to the issue are provided below; RBN-11 by Rob Bodington (05-02-21) minor_technical issue The relationship between different version(s) should be described in this capability, not "representing_assembly_structure" (C003). The product_version_relationship should be treated in the same way as in representing product as individual, and use the same classification. I propose: Derived_version_relationship Sequential_version_relationship Hierarchical_version_relationship as defined in the PDM Schema usage guide. TJT Response: Relationships between parts, part versions and view_definitions are not currently described within Representing_parts. They are described within representing_assembly_structures as these relationships are used to define the assembly structures and how those structures might change if different versions of a part are used. However, it is possible to include product_version_relationship in this capability, but it would then exist in both. This is because supplied_part_relationship (a subtype) would + I believe should, stay within C003. Though I could be persauded. I agree with the use of the classification and the ref data derived from the PDM schema. Comments? regards, Tim

Comment: (Peter Bergström 2007-03-28)
This was already fixed.

Comment: (Tim Turner Aug 16th 2005)
Resolution: Yes, representing_parts will be harmonised with representing product as individual, and use the same classification approach. Correspondance:- -----Original Message----- From: Tim Turner Sent: 12 August 2005 12:57 To: DEXS-PLCS-OASIS (E-mail) Subject: Representing parts - Issue: RBN-12 In the interest of visibility My response + comments to the issue are provided below; Issue: RBN-12 by Rob Bodington (05-02-24) minor_technical issue Resolution: Accept. Status: open The description of the view definition context should be harmonised with representing product as individual, and use the same classification approach. TJT Response: I agree in principle. The impact is that view_definitions can only be processed on import with reference to traversing the sub/supertype hierarchy contained within the RDL. regards, Tim

Comment: (Tim Turner Aug 15th 2005)
Resolution:Yes, the part_version and Part view definition shall have an assigned id (and the relevant classification to go with it). Correspondance:- -----Original Message----- From: Tim Turner Sent: 15 August 2005 11:41 To: 'Per-Åke Ling'; Tim Turner Cc: DEXS-PLCS-OASIS (E-mail) Subject: RE: [plcs-dex] Representing parts Issue RBN-13 Per, thanks for your effort to describe this problem. The practice of dis-associating the attributes from entities in PLCS (such as .id) creates a challenge for us - especially when implementing these ideas. There are strengths and weaknesses with every approach. The example below that you sketch below indicates some ambiguity in deciphering the id of the part (since there is more than one) given a set of part_versions which all have the same org.id. The date/time stamp is of course optional. Normally (!) in an exchange file, the part_version will specify the part to which it is related (so your arrows might need to be reversed). Then the part attributes e.g. part.id can usually be determined. However, in PLCS these attributes are empty, replaced by identifiers assigned separately to the part. Your example shows two such identifiers "4711" and "ABC". The issue that this raises is how to determine which one is to be used and in which situations. The organization assigning the ids can distinguish at one level + the date/time of the assignment another. What I neglected to also point out is that the third aspect - the classification of the .id attribute also allows another level. These three aspects are meant to provide the unique identification (somebody correct me if I'm inaccurate here). Hence the classification can be used to differentiate between the ids. This solves the first problem. Likewise, the part_versions have their own .id + classification in addition to the org + poss. date. Lastly, there is also the view_definition (missing from your sketch) which is supposed to add the basis for each version specified, and has a context through which to define the domain and/or life-cycle stage (e.g., design, manufacturing). As the view_definitions also have a distinguishing id/clasifications and define a context, an implementation may code for these. Through the classifications of the ids, it is possible to navigate and expose the different views required. For example, for design we have: Identifier_code ... Version_identifier_code ... Part_type_code and we have one for assembly AssemblyVw_code ... Assembly_Vn_code ... Assembly_code (which I just made up to fit your example). However, it is the business rules or s/w dictate the application + association of the different classifications. This I think covers the other part of the problem. I have modified your sketch to show this. In the example I took the liberty to classify the second part.id as an assmebly_code + this refers to the same part as the previous one. Regards, Tim NB. C001 + C002 does explain this more consisely + fully than how I have done here perhaps. part (----------------------------+-- part_version (------------------------part_view_Definition ---) view_definition_context id: 4711 (--Part_type_code | id:v1 --Version_identifier_code id:v1 --Identifier_code domain:part design org: Cage#013 | org: Cage#013 org: Cage#013 lifecycle:design date: 2005-01-05 | date: 2005-01-07 date: 2005-01-07 +-- part_version (-----------------------part_view_Definition -----) view_definition_context id: ABC (--Assembly_code | id:v2 (--Version_identifier_code id:v1 (--Identifier_code domain:part design org: Cage#013 | org: Cage#013 org: Cage#013 lifecycle:design date: 2005-02-06 | date: 2005-03-03 date: 2005-03-03 +-- part_version (------------------------part_view_Definition -----) view_definition_context | id:v3 (--Version_identifier_code id:v1 (--Identifier_code domain:part design | org: Cage#013 org: Cage#013 lifecycle:design | date: 2005-04-02 date: 2005-04-02 +-- part_version (----------------------+-part_view_Definition ------) view_definition_context id:A2 (--Assembly_Vn_code | id:v1 (--Identifier_code domain:part design org: Cage#013 |___ org: Cage#013 lifecycle:design date: 2005-05-19 | date: 2005-04-28 id:v4 (--Version_identifier_code | org: Cage#013 | date: 2005-04-28 part_view_Definition ------------------) view_definition_context id:v1 (--AssemblyVw_code domain:part assembly org: Cage#013 lifecycle:design date: 2005-05-19 -----Original Message----- From: Per-Åke Ling [mailto:per-ake.ling@eurostep.com] Sent: 12 August 2005 16:43 To: Tim Turner Cc: DEXS-PLCS-OASIS (E-mail) Subject: Re: [plcs-dex] Representing parts Issue RBN-13 I disagree slightly (this also addresses another response from Thomas Hendrix). First of all, although the common case would be different organisations, it is fragile to establish matching between versions and parts based on org-id. Second, the date assignment is completely useless in this context since a part may be established before its versions (probably a common case). Consider: part ------------------------+---- part_version id: 4711 | id:v1 org: Cage#013 | org: Cage#013 date: 2005-01-05 | date: 2005-01-07 +---- part_version id: ABC | id: v2 org: Cage#013 | org: Cage#013 date: 2005-02-06 | date: 2005-03-03 +---- part_version | id: v3 | org: Cage#013 | date: 2005-04-02 +---- part_version id: A2 org: Cage#013 date: 2005-05-19 id: v4 org: Cage#013 date: 2005-04-28 Applying some heuristics, it would appear the A2 goes with ABC and the others (v1,v2,v3,v4) goes with 4711. However, this is founded on reasoning from the reader, and is not very amenable to codifying in rules. Note that all org-id match, and no dates match. But, based on pattern matching and the progression on dates, a reasonable guess can be produced. But, it is _only_ a guess! In real life this is not really rare, e.g. a company (same Cage-code) may produce parts which have several internal design ids as well as several visible external ids (spare parts, etc). In other areas PLCS does not trust pattern matching or heuristics (e.g. the progression of versions, which require explicit relationships), and it therefore seems odd to do it in this particular case. I still believe this is an oversight. Regards, Per-Åke Tim Turner wrote: There are other distinguishing features regarding the identification - your example simplifies it to just the id's. In fact we should have for each part, the following (where such tracking is required); part: ------------+---- part_version id: XYZ4711 orgn: SomeOrgn org_id: e.g CageCode date: 3-6-2005 | id: v1 + orgn, org_id, date | part_version +---- id: v2 + orgn, org_id, date | part_version +---- id: v3 + orgn, org_id, date With respect to other Part id's; they are either issued by the same OEM + therefore have a versioned history (i.e. relations between the versions), or they exist as multiple id's referring to the same part (e.g. re-badging a suppliers id by an assembly manufacturer. In the latter case the orgn, org_id, + date would be used to match the id's across from the part to the part_versions + vice-versa. Hence where necessary (e.g. in circumstances like you point out), we would need to refer to the full context of each identifier. This is not really an issue as far as I can see. Cheers, Tim -----Original Message----- From: Per-Åke Ling [mailto:per-ake.ling@eurostep.com] Sent: 12 August 2005 10:57 To: Tim Turner Cc: DEXS-PLCS-OASIS (E-mail) Subject: Re: [plcs-dex] Representing parts Issue RBN-13 There is a problem with the ids on part_version: Consider a part identified with XYZ4711, an three part_versions connected to it: v1, v2 and v3: part: ----------------------+---- part_version id: XYZ4711 | id: v1 | part_version +---- id: v2 | part_version +---- id: v3 However, in PLCS there is no way to relate the ids so we cannot establish which version id goes with which part id: Multiple ids: part: --------------------------- part_version id: XYZ4711 id: v1 id: ABC13 id: 1.0 id: 04517 id: A1 There is no way to show that the complete id is XYZ4711 v1, ABC13 A1, and 04517 1.0 as opposed to e.g. ABC13 v1. An obvious but annoying solution is to write the full id for the part, e.g. 'XYZ4711 v1', but it is not only redundant, it is also counterintuitive as the _part_ is XYZ411 and the _version_ is v1, not 'XYZ4711 v1'. Unfortunatey I cannot see a way around this. Regards, Per-Åke Ling Tim Turner wrote: In the interest of visibility My response + comments to the issue are provided below *Issue: RBN-13 by Rob Bodington (05-07-27) minor_technical issue* Should the part_version and Part view definition have an assigned id or should the id attribute be used? *TJT Response:* As version code identifiers for a part and their respective view definitions may also change over time we should use an assigned id. This will then be consistent with how we treat identifiers as described in C001. Any additional comments welcome. regards, Tim

Comment: (Tim Turner Aug 16th 2005)
Resolution: Yes - however, this will be a new capability being edited by Leif Gilstrom. The description attribute shall be /IGNORED when description is provided by this new capability. Correspondance:- From: Tim Turner Sent: 12 August 2005 09:30 To: 'Gyllström Leif'; Nigel Newling Cc: DEXS-PLCS-OASIS (E-mail) Subject: RE: [plcs-dex] Representing parts Issue RBN-14 Leif, I assume, given your comment, that the 'assigning_descriptor' will not make 'assigning_observation' redundant. BTW is it to be called 'assigning_descriptor' or 'assigning_description', and do you have a capability number yet? regards, Tim -----Original Message----- From: Gyllström Leif [mailto:leif.gyllstrom@aerotechtelub.se] Sent: 12 August 2005 05:13 To: Nigel Newling; DEXS-PLCS-OASIS (E-mail) Subject: SV: [plcs-dex] Representing parts Issue RBN-14 Nigel Even though there mignt be a resemblance between the two I would still argue the requirement for defining two separate capabilities. The capability 'assigning_observation' adresses the area mainly described within the AP239 module 'Observation'. The capability 'assigning_descriptor' adresses the usage (or should I say the non-usage') of description attributes for any type of entity. I.E. The capability 'assigning_observation' should use the capability 'assigning_descriptor' for the assignment of descriptive text, rather than use the Observation.description attribute (which shall be /IGNORE'ed) Regards Leif -----Ursprungligt meddelande----- Från: Nigel Newling [mailto:nfn@lsc.co.uk] Skickat: den 12 augusti 2005 11:01 Till: Gyllström Leif; DEXS-PLCS-OASIS (E-mail) Ämne: RE: [plcs-dex] Representing parts Issue RBN-14 Leif, Before we set off creating an endless series of extra Capabilities, should we not check what has already been identified as required by specific DEXs. From your description of your proposed 'assigning_descriptor', I see a significant overlap with Capability (C025): assigning_observation, which was always intended to allow the attachment of freeform notes. Can we settle on one or the other? I am leery of allowing multiple descriptions of equal status. It has the potential to create trouble when using AP239 as an integration model. Best practice is to define one as master and make the others subordinate aliases, e.g. 'also known as.. '. Nigel -----Original Message----- From: Gyllström Leif [mailto:leif.gyllstrom@aerotechtelub.se] Sent: 12 August 2005 09:24 To: Tim Turner; DEXS-PLCS-OASIS (E-mail) Subject: SV: [plcs-dex] Representing parts Issue RBN-14 All As Agreed, I'm working on the capability 'assigning_descriptor', which among other things covers the assignment ocf descriptions, notes, comments etc Regards Leif -----Ursprungligt meddelande----- Från: Tim Turner [mailto:tjt@lsc.co.uk] Skickat: den 12 augusti 2005 02:08 Till: DEXS-PLCS-OASIS (E-mail) Ämne: [plcs-dex] Representing parts Issue RBN-14 In the interest of visibility My response + comments to the issue are provided below; Issue: RBN-14 by Rob Bodington (05-07-27) minor_technical issue Should assigning_description be used to capture the parts description? TJT Response: just as a name may change over time, so might the description. In addition, multiple descriptions of the same part may be applicable. I could not find a "assigning_description" capability or entity in Dexlib/PLCS anywhere. However, there is a skeletal representing_description capability (completely undeveloped) which suggests to use "document/version and document_assignment to represent descriptions that are assigned to items such as part." I assume that the suggestion is to document the description within the document to be referenced. However, this means that the description is not available to a processor until the document is opened and the contents extracted. A document (a subtype of product) also has it's own description attribute which would require another document to describe it. A document needs a document_version and document_definition which also have a description attribute, which makes for a potentially circular + ambiguous usage. This makes me feel uncomfortable recommending or accepting this route without clearer justification. In my mind that leaves 2 options; either assigning_identification or attribute_classification. 1. The description can be specified through C001 - assigning_identification where the identification_assignment.name carries the product description, and the corresponding external_class_library.class_name is set to "Description". However, this is not so elegant a solution. 2. The description could also be specified through attribute_classification where the attribute_classification.attribute_name carries the product description, and the corresponding attribute_classification.allowed_value, which can be an instance of external_class_library - whose .class_name attribute can be set to "Description", whilst the classified_entity (a classified_attribute_select type) has products (+ most other entities) in scope. Questions for consistency purposes: 1. Is the Organization specifying the description required to be identified (according to current C001 template, the Organization assigning the name is also required to be specified)? 2. Should attribute_classification also be used to represent the name (see issue RBN-15)? 3. Aside from this, if there are multiple names + descriptions assigned (thru some means), how should should we know which is the most relevant or intended for everday use? Is there a relationship between a name and a description which should be kept together somehow? regards, Tim Note: attribute_classification has been suggested for other uses in the past but has so far (to my knowledge) still not being advocated for use in PLCS (in general).

Comment: (Tim Turner Aug 16th 2005)
Resolution: Yes, assigning_identification shall be used to assign the name to a part. Correspondance:- From: Gyllström Leif [mailto:leif.gyllstrom@aerotechtelub.se] Sent: 16 August 2005 12:22 To: Tim Turner; DEXS-PLCS-OASIS (E-mail) Subject: SV: [plcs-dex] Representing_parts C002 Issue RBN-15 All I thought that we once and for all decided that ALL names should be assigned using Identification_assignment. Leif -----Ursprungligt meddelande----- : Tim Turner [mailto:tjt@lsc.co.uk] t: den 11 augusti 2005 21:37 Till: DEXS-PLCS-OASIS (E-mail) : [plcs-dex] Representing_parts C002 Issue RBN-15 In the interest of visibility My response + comments to the issue are provided below; Issue: RBN-15 by Rob Bodington (05-07-27) minor_technical issue Should assigning_identification be used to assign the name to a part? TJT Response: just as an identifier may change over time, so might the name. The name can be specified through C001 - assigning_identification where the identification_assignment.name carries the product name, and the corresponding external_class_library.class_name should be set to "Name_identification". Questions for consistency purposes: 1. Is the Organization specifying the name required to be identified (according to current C001 template, the Organization assigning the name is also required to be specified)? 2. Should ALL other types of products in PLCS (i.e. attachment_slot, breakdown, breakdown_element, document, interface_connector, interface_specification, part, product_as_individual, requirement) also conform to this rule regarding names? 3. Any feedback? regards, Tim

Comment: (Peter Bergström 2007-03-28)
This was already fixed.

Comment: (Peter Bergström 2007-03-28)
This was already fixed.

Comment: (Peter Bergström 2007-03-28)
This was already fixed.

Comment: (Peter Bergström 2007-05-17)
Note inserted under section "Part_version".