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

[Tim Turner <timturner11@bellsouth.net>]

Saun,

sorry, I appreciate what you say, but how does this affect the original
problem, which is the duplication of entities in capabilities for the
requirement to be able to provide enough unique identification of the PIF? 

The real issue at heart is the way the capabilities are having to use
entities beyond their scope to enable adequate interoperability between
them. This has resulted in the need to develop referencing capabilities
which have large overlapping set of entities with those that do the
representation. That just seems more complicated than it needs to be -
especially when we're going to see a significant increase in the number of
capabilities over time.

I don't really want to be a synnic, but are we really going to have a
separate capability for the representation_of_XX, the assignment_of_XX and
another for the referencing_of_XX? We'll soon be generating a set of these
for each module! Actually, maybe that would be a more logical!

regards,
Tim



-----Original Message-----
From: Barker, Sean (UK) [mailto:sean.barker@baesystems.com]
Sent: 17 September 2004 15:36
To: timturner11@bellsouth.net; David Price; 'Plcs-Dex teams E-mail '
E-mail
Subject: RE: [plcs-dex] Referencing data within other exchange files



Tim,
	the idea of a unique id simply consisting of a number or string
disappeared with the introduction of the UID standard, for which any part
number must also contain its organizational context. (In theory, the
organization should also have an ID referenced to the context of the
organization that creates those ID's).
	The requirement is that the id be unique over the likely scope of
id's for 'that kind of thing'. Parts are generally not too painful, once you
know the allocating organization. For Task, it was required that the number
be unique within the context of the affected product.
	The critical questions are:
a) What makes the identifier unique for the entity-type in the context of a
distributed organisation (think DoD)?
b) Does the STEP data model allow that identifier to be associated to the
correct context?
c) Do cardinality constraints or rules constrain the model to require
extraneous data?

Yours:

Sean Barker (Implied PLCS context)
9518F (Implied BAE SYSTEMS context)
+44 117 302 8184 (what sort of entity is this?)

-----Original Message-----
From: Tim Turner E-mail [mailto:timturner11@bellsouth.net]
Sent: 17 September 2004 15:39
To: 'David Price'; ''Plcs-Dex teams E-mail ' E-mail'
Subject: RE: [plcs-dex] Referencing data within other exchange files


               *** WARNING ***

This mail has originated outside your organization,
either from an external partner or the Global Internet.      Keep this in
mind if you answer this message. 
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
> > >
> > >
> > >
> > >
> > >
> > >
>
>
>





********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

<<attachment: winmail.dat>>