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

[Tim Turner <timturner11@bellsouth.net>]

Dave,

Neither am I trying to be difficult. I just sense that what we have is
sub-optimal at present.

I (for one) do not see that what we have at present will be widely adopted
either at present though maybe I'll have to eat my words one day - but at
least I'm putting my thoughts out there!

I agree that the context is all we need. I am trying to suggest that the
*content* of the entities that would normally hold this context be bottled
up some how such that we don't have to repeatedly create duplicate instances
of the thing we're trying to reference. To do this in such a way as to
negate the need to pull in the express definition of what is being
referenced would mean a smaller schema, better lines of delineation between
capabilities & a lesser requirement to create specific capabilities to
represent only those referenced entities (which are then pulled into a Dex).

I do not see the shipbuilding approach as a definitive solution but an
example of the sort of thing we could adapt - just as the building block
approach was also adapted to that of the module one.

I will try to dig out some of the requirements from T23 to at least see if
there is common ground on what they were aiming at.

regards
Tim



-----Original Message-----
From: David Price [mailto:david.price@eurostep.com]
Sent: 29 September 2004 13:17
To: plcs@lists.oasis-open.org
Subject: RE: [plcs] FW: [plcs-dex] Referencing data within other
exchange files


Hi Tim,

Not intentionally trying to be difficult - I won't be in the meetings in
Seattle on this topic so am providing my input via this exploder.

I was actually thinking of Shipbuilding and other models when I said we
should learn our lesson about modelling a capability that will not be widely
adopted. I don't doubt that invididual organizations have made use of these
ideas. The same idea's also stuck in some of the 20s series implementation
methods (i.e. Part 28 Edition 1) and Electric Boat has implemented that too.
My point is that PLCS should not adopt this approach as a requirement for
data consolidation. You don't need to do anything special at all if you
identify things with sufficient context... just as Rob B said. My input to
the discussion can be summarized as "I think the entity types
"external_instance_pattern" and "external_instance_identification" are a
solution looking for a problem.".  I'll stop with that comment.

Cheers,
David

> -----Original Message-----
> From: Tim Turner [mailto:timturner11@bellsouth.net]
> Sent: 29 September 2004 17:59
> To: 'David Price'; plcs@lists.oasis-open.org
> Subject: RE: [plcs] FW: [plcs-dex] Referencing data within
> other exchange files
>
>
> Like I said,
>
> I think it will be useful to review this after the session in Seattle.
>
> The proposal was not to reference a P21 instance number.
> Please look at the example again. (It's way down in the weeds
> of this email somewhere, along with my rejection of Rob's
> assumption about instance numbers).
>
> The requirement to have separate capabilities in order to
> reference the contents of another increases both the number
> of capabilities (& their
> maintenance) and confuses the scope of the Dexs. But that's
> just my own opinion. Maybe others are happy with it.
>
> Dave, I'd like to humbly suggest that the shipbuilding team
> did produce something useful which may provide something to
> learn from - even though it wasn't invented here (PLCS) and
> that some aspects may need to be brought up to date / adapted
> for PLCS if considered. However, I freely admit that we may
> be too far down the line for that. I have been trying to
> point out  an alternative solution to the existing mechanism
> that has been tried & tested & is now being implemented by
> several major vendors (e.g. Electric Boat, Integraph ..).
> However, it may need some adaptation.
>
> Rob, there is a correlation with what PLCS is doing & what
> was produced in the shipbuilding arena. The protocols
> produced by T23 did not need to have a set of separate
> schemas (ref.capabilities) to define objects that required
> referencing (which are then pulled into the Dex).
>
> For example, the protocol for ship structures (AP218) does
> not need to define the entity moulded_form in order to
> reference the moulded_form (defined in AP216) of a bulkhead
> (defined in AP218). In the PLCS method, I would have to
> develop a ref.capability for referencing moulded forms and to
> then pull that into the Dex (in this case AP218).
>
> Will someone from ES planning to present this PLCS reference
> data mechanism at Gerry's session in Seattle?
>
> regards,
> Tim
>
>
>
> -----Original Message-----
> From: David Price [mailto:david.price@eurostep.com]
> Sent: 29 September 2004 10:17
> To: plcs@lists.oasis-open.org
> 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
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> > > >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
>