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

["David Price" <david.price@eurostep.com>]

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