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