-----Original
Message-----
From: Rob Bodington
[mailto:rob.bodington@eurostep.com]
Sent: 26 October 2004 12:24
To: 'Tim King';
john.dunford@eurostep.com; torirgen@eunet.no
Cc: 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
I sort of agree with you Tim. However, I am
considering writing a global rule (a heretic statement I know) that forces a
product_as_realised to have an identification_assignment to carry the serial
number. I was also considering a rule to force the assignment of an organiztion
assignment to to the identification assignment.
-----Original Message-----
From: Tim King
[mailto:tmk@lsc.co.uk]
Sent: 26 October 2004 11:11
To: 'john.dunford@eurostep.com';
torirgen@eunet.no
Cc: trine.hansen@dnv.com; plcs@lists.oasis-open.org;
leif.tonning@dnv.com; 'Leif Gyllström'; 'Rob Bodington'
Subject: RE: [plcs] Workshop #2 -
Synchronise work on DEXs and reference data between PLCS pilots and OASIS/PLCS
Dear
John,
This
business practice is not an issue for the PLCS model because we just map things
where they should go (i.e. the NSN is mapped to the Identification_assignment
for the Resource_item). We do not need to autogenerate anything.
The Product_as_realized instance stands in its own right and needs no Identification_assignment
(i.e. there is no serial number to distinguish). If the legacy systems
requires the "identifier" then one can trace back through to the
Resource_item that applies and find the NSN there. This means "we do
not have a serial number for this part of the realised ship but we know it is
on there (never needing tracking) and we are using the NSN as a proxy
identifier". (Of course, I am not sure if the system has a flag to
indicate which serial numbers are real and which are NSNs - but that could be
determined by intelligent inspection.)
Cheers,
Tim.
-----Original
Message-----
From: John Dunford [mailto:esukpc15@gotadsl.co.uk]
Sent: 25 October 2004 10:49
To: 'Tim King'; torirgen@eunet.no
Cc: trine.hansen@dnv.com;
plcs@lists.oasis-open.org; leif.tonning@dnv.com; 'Leif Gyllström'; 'Rob
Bodington'
Subject: RE: [plcs] Workshop #2 -
Synchronise work on DEXs and reference data between PLCS pilots and OASIS/PLCS
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
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