-----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