[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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" & "ABC". The issue that this raises is how to determine which one is to be used & 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
> >
> >
> *************************************************************************
> > *
> > * 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 *
> >
> >
>
>
> --
> ========================================================
> Per-Åke Ling email: per-ake.ling_AT_eurostep.com .~.
> Eurostep AB mobile: +46 709 566 490 / v \
> Vasagatan 38 http://www.eurostep.com /( _ )\
> SE-111 20 Stockholm ^ ^
>
>
> *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 *
>
>
--
========================================================
Per-Åke Ling email: per-ake.ling_AT_eurostep.com .~.
Eurostep AB mobile: +46 709 566 490 / v \
Vasagatan 38 http://www.eurostep.com /( _ )\
SE-111 20 Stockholm ^ ^
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]