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

[Tim Turner E-mail <timturner11@bellsouth.net>]

Actually,

Rob was nearly correct - the scenario if fine except for the OID. I wouldn't
suggest trying to refer to an instance number in a step file.

All the proposal was aiming at, was to identify the elements required to
uniquely identify the item of interest. Examples of unique identification
are shown in C001 - Assigning identifiers.

I see a repeatable pattern for the item (e.g. a Part)such as;
	an id along with it's classification (e.g. part number),
	an organisation/person assignment (& it's classification),
	a date/time.

So I wanted to capture all this into a simple reference entity along with
the type of schema used to exchange the original data that we're trying to
reference into.

However, for more complex cases we need to be able to provide further
context e.g. what was the part version as well as the part. Hence the need
to bundle these together in a collector (the set) of items.

Currently, we have to use the same set of (identification) entities as used
in the original exchange file & to rebuild this pattern to achieve the
identification. This causes a larger overlap between capabilities than
required & pulls in a greater number of entities than needed to represent
the new information of the next exchange (e.g. just the work request).

That is, a capability for a work request also needs to contain entities for
the assembly/product to show what it has been assigned to. Hence in a
complex product, we need to be able to uniquely identify the wheel (for
example) that the work is assigned to. This means we need to have part in
the capability/dex that is assinging the work - when a simple reference
would remove the need for this.

There is also a significant difference in the number of instances required
to achieve the reference. A reference is normally something like a string
e.g. ISBN number, or an RDL reference, but what we have a present is nothing
like this.

How systems merge the models internally is really down to their own
implementation, but some references might be easier to handle than others.

This sort of thing may also help us with the customer's requirements
regarding long term data archive/retention.

regards,
Tim

-----Original Message-----
From: David Price [mailto:david.price@eurostep.com]
Sent: 17 September 2004 03: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
> > >
> > >
> > >
> > >
> > >
> > >
>
>
>