[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: The saga on "manage identification"
Agreed, assuming that Rob B has by now decided that the uniqueness rule should go in the Capability/DEX, not in AP239 itself. 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 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: 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]