OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

plcs-dex message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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]