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