RE: [plcs] Workshop #2 - Synchronise work on DEXs and reference data between PLCS pilots and OASIS/PLCS

["John Dunford" <esukpc15@gotadsl.co.uk>]

Title: Message

Tim, the problem that Tor refers to is the opposite of the one you cite.  He is not facing an application which uses its own, special, identifiers for a part.  He is facing one where the NSN has been mis-used for this purpose.  This is OK if everyone know this is what has been done (as the host system users probably do), but it could cause significant problems, in a wider context, if the practice is spread (by a PLCS DEX) to a broader community.

 

I suspect we will encounter many such examples of "id confusion" in current systems  (not least in SSDD and UMMS, where I suspect the famous ACCREF Number means different things to different people).

 

So, how should PLCS handle this?   If we are all agreed that NSN's should be recorded by PLCS as identifiers of classes of resource_items (and it seems we are), how should we deal with the mapping when a particular application uses an NSN to identify a product_as_realized?  Should the DEX translator auto generate a new unique id for the p_a_r, and relate the NSN to the p_a_r, as the id of the associated resource_item; or is there another way of handling this?

 

Forgive me if I'm am treading ground already resolved, but I suspect "id confusion" may well be the biggest problem that PLCS implementers will face, and a consistent, well document approach will be needed.

 

John Dunford,

Eurostep Limited,

25, Chaucer Road, BATH BA2 4QX, UK

Tel: +44 1225 789347

Mobile: +44 0797 491 8202

www.eurostep.com

www.share-a-space.com

 

-----Original Message-----
From: Tim King [mailto:tmk@lsc.co.uk]
Sent: 20 October 2004 10:09
To: 'torirgen@eunet.no'
Cc: 'john.dunford@eurostep.com'; trine.hansen@dnv.com; plcs@lists.oasis-open.org; leif.tonning@dnv.com; Leif Gyllström
Subject: RE: [plcs] Workshop #2 - Synchronise work on DEXs and reference data between PLCS pilots and OASIS/PLCS

Yes.  But the example you give just means that for the initial allocation of the NSN there is a one-to-one correspondence.  If someone else finds a new use for the form, fit and function that the part_version embodies then the NSN is the common link across those different applications and potentially eventual different manufacturings.  In principle, the NSN only enables supply rationalisation but can not really force people not to find a way to distinguish their own designs from others.

Cheers,
Tim.

-----Original Message-----
From: torirgen@eunet.no [mailto:torirgen@eunet.no]
Sent: 19 October 2004 09:44
To: Tim King
Cc: 'john.dunford@eurostep.com'; trine.hansen@dnv.com;
plcs@lists.oasis-open.org; leif.tonning@dnv.com; Leif Gyllström
Subject: RE: [plcs] Workshop #2 - Synchronise work on DEXs and reference
data between PLCS pilots and OASIS/PLCS

John,
Well in the case of the Norwegian Frigates the NSN applies sometimes to
part_version, and even worse the part_version only apply to ONE ship...
but in principle I tend to agree with you.

Best regards,
Tor Arne

> I completely support John's comments.  We reviewed this at Seattle and
> when
> I have time, I should be writing this up ... ideally as a capability.
>
> Cheers,
> Tim.
>
> -----Original Message-----
> From: John Dunford [mailto:esukpc15@gotadsl.co.uk]
> Sent: 18 October 2004 12:02
> To: Trine.Hansen@dnv.com; plcs@lists.oasis-open.org
> Cc: Leif.Tonning@dnv.com; Leif Gyllström
> Subject: RE: [plcs] Workshop #2 - Synchronise work on DEXs and reference
> data between PLCS pilots and OASIS/PLCS
>
>
> Trine, in briefly reviewing you PowerPoint and spreadsheet I was surprised
> to see no mention of the entity Resource_item.  Apart from anything else
> this is the key to modelling NATO STOCK NUMBERS, which are identifiers of
> resource_items.  The whole Class, Group, Item structure is one set of
> ready
> made Reference Data, applicable to this entity.  The NATO RD should not be
> applied to part_version, because an NSN may be satisfied by any number of
> part_versions from different suppliers.
>
> Indeed the resource_item/managed_resource area probably deserve more
> attention from the DEX community than it has so far received.  These
> concepts were specifically designed to provide somewhere to hold the large
> set of information which applies to items within an Inventory/Stock
> management environment, and not to a specific part_version, and I am sure
> you'll find plenty of this across the NDLO!
>
> John Dunford,
> Eurostep Limited,
> 25, Chaucer Road, BATH BA2 4QX, UK
> Tel: +44 1225 789347
> Mobile: +44 0797 491 8202
> www.eurostep.com
> www.share-a-space.com
>
> -----Original Message-----
> From: Trine.Hansen@dnv.com [mailto:Trine.Hansen@dnv.com]
> Sent: 15 October 2004 18:03
> To: plcs@lists.oasis-open.org
> Cc: Leif.Tonning@dnv.com
> Subject: [plcs] Workshop #2 - Synchronise work on DEXs and reference data
> between PLCS pilots and OASIS/PLCS
>
>
> All.
> Please find attached
> (1) An updated figure of the proposed example "business concept" that will
> be used in the planned workshops and
> (2) Spreadsheet with draft input to the reference data discussions.
> The attached spreadsheet is a draft input to the reference data
> discussions.
> Column A, E, F and H refer to instantiation diagrams and capabilities
> produced in the Norwegian pilot and should only be viewed as references
> only.
>
>
> <<Business concept v2.ppt>> <<equipment&part_values.xls>>
> Regards
> Trine Hansen
> UCTNO940, Information Quality Management
> Det Norske Veritas AS
> ( + 47 67 57 96 38 (office)
> ( + 47 90 83 44 24 (mobile)
> * trine.hansen@dnv.com
> http://www.dnv.com
>
>
> **************************************************************
> Neither the confidentiality nor the integrity of this message can be
> guaranteed following transmission on the Internet.
> All messages sent to a DNV email addressee are swept by Sybari Antigen for
> the presence of computer viruses.
> DNV acknowledges that SPAM email represents a potential security risk, and
> DNVs filters to block unwanted emails are therefore continuously adjusted.
> DNV has disabled "out of office" replies to the Internet
> **************************************************************
>
>
> 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
>
>
>

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