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