[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [plcs] The saga on "manage identification" / NSN
| *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. |
-----Original Message-----
From: Simon Dick [mailto:simon.dick@eurostep.com]
Sent: 05 November 2004 14:47
To: 'Trine.Hansen@dnv.com'; 'plcs@lists.oasis-open.org'
Cc: 'Leif.Tonning@dnv.com'
Subject: RE: [plcs] The saga on "manage identification" / NSNTrine,
See comments below. Not adding any more fuel.... just my opinion.
Regards,
Simon.
-----Original Message-----
From: Trine.Hansen@dnv.com [mailto:Trine.Hansen@dnv.com]
Sent: 05 November 2004 06:24
To: plcs@lists.oasis-open.org
Cc: Leif.Tonning@dnv.com
Subject: [plcs] The saga on "manage identification" / NSN
All.
The NDLO pilot, with their codifiying experts, recognises an NSN to be an identity for a part from a supply and maintenance point of view. However, the observation apply that the same NSN may be assigned to many different part numbers (from different vendors). [Simon Dick] agreed
The spec for the first part given the NSN may be the common spec for new parts codified to the same NSN.
Similarly, more than one NSN may play the role of resource item for a given task. [Simon Dick] Disagree - one resource item for a given task (assuming the resource item was a spare part or tool) would have one NSN - I don't know of any circumstance whereby different NSNs would meet the criteria for the same required resource item. The actual part installed in an equipment does own an NSN, however, this is not exclusive. We can from a PLCS point of view easily agree that there are benefits of assigning the NSN to the resource item, and have done so for all resources that has an NSN (including tools etc). [Simon Dick] Agreed - an NSN is one way of identifying a resource item. In short, we agree. Also, we have no problem with somebody using the NSN as a serial number, although this seems like a very special case. [Simon Dick] Disagree - there are NO circumstances in which NSNs can be used as a serial number by means of uniquely identifying an instance of a product. NSNs are a classification of items (meeting the same form, fit, function). PLCS should not promulgate the acceptability of using NSNs as serial numbers, and preferably, should refute it. The only requirement is to classify the role of this identifyer as such. The NSN may then occur twice in two different roles. Global rules. In our view, a DEX specification represents a specific business object. These objects will hold their own set of rules. Additionally, there will be a common need for rules applying to DEX'es as such. These rules probably should be global.
We do not intend to open the NSN discussion by adding more fuel. This is just to present our agreement to an issue that we were guilty of initiating.
Regards
Leif and Trine
-----Original Message-----
From: Rob Bodington [mailto:rob.bodington@eurostep.com]
Sent: 28. oktober 2004 09:12
To: 'Per-Åke Ling'; john.dunford@eurostep.com
Cc: 'Gordon Robb'; 'Tim Turner (Offsite)'; 'Tim King'; torirgen@eunet.no; Hansen, Trine; Tonning, Leif; 'Leif Gyllström'; plcs@lists.oasis-open.org
Subject: RE: [plcs] Re: The saga on "manage identification"
I agree with John that NSN numbers should be an identification of a resource item.
However, if a company is misusing NSN numbers to identify Prod_as_real, or Parts, in other words treating them internally as Part numbers or Serial numbers, then there is nothing we can do about it. What the translator must do is to export a prod_as_realised or part and identify it according to the capability "assigning identifiers"
What it should NOT do is classify the identification as an NSN number.
We have had the "unique Id" debate over and over in PLCS.
PLCS can not impose uniqueness on any identifier.
All it can do is represent the Id in the context of the organization that created it. It is up to that organization to ensure uniqueness. Consequently PLCS has been careful to adhere to the DOD Memorandum "The Department of Defence Guide to Uniquely Identifying Items, Version 1.3" dated November 25th, 2003. See (http://www.acq.osd.mil/uid) for the source. This is documented in the capability Assigning identifiers.
I will start the discussion about rules in a separate email thread
Regards
Rob
-------------------------------------------
Rob Bodington
Eurostep Limited
Web Page: http://www.eurostep.com http://www.share-a-space.com
Email: Rob.Bodington@eurostep.com
Phone: +44 (0)1454 270030
Mobile: +44 (0)7796 176 401
-----Original Message-----
From: Per-Åke Ling [mailto:per-ake.ling@eurostep.com]
Sent: 27 October 2004 19:00
To: john.dunford@eurostep.com
Cc: 'Gordon Robb'; 'Tim Turner (Offsite)'; 'Rob Bodington'; 'Tim King'; torirgen@eunet.no; trine.hansen@dnv.com; leif.tonning@dnv.com; 'Leif Gyllström'; plcs@lists.oasis-open.org
Subject: [plcs] Re: The saga on "manage identification"
Understood and completely agreed. However, there is an issue 3, raised
by Rob regarding adding a rule to enforce identification. If I
understood correctly this would be a rule at PLCS schema level, and it
was that issue I debated and was not happy with. If Rob meant adding a
rule to the capability, my apology and my reasoning is beside the point.
Regards,
Per-Åke
John Dunford wrote:
> Sorry to prolong this exciting debate (especially as I started it) but
> there are two issues here and they are getting muddled up.
>
> Issue 1 considers whether to impose uniqueness requirements on the
> "id/organisation" pair within a capability or DEX. I support this
> idea, although it will require action by the translators of some
> legacy systems to define the assigning organization, where this is
> implicit within the system itself. And no bad thing I hear you say!
>
> Issue 2 concerns the nature of the item being identified. Here my
> concern is make sure that PLCS Capabilities and DEXs establish a
> coherent approach to handling the problems caused by the misuse of
> specific identifiers - notably the NSN - within legacy systems.
>
> The solution to this problem is neatly explained by Tim's in the "Dear
> John" note below! As Tim correctly states, in PLCS, an NSN is an
> identifier of a resource_item AND OF NOTHING ELSE.
>
> Many legacy systems however, do not recognize the distinctions made by
> PLCS between resource_item, part_version, slot, and part_as_realized.
> As a result they sometimes (often?) use NSN as identifiers for any/all
> of these things. When mapping such data into a DEX, it is important
> to re-establish clear distinctions, so that any recipient can
> understand what the data in the DEX really means.
>
> It follows that NSNs should ALWAYS be recorded in DEXs as the
> identifier of a resource_item, WHETHER OR NOT THIS ENTITY IS
> RECOGNISED BY THE LEGACY SYSTEM. The entity being identified should
> be mapped into the DEXs as whatever it really is: a part, a slot, a
> realized part etc. If the entity in the legacy system is anything
> other than a resource_item, it will not have an identifier per se in
> the DEX file, unless one is generated by the translator, but it will
> be related to a resource_item, identified by the NSN.
>
> Can I please be assured that this approach is being followed,
> especially in DEX 1, 4, 7 and 8.
>
> 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: Per-Åke Ling [mailto:per-ake.ling@eurostep.com]
> Sent: 27 October 2004 10:18
> To: Gordon Robb
> Cc: Tim Turner (Offsite); Rob Bodington; john.dunford@eurostep.com; Tim
> King; torirgen@eunet.no; trine.hansen@dnv.com; leif.tonning@dnv.com;
> 'Leif Gyllström'; plcs@lists.oasis-open.org
> Subject: Re: The saga on "manage identification"
>
>
> I agree completely. The standard only states "...provide unambiguous
> identification..." without stating how this unambiguity (sic) should be
> achieved. The capability, on the other hand, does specify that the
> triplet [id,class,org] must be unique, which is where such a restriction
>
> belongs. In the future a new id capability could conceivably be
> defined
> with some alternate way of achieveing uniqueness.
>
> If I do not read this wrong it confirms my earlier longwinded
> argument, i.e. do not restrict PLCS, put the restrictions in
> DEX/capabilities.
>
> Regards,
> Per-Åke
>
> Gordon Robb wrote:
>
>>Gentlefolk
>>Isn't it time to remind ourselves of what the PLCS AP 239 definition
>>of
>>"manage identification" states
>>
>>"Manage identification
>>action to provide unambiguous identification of all elements, and
>>versions, of the product or support system to which reference needs to
>
>
>>be made, identification of interfaces between elements, the necessary
>>assembly, and other breakdowns structures, required to manage the
>>product through life and definition of the information to be held for
>>each type of product and support system element
>>
>>NOTE This activity occurs throughout the product life cycle and is
>>the basis of management of configuration change and configuration
>>status
>>accounting of a product and all constituent configuration items. The
>>purposes and benefits of this activity include:
>>
>>· determining the structure (hierarchy) of a product and the
>>organization and relationships of configuration documentation and
>>other
>>product information;
>>
>>· documentation of the performance, interface and other
>
> attributes
>
>>of a product;
>>· determination of the appropriate level of identification
>
> marking
>
>>of product and documentation;
>>· unique identification of a product or component part of a
>
> product;
>
>>· unique identification of the technical documents describing
>
> the
>
>>product;
>>· modification of identification of product and documents to
>>reflect incorporation of change;
>>· distinction between product versions;
>>· correlation of document revision level to product version;
>>· correlation of a PIF to related user or maintenance
>
> instructions
>
>>at the configuration item level."
>>
>>That definition is catered for by Capability (C001):-
>>assigning_identifiers which states in its introduction "The purpose of
>>this capability is to assign identifiers to entities within the model
>>that may be the subject of identification. There are three components
>>to identification;
>>
>> the identifier and its assignment
>> the organization that owns the identifier
>> the meaning of the identifier (e.g. serial number) as provided
>>by the classification The approach adopted here is compatible with
>>that provided in the DOD Memorandum "The Department of Defence Guide
>>to Uniquely Identifying Items, Version 1.3" dated November 25th, 2003.
>>See
>>(http://www.acq.osd.mil/uid) for the source. This memorandum applies
>
> to
>
>>high value tangible assets (such as an aircraft). However, the
>
> approach
>
>>here is much broader than the DoD approach and covers none tangible
>>assets (such as a maintenance task).
>>
>>NOTE The identifier shall be unique within the organization that
>
> owns
>
>>it.
>>
>>EXAMPLE A DUNS code or a CAGE Code is an example of an
>
> identification
>
>>that can be assigned to an organization.
>>
>>EXAMPLE A Part Number is an example of an identification that can
>
> be
>
>>assigned to the design of a Part.
>>
>>EXAMPLE A Serial Number is an example of an identification that can
>
>
>>be assigned to a physical instance of a Part (a Product_as_individual)
>>
>>The methodology of 'References to Identification_Assignment' is
>>depicted in the attachment.
>>
>>Whilst the modellers may wish to battle out their preferences I would
>>like to state that the way DEX 1 and DEX 8 are compiled (noting there
>>will be fine tuning to take place post the revision to module 1164 PAI
>
>
>>and possible 1251 Interface) meet the business requirements for
>
> managing
>
>>the id.
>>
>>The bottom line is that a serial number allocated by the 'OEM' is a
>>through life serial number that provides unambiguous identification
>
> and
>
>>traceability of the asset if required. Through configuration changes
>
> in
>
>>its life the PIF part number//section/reference number//National or
>
> NATO
>
>>stock number will change BUT the serial number remains the same.
>>
>>regards
>>
>>Gordon
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>-----Original Message-----
>>From: Per-Åke Ling [mailto:per-ake.ling@eurostep.com]
>>Sent: 26 October 2004 18:55
>>To: Tim Turner
>>Cc: Rob Bodington; john.dunford@eurostep.com; 'Tim King';
>>torirgen@eunet.no; 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
>>
>>
>>Hmmm, yes. But, it would be a headache to ensure uniqueness in the
>>model iteself, as you pointed out it should be a business issue. If
>>specified at all it should be in a DEX, not in the model. The reason
>>for this being that it is very difficult to define what constitutes
>>uniqueness, consider the following cases:
>>
>>1. same id, different organisations
>>2. same id, different effectivity
>>3. same id, different classification
>>4. same id, different context
>>...
>>
>>So, given that identification is multidimensional, what constraints
>>can the model enforce that would sit comfortably with every
>>implementation ?
>>
>>On the other hand, considering the DEX as a well defined subset and
>>restriction, it could well be that for a specific area of
>>applicability of PLCS (i.e. the DEX) a specific rule could be
>>specified enforcing some rule of uniqueness.
>>
>>To summarize, I believe that PLCS (the model) is fine as it is with
>>all its flexibility (and warts), the restrictions should instead be
>>specified in the DEX. Since probably nobody would claim conformance
>>with PLCS as a whole (a somewhat nebulous claim) this is not a
>>problem, I rather see an application claiming conformance with e.g.
>>DEX #1, #7 and #13 (or whatever). This will achieve the constraints
>>without restricting the model itelf, and thereby keeping it more
>>futureroof.
>>
>>Regards,
>>Per-Åke
>>
>>Tim Turner wrote:
>> > Per,
>> >
>> > I can see your point. The contents of the identifier is a business
>>issue,
>> > not a modelling one.
>> >
>> > However, if (are?) we responsible for enforcing
>>consistency/uniqueness in
>> > the model, then we probably need some rules. Any global rules would
>
>
>>need to
>> > be established at the capability/dex level - not the PLCS schema
>
> level.
>
>> >
>> > I think the implementors will be cursing us if we give them
>>conflicting or
>> > ambiguous requirements that can be interpreted differently
>
> resulting in
>
>> > different populations of the data - so we need to strike the right
>>balance.
>> >
>> > I think we need to ensure at least consistency in the data. The
>
> real
>
>> > question then is how restrictive do the rules need to be for this.
>
> I was
>
>> > agreeing with Rob, in suggesting that we need to ensure that there
>
> is an
>
>> > identification of the P.A.R, and (going further) that there should
>>alsways
>> > be at least one identifier that is classified as a 'serial
>>identification
>> > code' (and owned by an Org'n).
>> >
>> > Whether we go further & ensure that the content of that identifier
>
> is
>
>>unique
>> > at all (I presume within the Dex), across all P.A.R's, P.A.P's
>
> and/or
>
>>all
>> > Parts is the issue.
>> >
>> > So the next question, I hinted at earlier, is whether we as
>>developers of
>> > the model are responsible for *ensuring* uniqueness of the data, or
>
>
>>do we
>> > pass on that problem to the implementors?
>> >
>> > kind regards,
>> > Tim
>> >
>> > NB. I am not certain that this is an issue from both the
>
> integration and
>
>> > data exchange uses of plcs (but certainly from the latter).
>> >
>> >
>> >
>> > ----- Original Message -----
>> > From: "Per-Åke Ling" <Per-Ake.Ling@eurostep.com>
>> > To: "Rob Bodington" <rob.bodington@eurostep.com>
>> > Cc: "'Tim Turner'" <timturner11@bellsouth.net>;
>><john.dunford@eurostep.com>;
>> > "'Tim King'" <tmk@lsc.co.uk>; <torirgen@eunet.no>;
>><trine.hansen@dnv.com>;
>> > <plcs@lists.oasis-open.org>; <leif.tonning@dnv.com>; "'Leif
>
> Gyllström'"
>
>> > <leif.gyllstrom@aerotechtelub.se>
>> > Sent: Tuesday, October 26, 2004 12:24 PM
>> > Subject: RE: [plcs] Workshop #2 - Synchronise work on DEXs and
>
> reference
>
>> > data between PLCS pilots and OASIS/PLCS
>> >
>> >
>> >
>> >>I fail to see this as a PLCS problem. PLCS provides a mechanism for
>> >>identification, to be meaningful this should at least be qualified
>> >>by classification and an organisation claiming ownership, i.e. the
>> >>PLCS is flexible and rich enough to handle any identification
>> >>scheme.
>> >>
>> >>Whether or not NSN numbers are unique is surely a problem
>
> irrespective
>
>> >>of PLCS, i.e. the organisation assigning the numbers will have
>> >>problems regardless.
>> >>
>> >>On the other hand, I am not sure global rules are a good idea
>
> unless
>
>> >>one can ascertain that it will always be true for any conceivable
>
> use
>
>> >>of PLCS that an identification always will have an organisation
>
> (and
>
>> >>likewise for other rules). I am not happy about restricting the
>
> PLCS
>
>> >>schema this way, but a DEX (or capability) could certainly impose
>> >>such a restriction.
>> >>
>> >>Regards,
>> >>Per-Åke
>> >>
>> >>
>> >>Quoting Rob Bodington <rob.bodington@eurostep.com>:
>> >>
>> >>
>> >>>We can't stop someone using an NSN as a serial number . but
>> >>>
>> >>>If an identifier is a Serial number, then the
>
> identification_assignment
>
>> >>>should
>> >>>be classified as such.
>> >>>
>> >>>If the identifier is an NSN the identification_assignment should
>
> be
>
>> >>>classified
>> >>>as an NSN - not a serial number.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>Regards
>> >>>Rob
>> >>>
>> >>>-------------------------------------------
>> >>>Rob Bodington
>> >>>Eurostep Limited
>> >>>Web Page: <http://www.eurostep.com> http://www.eurostep.com
>> >>><http://www.share-a-space.com> http://www.share-a-space.com
>> >>>Email: Rob.Bodington@eurostep.com
>> >>>Phone: +44 (0)1454 270030
>> >>>Mobile: +44 (0)7796 176 401
>> >>>
>> >>>-----Original Message-----
>> >>>From: Tim Turner [mailto:timturner11@bellsouth.net]
>> >>>Sent: 26 October 2004 16:14
>> >>>To: Rob Bodington; john.dunford@eurostep.com; 'Tim King';
>> >>>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
>> >>>
>> >>>
>> >>>
>> >>>Y'all,
>> >>>
>> >>>
>> >>>
>> >>>I tend to agree with Rob (the heretic!) - since I also recommended
>
> the
>
>> >>>use of
>> >>>global rules to help with consistency and to enforce what is being
>> >>>described by the Dexs. What is the point of not doing what we
>> >>>preach?
>> >>>
>> >>>
>> >>>
>> >>>The validation of a serial number is not something that the model
>> >>>should enforce. However, the Dexs state what type of reference
>> >>>data
>
> should be
>
>> >>>associated with an identifier of a Product_as_realized.
>> >>>
>> >>>
>> >>>
>> >>>What worries me is the subsequent issue; that if a NSN is used in
>
> place
>
>> >>>of a
>> >>>serial number (but classified as a serial number) - is the issue
>
> of
>
>> >>>uniqueness.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>If this situation can occur once, then the same NSN may be used
>> >>>elsewhere - also as a serial number. Hence we may have two (or
>> >>>more) identical identifiers (NSN)
>> >>>both classified as serial numbers. Will this not present a bigger
>> >>>problem?
>> >>>
>> >>>
>> >>>
>> >>>regards,
>> >>>
>> >>>Tim
>> >>>
>> >>>----- Original Message -----
>> >>>
>> >>>From: Rob <mailto:rob.bodington@eurostep.com> Bodington
>> >>>
>> >>>To: john.dunford@eurostep.com ; 'Tim King' <mailto:tmk@lsc.co.uk>
>
> ;
>
>> >>>torirgen@eunet.no
>> >>>
>> >>>Cc: trine.hansen@dnv.com ; plcs@lists.oasis-open.org ;
>> >>>leif.tonning@dnv.com ; 'Leif Gyllström'
>> >>><mailto:leif.gyllstrom@aerotechtelub.se>
>> >>>
>> >>>Sent: Tuesday, October 26, 2004 10:21 AM
>> >>>
>> >>>Subject: RE: [plcs] Workshop #2 - Synchronise work on DEXs and
>>reference
>> >>>data
>> >>>between PLCS pilots and OASIS/PLCS
>> >>>
>> >>>
>> >>>
>> >>>John
>> >>>
>> >>>I disagree.
>> >>>
>> >>>The rule will say that there must be at least one identification
>> >>>assigned to product_as_realized.
>> >>>
>> >>>
>> >>>
>> >>>I do not see how you can represent a product_as_realized without
>> >>>identifying it. The id attribute are legacy step which we would
>> >>>like to get rid
>
> of.
>
>> >>>
>> >>>
>> >>>
>> >>>I am not saying that the identification must be a serial number.
>
> Just
>
>> >>>that you
>> >>>must identify the product_as_realized. Reference data will tell
>
> you
>
>>what
>> >>>type
>> >>>of identifier it is.
>> >>>
>> >>>
>> >>>
>> >>>I was thinking of doing the same to Part as well.
>> >>>
>> >>>
>> >>>
>> >>>Regards
>> >>>Rob
>> >>>
>> >>>-------------------------------------------
>> >>>Rob Bodington
>> >>>Eurostep Limited
>> >>>Web Page: <http://www.eurostep.com> http://www.eurostep.com
>> >>><http://www.share-a-space.com> http://www.share-a-space.com
>> >>>Email: Rob.Bodington@eurostep.com
>> >>>Phone: +44 (0)1454 270030
>> >>>Mobile: +44 (0)7796 176 401
>> >>>
>> >>>-----Original Message-----
>> >>>From: John Dunford [mailto:esukpc15@gotadsl.co.uk]
>> >>>Sent: 25 October 2004 15:05
>> >>>To: 'Rob Bodington'; '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
>> >>>
>> >>>
>> >>>
>> >>>Rob, please don't apply a rule to serial id. I like Tim's
>
> explanation
>
>> >>>of how
>> >>>things will work for the situation when reference is made to
>
> realized
>
>> >>>parts by
>> >>>"improper" means! PLCS must recognise that in many current
>> >>>applications, references need to be made to realized parts without
>> >>>serial ids.
>
> This
>
>> >>>is done
>> >>>in various ways including using NSNs, or Slot, or Part
>> >>>numbers/descriptions (e.g. when reporting a Fault, or hours run,
>> >>>on the Starboard Outer
>
> Feed
>
>> >>>Pump).
>> >>>
>> >>>
>> >>>
>> >>>I have a little more sympathy with a global rule on organization
>> >>>assignment, although this again may require such data to be
>> >>>generated by a translator, if
>> >>>the organization id is implicit within a given legacy system.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>John Dunford,
>> >>>
>> >>>Eurostep Limited,
>> >>>
>> >>>25, Chaucer Road, BATH BA2 4QX, UK
>> >>>
>> >>>Tel: +44 1225 789347
>> >>>
>> >>>Mobile: +44 0797 491 8202
>> >>>
>> >>>www.eurostep.com <http://www.eurostep.com/>
>> >>>
>> >>>www.share-a-space.com <http://www.share-a-space.com/>
>> >>>
>> >>>
>> >>>
>> >>>-----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.
>> >>>
>> >>>
>> >>>
>> >>>Regards
>> >>>Rob
>> >>>
>> >>>-------------------------------------------
>> >>>Rob Bodington
>> >>>Eurostep Limited
>> >>>Web Page: <http://www.eurostep.com> http://www.eurostep.com
>> >>><http://www.share-a-space.com> http://www.share-a-space.com
>> >>>Email: Rob.Bodington@eurostep.com
>> >>>Phone: +44 (0)1454 270030
>> >>>Mobile: +44 (0)7796 176 401
>> >>>
>> >>>-----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
>> >>>
>> >>>
>> >>>
>> >>>
>> >>
>> >>
>> >>
>> >>-- ========================================================
>> >>Per-Åke Ling email: per-ake.ling@eurostep.com
>> >>Eurostep AB mobile: +46 709 566 490
>> >>Vasagatan 38 http://www.eurostep.com
>> >>SE-111 20 Stockholm
>> >
>> >
>>
>>--
>>========================================================
>>Per-Åke Ling email: per-ake.ling_AT_eurostep.com
>>Eurostep AB mobile: +46 709 566 490
>>Vasagatan 38 http://www.eurostep.com
>>SE-111 20 Stockholm
>>
>>
>>*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 *
>>
>>
>>
>>
>>
>>
>>----------------------------------------------------------------------
>>--
>>
>
>
--
========================================================
Per-Åke Ling email: per-ake.ling_AT_eurostep.com
Eurostep AB mobile: +46 709 566 490
Vasagatan 38 http://www.eurostep.com
SE-111 20 Stockholm
**************************************************************
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
**************************************************************
| ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]