[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]