[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: DEX 3 Status
Team Please note the content of the attached e-mail trail. To save you reading it all, the bottom line is "DEX3 on hold for the moment, except for work being done by Sean." I'll get back to you when the situation changes. John
--- Begin Message ---
- From: John Spencer <John.Spencer@pennantplc.co.uk>
- To: "'Trine.Hansen@dnv.com'" <Trine.Hansen@dnv.com>
- Date: Tue, 2 Nov 2004 10:41:34 -0000
Hi Trine Thanks for your reply. I agree with what you say "best to consider DEX3 on hold for the moment". I will wait to hear from you to start the re-vitalisation process. Could you feed this decision into the "PLCS Resource Spreadsheet" as issued by Chris Kreiler on Friday. Thanks again, good luck with the synchronization project and I hope to hear from you soon. John -----Original Message----- From: Trine.Hansen@dnv.com [mailto:Trine.Hansen@dnv.com] Sent: 02 November 2004 07:46 To: John Spencer Subject: RE: [plcs] DEX Team 3 Hi John. Carl also contacted me about DEX 3 and I answered: "Carl-Johan. As far as I know Sean Barker is the only person that is active in the development of DEX D003 at the moment. He works to finalise the capabilities to a review level. It is very good news if a real project now need the DEX. John Spencer is the team leader (and might know the situation better than me). My impression is that development of this DEX has been set on "hold" - except for the modeller activities - in anticipation of a real project need. As you might know we have started a workshop series between ongoing PLCS pilots to synchronize interpretations of the PLCS data model. Simultaneous we will verify some of the capabilities and DEX1 with respect to a real data need. If you plan revitalisation of the "Task set" DEX I will strongly recommend you to join this work, at least await some results from this work. You can see the latest version of DEX3 at DEXLib. If you have problems with the access, please let me know." Personally I have recommended a "break" in most of the DEX development and await recommendations from the on-going "Synchronization" project. The "mammoth" DEXs we are developing in OASIS are very large and very generic. If the objective is to develope unambiguous DEX specifications, we probably have to focus more on real needs. Today's capabilities may be more like user guidance to the PLCS data model than implementer specifications (they are all candidates for interpretations). We are now developing the "example" DEX "Equipment and parts" in the Synchronization workshops and we might end up with some interesting conclusions. Among other things we have agreed on a set of DEX requirements, and unfortunately no of the OASIS DEXs fulfil these requirements at the moment. One of the deliveries from the "Synchronization" project is recommendations for a way forward. I feel comfortable with the situation that DEX 3 is on "hold" for a while. The procedure/method for developing DEXs may look different after the "Synchronisation" workshops this fall. Best regards Trine _____ From: John Spencer [mailto:John.Spencer@pennantplc.co.uk] Sent: 29. oktober 2004 11:53 To: Hansen, Trine Subject: FW: [plcs] DEX Team 3 Trine My situation hasn't changed since this e-mail in Sep. In fact if anything my availability is even less. Could we discuss this? John +44 23-8090-8204 -----Original Message----- From: John Spencer Sent: 29 September 2004 15:50 To: 'Carl-Johan Wilen' Cc: 'sean.barker@baesystems.com'; 'Nigel Newling' Subject: RE: [plcs] DEX Team 3 Carl I am indeed the team leader, however, as Nigel says, "due to lack of support little headway has been made". The "lack of support" really comes down to funding. None of the team are funded to do any work, so any activity is only that from spare time from "the day job". Sean has managed to find some time, but, speaking for myself only, I have very little opportunity for finding enough time to do anything significant. I have explained this situation to Trine in the past and suggested that perhaps someone else should take over the leadership. However, presumably because everyone else is in the same situation, no alternatives have been forthcoming. Carl - would you be able to take on the leadership? I can probably make myself available for some input and some review activity, but I'm afraid that the time will be very limited. John -----Original Message----- From: Nigel Newling [mailto:nfn@lsc.co.uk] Sent: 29 September 2004 14:04 To: 'Carl-Johan Wilen' Cc: John Spencer; 'sean.barker@baesystems.com' Subject: RE: [plcs] RE: [PLCS] FW: Referencing data within other exchange files Carl-Johan, John Spencer ( John.Spencer@pennantplc.co.uk <mailto:John.Spencer@pennantplc.co.uk> ) is the team leader for DEX 3 but has made little headway in recent months due to lack of support through OASIS. Sean Barker ( sean.barker@baesystems.com <mailto:sean.barker@baesystems.com> ) is the modeller assigned to compile the DEX. Recently, he has been working intermittently, as his day job at BAES permits, on the Task Capabilities that form the core of the DEX. For MoD, the DEX 3 driver is the requirement to be able to replace the relational data base specification of the LSAR in Def Stan 00-60 with a reference to AP 239 DEXs. Nigel -----Original Message----- From: Carl-Johan Wilen [mailto:Carl-Johan.Wilen@saab.se] Sent: 29 September 2004 07:15 To: Nigel Newling; Trine.Hansen@dnv.com Cc: howard.mason@baesystems.com; dennis.stjernfeldt@fmv.se Subject: RE: [plcs] RE: [PLCS] FW: Referencing data within other exchange files Nigel, Has the work on DEX3 Task started (at IFS, Uxbridge (Where did they go ....?) ? We will (and shall) be a part of that DEX development. Who is now the Team leader? In parallel we hare just planning to start up a DEX3 team with participants from FMV, Saab, EuroStep, Norwegian DLO and most certain also UK MoD. The driver behind this is the MoU between PLCS and S1000D. Nothing has happend during the last 24 months on the MoU or the DEX3. It's time to start the job. Any news on what is going on on DEX3 is welcome. /Carl -----Original Message----- From: Nigel Newling [mailto:nfn@lsc.co.uk] Sent: den 21 september 2004 12:06 To: plcs@lists.oasis-open.org Subject: [plcs] RE: [PLCS] FW: Referencing data within other exchange files At risk of stepping into shark infested waters, may I add my three pennyworth? At the launch of the DEX 3 team at IFS, Uxbridge (Where did they go ....?) we had a long debate about the role of DEXs in AP239. It was agreed that DEXs were specifically business orientated, with each DEX capable of standing alone as a data exchange to meet a specific business need. Where two or more DEXs overlap then their data sets could be added, using data objects common across the DEXs as integration keys. It was not, however, considered to be a specific role obligation on the design of a DEX to support data integration. This was considered to be a "free benefit" of DEXs, as implementations of AP239. At a subsequent workshop at R-R, Filton, Bristol, it was agreed that there were, in essence, three types of Capability. Assigning capabilities allowed recurring packages of information, such as a date/time stamp, to be attached to almost any object in the DEX model. Representing capabilities would tell you everything you would ever reasonably want to know about the target. However, for many business processes, this package was considered to be an unnecessary exchange overhead when viewed in terms of the strict business needs of an individual DEX. It was, therefore, resolved to create "cut down" versions of most Representation capabilities. These versions would only supply the basic identity set of the target object. Although they were classified as Reference capabilities, they was not primarily intended to provide the link to the corresponding representation, although, using the DEX integration concept described above, the common ID component of the complementary pair does enable this to be done. So, for example, DEX 4, as a self contained data exchange to request that one or more maintenance tasks be undertaken, only needs to reference the parts that is to be repaired but allows the option of representing the tasks, if the service provider does not already hold a full task library from a DEX 3 exchange, or simply reference the task if it is known that he does. Nigel -----Original Message----- From: John Dunford [ mailto:esukpc15@gotadsl.co.uk <mailto:esukpc15@gotadsl.co.uk> ] Sent: 20 September 2004 09:47 To: plcs@lists.oasis-open.org Subject: [plcs] FW: [plcs-dex] Referencing data within other exchange files A detailed explanation of one way of doing referencing is provided in the attached ODETTE file, which those with long memories will recall was a major source for the DEX concept. 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: Rob Bodington [ mailto:rob.bodington@eurostep.com <mailto:rob.bodington@eurostep.com> ] Sent: 17 September 2004 08:41 To: ''Plcs-Dex teams E-mail ' E-mail' Subject: RE: [plcs-dex] Referencing data within other exchange files I agree David, that is why we have written the referencing capabilities to explain what information you need to exchange in order to be able to uniquely identify something. 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 Fax: +44 (0)1454 270031 > -----Original Message----- > From: David Price [ mailto:david.price@eurostep.com <mailto:david.price@eurostep.com> ] > Sent: 17 September 2004 08:03 > To: ''Plcs-Dex teams E-mail ' E-mail' > Subject: RE: [plcs-dex] Referencing data within other exchange files > > A few opinions:-) > > If those are the requirements, I cannot imagine a worse solution than > using any sort of OID like the Part 21 #number. Using an artificial > identifier like that is not going to solve your problems. You need to > use the "business > identifier", for lack of a better term, and place requirements on > post-processors to merge datasets whether than duplicate data. I don't > think > you can model yourself into solving this requirement. It's been identified > for years and has been built into a few technologies like URIs in OWL but > I've never seen a model of this that really works. You're back to the > Globally Unique Identifier issue and something like a URI or "business > identifier" are the closest thing we have. > > Cheers, > David > > > -----Original Message----- > > From: Rob Bodington [ mailto:rob.bodington@eurostep.com <mailto:rob.bodington@eurostep.com> ] > > Sent: 17 September 2004 07:47 > > To: ''Plcs-Dex teams E-mail ' E-mail' > > Subject: RE: [plcs-dex] Referencing data within other exchange files > > > > > > Hi David > > The requirement is to be able to refer to something that has already > > been exchanged. > > > > For example, on day one I send you the complete product structure of > > an aircraft. A couple of days later I send you a Work request > > relating to a particular version of a part in that product > > structure. Clearly, I do not want to send you the complete aircraft > > plus my work request. Instead I send you the work request plus > > enough information to identify the subject (part > > version) of the work request in your system. So I need to > > send you part version, the part plus the identification > > assignments that enable you to associate the work request > > with the correct part version. > > > > So the "referencing" capabilities are intended to specify the > > contextual information that is necessary to identify something that > > has already been sent. > > > > Tim's proposal is to reference the OID in the Part 21 files. This > > assumes that they are maintained. I had always assumed that a part > > 21 file was transitory. In other words, you import it into you > > system then discard it. Of course, some business processes require > > you to retain the file for audit purposes. > > > > 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 > > Fax: +44 (0)1454 270031 > > > > > > > -----Original Message----- > > > From: David Price [ mailto:david.price@eurostep.com <mailto:david.price@eurostep.com> ] > > > Sent: 16 September 2004 23:28 > > > To: ''Plcs-Dex teams E-mail ' E-mail' > > > Subject: RE: [plcs-dex] Referencing data within other exchange > > > files > > > > > > As an alternative to creating a model supporting a reference to > > > instances in other exchange files/databases, one could simply use > > > implementation technology that natively supports it. For example, > > > that's what Xlink was designed to do and that's one use of URIs in > > > OWL. What *exactly* are the requirements? > > > > > > Cheers, > > > David > > > > > > > -----Original Message----- > > > > From: Tim Turner [ mailto:timturner11@bellsouth.net <mailto:timturner11@bellsouth.net> ] > > > > Sent: 16 September 2004 01:45 > > > > To: 'Plcs-Dex teams E-mail ' E-mail > > > > Subject: [plcs-dex] Referencing data within other exchange files > > > > > > > > > > > > All, > > > > > > > > Following on from my previous email about referencing, if > > we want to > > > > truely reference something from another exchange then (if > > there is > > > > nothing that already lets us achieve the same) lets > > create an entity > > > > to handle it, e.g; something like... > > > > > > > > Entity external_instance_pattern > > > > instance_pattern : SET[1:?] external_instance_identification; > > > > name: string; > > > > description : OPTIONAL STRING; > > > > End_entity; > > > > > > > > ENTITY external_instance_identification; > > > > source_id : STRING; > > > > source_type : STRING; > > > > instance_identifier : STRING; > > > > identifier_classification: external_class; > > > > description : OPTIONAL STRING; > > > > END_ENTITY; > > > > > > > > This lets us create a reference to an instance within another > > > > exchange file (it may since have been stored in a > > database or other > > > > system - but that is not our worry). It also lets us choose > > > > which Dex or schema that the exchange was provided within (the > > source_id), > > > > the instance type (source_type), the identifier used, and the > > > > classification that was used. > > > > > > > > Hence to reference a Part with the identifier "PSU-009" > > classified > > > > as a "part_type_code" that was exchanged using Dex001, we would > > > > have; > > > > > > > > #1=external_instance_pattern((#2), 'simple design part > > reference', > > > > $); #2=external_source_identification('Dex001', > > > > 'Part', 'PSU-009', #3, $); #3=external_class('Part_type_code', > > > > $); > > > > > > > > More complex ones would be something like; > > > > For a Version 1.1 of Part with the identifier "PSU-009" > > classified > > > > as a "part_type_code" we would have; > > > > > > > > #1=external_instance_pattern_identification((#2, #4), > > 'simple design > > > > part version reference', $); > > > > #2=external_source_identification('Dex001', 'Part', > > 'PSU-009', #3, > > > > $); #3=external_class('Part_type_code', $); > > > > #4=external_source_identification('Dex001', > > 'Part_version', '1.1', > > > > #5, $); #5=external_class('Version_code', $); > > > > > > > > For more complex patterns we just add another instance of > > > > external_source_identification to the external_instance_pattern. > > > > > > > > If necessary (for unique & complete identification) we might > > > > also need to add two other optional attributes to the > > > > external_source_identification, such as; the organization and > > > > date/time. > > > > > > > > This approach is compatible with re-using classification, > > reference > > > > data and is straight forward (to me at least!). > > > > > > > > To be used, external_instance_pattern would need to be a viable > > > > option in the extensible select lists when doing an assignment - > > > > e.g. when assigning a task, document, activity, > > observation etc.. to > > > > the item of interest being referenced. > > > > > > > > This may even help interoperability & even allow us to span data > > > > over several files (if needed). > > > > > > > > Just something to think about- but comments welcome! > > > > > > > > regards, > > > > Tim > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 ************************************************************** 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 **************************************************************--- End Message ---
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]