[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 ^ ^
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]