RE: [plcs-dex] Referencing data within other exchange files

["Rob Bodington" <rob.bodington@eurostep.com>]

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
> >
> >
> >
> >
> >
> >