[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [plcs] FW: [plcs-dex] Referencing data within other exchange files
All,
Rob B's explanation of data consolidation is right on (or is that spot on
for Brits?). It's a fruitless exercise to build a capability into the
information model to refer between Part 21 files. People inside and outside
STEP have looked into this for years and produced nothing useful. I'd
encourage the PLCS/DEX team to learn from that wasted effort. Write a
guideline or place requirements on post-processors if you must, but don't
try and model Part 21 identifiers.
Cheers,
David
> -----Original Message-----
> From: Rob Bodington [mailto:rob.bodington@eurostep.com]
> Sent: 29 September 2004 15:02
> To: timturner11@bellsouth.net; john.dunford@eurostep.com;
> plcs@lists.oasis-open.org
> Subject: RE: [plcs] FW: [plcs-dex] Referencing data within
> other exchange files
>
>
> John
> We took the Odette document as a starting point.
> That is why we have implemented referencing capabilities.
> I remain to be convinced that we need yet another means in a
> Part 21 file to refer to some other entity in another part 21 file.
>
> Data consolidation takes place in applications importing
> data. When importing data, the data consolidation process
> needs enough contextual information about an entity being
> imported to establish whether it already exists in the
> database. It is the definition of that contextual information
> that the Odette document and the referencing capabilities specify.
>
> For example, if I send you a part, then send you a document
> assigned to that part, the information that you need to
> establish that the two exchanges are talking about the same
> part is the identification_assignment. Not the OID (#1 part
> etc) of the part in a Part21 file. The part 21 file may well
> be transitory.
>
> Tim - I am not sure what this has to do with modules or ship
> building blocks?
>
> Or have I missed the point completely.
>
> 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: Tim Turner [mailto:timturner11@bellsouth.net]
> Sent: 29 September 2004 14:36
> To: john.dunford@eurostep.com; plcs@lists.oasis-open.org
> Subject: RE: [plcs] FW: [plcs-dex] Referencing data within
> other exchange files
>
> John,
>
> I think that it will be useful to review this in the light of
> Gerry's session on Wed at Seattle.
>
> I have offered to put something together on behalf of the
> shipbuilding team - which used building blocks similar to
> modules (as a development
> mechanism) and had a number of shorter schemas than the Ship
> Product Model (read PLCS) that required - what I think - is a
> similar amount of interoperability.
>
> However, I will only have time to do that on the flight out there!
>
> regards,
> Tim
>
>
> -----Original Message-----
> From: John Dunford [mailto:esukpc15@gotadsl.co.uk]
> Sent: 28 September 2004 13:34
> To: plcs@lists.oasis-open.org
> Subject: FW: [plcs] FW: [plcs-dex] Referencing data within
> other exchange files
>
>
> Dear All, do we now have an agreed way forward for the
> referencing capabilities? This is a key feature of the DEX
> concept as it provides the means both to:
>
> - handle net change
> - grow an info set over time
> - link data from one DEX to data from another.
>
> At first sight it seems sensible, as Tim implies below, to
> have a single referencing mechanism (if necessary with
> options within in) which could be used by any DEX to point to
> ANY entity in PLCS to which reference was needed.
>
> I don't think this is an issue we should slide past without
> due thought and attention!
>
> 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 Turner [mailto:timturner11@bellsouth.net]
> Sent: 23 September 2004 03:22
> To: john.dunford@eurostep.com
> Subject: RE: [plcs] FW: [plcs-dex] Referencing data within
> other exchange files
>
>
> Thanks John,
>
> this does shed some light onto the history of where we are.
> However, that doesn't solve the issue at hand (IMHO), about
> having to create a capability for the sole purpose of
> representing entities to be referenced from another.
>
> What is does do, however, is to tell me that those entities
> used for refernce purposes should be classified as such (in
> addition, I presume, to the identification assignment). This
> is not mentioned in any of the capabiltiies I've read so far.
>
> I apprecaite all the hard work gone into the current solution
> but I see a wealth of future confusion and issues around
> maintaining two capabilities when one would do.
>
> Someone once said that the capabilities are just building
> blocks for the Dexs & that they were to be transparent to Dex
> implementors. If that is the case, then we need to remove or
> re-package those listed within the body of a Dex - but that's
> propbably another issue.
>
> Best regards,
> Tim
>
> -----Original Message-----
> From: John Dunford [mailto:esukpc15@gotadsl.co.uk]
> Sent: 20 September 2004 04: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]
> 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.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]
> > 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]
> > > 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.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]
> > > > 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]
> > > > > 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
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > >
> > >
> > >
>
>
>
>
>
>
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]