[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
If each capability had the ability to use a simple independant referencing
mechanism, then we could make the separation of both the capabilities & the
Dexs clearer and more definitive without the need to introduce redundancy &
repetition.
regards,
Tim
-----Original Message-----
From: Nigel Newling [mailto:nfn@lsc.co.uk]
Sent: 21 September 2004 06:06
To: plcs@lists.oasis-open.org
Subject: [plcs] RE: [PLCS] FW: Referencing data within other exchange
files
At risk of stepping into shark infested waters, may I add my three
pennyworth?
At the launch of the DEX 3 team at IFS, Uxbridge (Where did they go ....?)
we had a long debate about the role of DEXs in AP239. It was agreed that
DEXs were specifically business orientated, with each DEX capable of
standing alone as a data exchange to meet a specific business need. Where
two or more DEXs overlap then their data sets could be added, using data
objects common across the DEXs as integration keys. It was not, however,
considered to be a specific role obligation on the design of a DEX to
support data integration. This was considered to be a "free benefit" of
DEXs, as implementations of AP239.
At a subsequent workshop at R-R, Filton, Bristol, it was agreed that there
were, in essence, three types of Capability. Assigning capabilities allowed
recurring packages of information, such as a date/time stamp, to be attached
to almost any object in the DEX model. Representing capabilities would tell
you everything you would ever reasonably want to know about the target.
However, for many business processes, this package was considered to be an
unnecessary exchange overhead when viewed in terms of the strict business
needs of an individual DEX. It was, therefore, resolved to create "cut down"
versions of most Representation capabilities. These versions would only
supply the basic identity set of the target object. Although they were
classified as Reference capabilities, they was not primarily intended to
provide the link to the corresponding representation, although, using the
DEX integration concept described above, the common ID component of the
complementary pair does enable this to be done. So, for example, DEX 4, as a
self contained data exchange to request that one or more maintenance tasks
be undertaken, only needs to reference the parts that is to be repaired but
allows the option of representing the tasks, if the service provider does
not already hold a full task library from a DEX 3 exchange, or simply
reference the task if it is known that he does.
Nigel
-----Original Message-----
From: John Dunford [mailto:esukpc15@gotadsl.co.uk]
Sent: 20 September 2004 09: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
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> >
> >
> >
DISCLAIMER: ***SECURITY LABEL: NOT PROTECTIVELY MARKED*** The
information in this message is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this message by anyone
else is unauthorised. If you are not the intended recipient, any
disclosure, copying, or distribution of the message, or any action or
omission taken by you in reliance on it, is prohibited and may be unlawful.
Please immediately contact the sender if you have received this message in
error. This e-mail originates from LSC Group. Registered in England & Wales
No 2275471 Registered Office: Devonport Royal Dockyard, Devonport, Plymouth,
PL1 4SG
------=_NextPart_000_0056_01C4A149.C5C3BB00
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>RE: [PLCS] FW: Referencing data within other exchange =
files</TITLE>
<META content=3D"MSHTML 6.00.2800.1458" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D835114002-23092004><FONT face=3DArial color=3D#0000ff =
size=3D2>Nigel,=20
sharks aside - </FONT></SPAN></DIV>
<DIV><SPAN class=3D835114002-23092004><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D835114002-23092004><FONT face=3DArial color=3D#0000ff =
size=3D2>IMHO I=20
don't like to see the use of the term 'reference keys' in statements =
like=20
that below as it already supposes a specific implementation =
paradigm which=20
is not what we should be advocating when developing a standard. That =
said, the=20
aims and goals stated are perfectly normal and satisfactory up until the =
section=20
about cut-down versions of the capabilities.</FONT></SPAN></DIV>
<DIV><FONT face=3DArial><FONT size=3D2><FONT color=3D#0000ff><SPAN=20
class=3D835114002-23092004><FONT face=3DArial color=3D#008000=20
size=3D2></FONT></SPAN></FONT></FONT></FONT> </DIV>
<DIV><SPAN class=3D835114002-23092004><FONT face=3DArial><FONT =
color=3D#0000ff=20
size=3D2>The essence here is in the example you point out. "So, for =
example,=20
DEX 4, as a self contained data exchange to request that one or more =
maintenance=20
tasks be undertaken, <STRONG>only needs to reference the parts</STRONG> =
that is=20
to be repaired but allows the option of representing the tasks, if the =
service=20
provider does not already hold a full task library from a DEX 3 =
exchange, or=20
simply reference the task if it is known that he=20
does."</FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D835114002-23092004><FONT =
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D835114002-23092004><FONT size=3D2><FONT face=3DArial=20
color=3D#0000ff>The fact that a work order needs to accurately =
reference the=20
identification of the object to which it applies is without question. =
However,=20
this can only be done at present through the reproduction of both the =
entity and=20
it's associated contextual identifiers (class/org/date), then it's =
associated=20
version and it's identifiers, and probably the view definition context =
also.=20
From the Odette example, it is also clear that an additional=20
classification of this entity is also required (class =
'reference').</FONT>=20
</FONT></SPAN></DIV>
<DIV><FONT face=3DArial><FONT size=3D2><FONT color=3D#0000ff><SPAN=20
class=3D835114002-23092004><FONT=20
size=3D2></FONT></SPAN></FONT></FONT></FONT> </DIV>
<DIV><SPAN class=3D835114002-23092004><FONT face=3DArial color=3D#0000ff =
size=3D2>If=20
each capability had the ability to use a simple independant referencing=20
mechanism, then we could make the separation of both the capabilities =
& the=20
Dexs clearer and more definitive without the need to introduce =
redundancy &=20
repetition.</FONT></SPAN></DIV>
<DIV><FONT face=3DArial><FONT size=3D2><FONT color=3D#0000ff><SPAN=20
class=3D835114002-23092004><FONT=20
size=3D2></FONT></SPAN></FONT></FONT></FONT> </DIV>
<DIV><SPAN class=3D835114002-23092004><FONT =
size=3D2>regards,</FONT></SPAN></DIV>
<DIV><SPAN class=3D835114002-23092004><FONT =
size=3D2>Tim</FONT></SPAN></DIV>
<BLOCKQUOTE>
<DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
size=3D2>-----Original Message-----<BR><B>From:</B> Nigel Newling=20
[mailto:nfn@lsc.co.uk]<BR><B>Sent:</B> 21 September 2004 =
06:06<BR><B>To:</B>=20
plcs@lists.oasis-open.org<BR><B>Subject:</B> [plcs] RE: [PLCS] FW: =
Referencing=20
data within other exchange files<BR><BR></FONT></DIV>
<P><FONT size=3D2>At risk of stepping into shark infested waters, may =
I add my=20
three pennyworth?</FONT> </P>
<P><FONT size=3D2>At the launch of the DEX 3 team at IFS, Uxbridge =
(Where did=20
they go ....?) we had a long debate about the role of DEXs in AP239. =
It was=20
agreed that DEXs were specifically business orientated, with each DEX =
capable=20
of standing alone as a data exchange to meet a specific business need. =
Where=20
two or more DEXs overlap then their data sets could be added, using =
data=20
objects common across the DEXs as integration keys. It was not, =
however,=20
considered to be a specific role obligation on the design of a DEX to =
support=20
data integration. This was considered to be a "free benefit" of DEXs, =
as=20
implementations of AP239.</FONT></P>
<P><FONT size=3D2>At a subsequent workshop at R-R, Filton, Bristol, it =
was=20
agreed that there were, in essence, three types of Capability. =
Assigning=20
capabilities allowed recurring packages of information, such as a =
date/time=20
stamp, to be attached to almost any object in the DEX model. =
Representing=20
capabilities would tell you everything you would ever reasonably want =
to know=20
about the target. However, for many business processes, this package =
was=20
considered to be an unnecessary exchange overhead when viewed in terms =
of the=20
strict business needs of an individual DEX. It was, therefore, =
resolved to=20
create "<STRONG>cut down</STRONG>" versions of most Representation=20
capabilities. These versions would only supply the basic identity set =
of the=20
target object. Although they were classified as Reference =
capabilities, they=20
was not primarily intended to provide the link to the corresponding=20
representation, although, using the DEX integration concept described =
above,=20
the common ID component of the complementary pair does enable this to =
be done.=20
So, for example, DEX 4, as a self contained data exchange to request =
that one=20
or more maintenance tasks be undertaken, <STRONG>only needs to =
reference the=20
parts</STRONG> that is to be repaired but allows the option of =
representing=20
the tasks, if the service provider does not already hold a full task =
library=20
from a DEX 3 exchange, or simply reference the task if it is known =
that he=20
does.</FONT></P>
<P><FONT size=3D2>Nigel</FONT> </P>
<P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From: John=20
Dunford [<A=20
=
href=3D"mailto:esukpc15@gotadsl.co.uk";>mailto:esukpc15@gotadsl.co.uk</A>]=
</FONT>=20
<BR><FONT size=3D2>Sent: 20 September 2004 09:47</FONT> <BR><FONT =
size=3D2>To:=20
plcs@lists.oasis-open.org</FONT> <BR><FONT size=3D2>Subject: [plcs] =
FW:=20
[plcs-dex] Referencing data within other exchange</FONT> <BR><FONT=20
size=3D2>files</FONT> </P><BR>
<P><FONT size=3D2>A detailed explanation of one way of doing =
referencing is=20
provided in</FONT> <BR><FONT size=3D2>the attached ODETTE file, which =
those with=20
long memories will recall was</FONT> <BR><FONT size=3D2>a major source =
for the=20
DEX concept.</FONT> </P>
<P><FONT size=3D2>John Dunford,</FONT> <BR><FONT size=3D2>Eurostep =
Limited,</FONT>=20
<BR><FONT size=3D2>25, Chaucer Road, BATH BA2 4QX, UK</FONT> <BR><FONT =
size=3D2>Tel: +44 1225 789347</FONT> <BR><FONT size=3D2>Mobile: +44 =
0797 491=20
8202</FONT> <BR><FONT size=3D2>www.eurostep.com</FONT> <BR><FONT=20
size=3D2>www.share-a-space.com</FONT> <BR><FONT size=3D2> </FONT> =
</P><BR>
<P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From: Rob=20
Bodington [<A=20
=
href=3D"mailto:rob.bodington@eurostep.com";>mailto:rob.bodington@eurostep.=
com</A>]=20
</FONT><BR><FONT size=3D2>Sent: 17 September 2004 08:41</FONT> =
<BR><FONT=20
size=3D2>To: ''Plcs-Dex teams E-mail ' E-mail'</FONT> <BR><FONT =
size=3D2>Subject:=20
RE: [plcs-dex] Referencing data within other exchange files</FONT> =
</P><BR>
<P><FONT size=3D2>I agree David, that is why we have written the =
referencing=20
capabilities</FONT> <BR><FONT size=3D2>to explain what information you =
need to=20
exchange in order to be able to</FONT> <BR><FONT size=3D2>uniquely =
identify=20
something.</FONT> </P>
<P><FONT size=3D2>Regards</FONT> <BR><FONT size=3D2>Rob</FONT> </P>
<P><FONT size=3D2>-------------------------------------------</FONT> =
<BR><FONT=20
size=3D2>Rob Bodington</FONT> <BR><FONT size=3D2>Eurostep =
Limited</FONT> <BR><FONT=20
size=3D2>Web Page: <A href=3D"http://www.eurostep.com"=20
target=3D_blank>http://www.eurostep.com</A> <A=20
href=3D"http://www.share-a-space.com"=20
target=3D_blank>http://www.share-a-space.com</A></FONT> <BR><FONT=20
size=3D2>Email: Rob.Bodington@eurostep.com</FONT> <BR><FONT=20
size=3D2>Phone: +44 (0)1454 270030</FONT> <BR><FONT =
size=3D2>Mobile: +44=20
(0)7796 176 401</FONT> <BR><FONT size=3D2>Fax: +44 =
(0)1454=20
270031 </FONT></P><BR>
<P><FONT size=3D2>> -----Original Message-----</FONT> <BR><FONT =
size=3D2>>=20
From: David Price [<A=20
=
href=3D"mailto:david.price@eurostep.com";>mailto:david.price@eurostep.com<=
/A>]</FONT>=20
<BR><FONT size=3D2>> Sent: 17 September 2004 08:03</FONT> <BR><FONT =
size=3D2>> To: ''Plcs-Dex teams E-mail ' E-mail'</FONT> <BR><FONT =
size=3D2>>=20
Subject: RE: [plcs-dex] Referencing data within other exchange =
files</FONT>=20
<BR><FONT size=3D2>> </FONT><BR><FONT size=3D2>> A few =
opinions:-)</FONT>=20
<BR><FONT size=3D2>> </FONT><BR><FONT size=3D2>> If those are =
the=20
requirements, I cannot imagine a worse solution than</FONT> <BR><FONT=20
size=3D2>> using any sort of OID like the Part 21 #number. Using an =
artificial </FONT><BR><FONT size=3D2>> identifier like that is not =
going to=20
solve your problems. You need to </FONT><BR><FONT size=3D2>> use =
the=20
"business</FONT> <BR><FONT size=3D2>> identifier", for lack of a =
better term,=20
and place requirements on</FONT> <BR><FONT size=3D2>> =
post-processors to=20
merge datasets whether than duplicate data. I don't</FONT> <BR><FONT=20
size=3D2>> think</FONT> <BR><FONT size=3D2>> you can model =
yourself into=20
solving this requirement. It's been</FONT> <BR><FONT =
size=3D2>identified</FONT>=20
<BR><FONT size=3D2>> for years and has been built into a few =
technologies=20
like URIs in OWL</FONT> <BR><FONT size=3D2>but</FONT> <BR><FONT =
size=3D2>> I've=20
never seen a model of this that really works. You're back to =
the</FONT>=20
<BR><FONT size=3D2>> Globally Unique Identifier issue and something =
like a=20
URI or "business</FONT> <BR><FONT size=3D2>> identifier" are the =
closest=20
thing we have.</FONT> <BR><FONT size=3D2>> </FONT><BR><FONT =
size=3D2>>=20
Cheers,</FONT> <BR><FONT size=3D2>> David</FONT> <BR><FONT =
size=3D2>>=20
</FONT><BR><FONT size=3D2>> > -----Original Message-----</FONT> =
<BR><FONT=20
size=3D2>> > From: Rob Bodington [<A=20
=
href=3D"mailto:rob.bodington@eurostep.com";>mailto:rob.bodington@eurostep.=
com</A>]</FONT>=20
<BR><FONT size=3D2>> > Sent: 17 September 2004 07:47</FONT> =
<BR><FONT=20
size=3D2>> > To: ''Plcs-Dex teams E-mail ' E-mail'</FONT> =
<BR><FONT=20
size=3D2>> > Subject: RE: [plcs-dex] Referencing data within =
other=20
exchange files</FONT> <BR><FONT size=3D2>> ></FONT> <BR><FONT =
size=3D2>>=20
></FONT> <BR><FONT size=3D2>> > Hi David</FONT> <BR><FONT =
size=3D2>>=20
> The requirement is to be able to refer to something that has=20
already</FONT> <BR><FONT size=3D2>> > been exchanged.</FONT> =
<BR><FONT=20
size=3D2>> ></FONT> <BR><FONT size=3D2>> > For example, on =
day one I=20
send you the complete product structure of</FONT> <BR><FONT =
size=3D2>> >=20
an aircraft. A couple of days later I send you a Work request =
</FONT><BR><FONT=20
size=3D2>> > relating to a particular version of a part in that =
product=20
</FONT><BR><FONT size=3D2>> > structure. Clearly, I do not want =
to send=20
you the complete aircraft </FONT><BR><FONT size=3D2>> > plus my =
work=20
request. Instead I send you the work request plus </FONT><BR><FONT =
size=3D2>>=20
> enough information to identify the subject (part</FONT> <BR><FONT =
size=3D2>> > version) of the work request in your system. So I =
need=20
to</FONT> <BR><FONT size=3D2>> > send you part version, the part =
plus the=20
identification</FONT> <BR><FONT size=3D2>> > assignments that =
enable you=20
to associate the work request</FONT> <BR><FONT size=3D2>> > with =
the=20
correct part version.</FONT> <BR><FONT size=3D2>> ></FONT> =
<BR><FONT=20
size=3D2>> > So the "referencing" capabilities are intended to =
specify=20
the</FONT> <BR><FONT size=3D2>> > contextual information that is =
necessary=20
to identify something that </FONT><BR><FONT size=3D2>> > has =
already been=20
sent.</FONT> <BR><FONT size=3D2>> ></FONT> <BR><FONT =
size=3D2>> >=20
Tim's proposal is to reference the OID in the Part 21 files. =
This</FONT>=20
<BR><FONT size=3D2>> > assumes that they are maintained. I had =
always=20
assumed that a part </FONT><BR><FONT size=3D2>> > 21 file was =
transitory.=20
In other words, you import it into you </FONT><BR><FONT size=3D2>> =
>=20
system then discard it. Of course, some business processes require=20
</FONT><BR><FONT size=3D2>> > you to retain the file for audit=20
purposes.</FONT> <BR><FONT size=3D2>> ></FONT> <BR><FONT =
size=3D2>> >=20
Regards</FONT> <BR><FONT size=3D2>> > Rob</FONT> <BR><FONT =
size=3D2>>=20
></FONT> <BR><FONT size=3D2>> >=20
-------------------------------------------</FONT> <BR><FONT =
size=3D2>> >=20
Rob Bodington</FONT> <BR><FONT size=3D2>> > Eurostep =
Limited</FONT>=20
<BR><FONT size=3D2>> > Web Page: <A=20
href=3D"http://www.eurostep.com"; =
target=3D_blank>http://www.eurostep.com</A> <A=20
href=3D"http://www.share-a-space.com"=20
target=3D_blank>http://www.share-a-space.com</A></FONT> <BR><FONT =
size=3D2>>=20
> Email: Rob.Bodington@eurostep.com</FONT> <BR><FONT =
size=3D2>> >=20
Phone: +44 (0)1454 270030</FONT> <BR><FONT size=3D2>> > =
Mobile: +44=20
(0)7796 176 401</FONT> <BR><FONT size=3D2>> > =
Fax: +44=20
(0)1454 270031</FONT> <BR><FONT size=3D2>> ></FONT> <BR><FONT =
size=3D2>>=20
></FONT> <BR><FONT size=3D2>> > > -----Original =
Message-----</FONT>=20
<BR><FONT size=3D2>> > > From: David Price [<A=20
=
href=3D"mailto:david.price@eurostep.com";>mailto:david.price@eurostep.com<=
/A>]</FONT>=20
<BR><FONT size=3D2>> > > Sent: 16 September 2004 23:28</FONT> =
<BR><FONT=20
size=3D2>> > > To: ''Plcs-Dex teams E-mail ' E-mail'</FONT> =
<BR><FONT=20
size=3D2>> > > Subject: RE: [plcs-dex] Referencing data =
within other=20
exchange</FONT> <BR><FONT size=3D2>> > > files</FONT> =
<BR><FONT=20
size=3D2>> > ></FONT> <BR><FONT size=3D2>> > > As an =
alternative=20
to creating a model supporting a reference to</FONT> <BR><FONT =
size=3D2>>=20
> > instances in other exchange files/databases, one could =
simply use=20
</FONT><BR><FONT size=3D2>> > > implementation technology =
that natively=20
supports it. For example, </FONT><BR><FONT size=3D2>> > > =
that's what=20
Xlink was designed to do and that's one use of URIs in</FONT> </P>
<P><FONT size=3D2>> > > OWL. What *exactly* are the=20
requirements?</FONT> <BR><FONT size=3D2>> > ></FONT> =
<BR><FONT=20
size=3D2>> > > Cheers,</FONT> <BR><FONT size=3D2>> > =
>=20
David</FONT> <BR><FONT size=3D2>> > ></FONT> <BR><FONT =
size=3D2>> >=20
> > -----Original Message-----</FONT> <BR><FONT size=3D2>> =
> >=20
> From: Tim Turner [<A=20
=
href=3D"mailto:timturner11@bellsouth.net";>mailto:timturner11@bellsouth.ne=
t</A>]</FONT>=20
<BR><FONT size=3D2>> > > > Sent: 16 September 2004 =
01:45</FONT>=20
<BR><FONT size=3D2>> > > > To: 'Plcs-Dex teams E-mail '=20
E-mail</FONT> <BR><FONT size=3D2>> > > > Subject: =
[plcs-dex]=20
Referencing data within other exchange files</FONT> <BR><FONT =
size=3D2>> >=20
> ></FONT> <BR><FONT size=3D2>> > > ></FONT> =
<BR><FONT=20
size=3D2>> > > > All,</FONT> <BR><FONT size=3D2>> > =
>=20
></FONT> <BR><FONT size=3D2>> > > > Following on from =
my previous=20
email about referencing, if</FONT> <BR><FONT size=3D2>> > we =
want=20
to</FONT> <BR><FONT size=3D2>> > > > truely reference =
something from=20
another exchange then (if</FONT> <BR><FONT size=3D2>> > there =
is</FONT>=20
<BR><FONT size=3D2>> > > > nothing that already lets us =
achieve the=20
same) lets</FONT> <BR><FONT size=3D2>> > create an entity</FONT> =
<BR><FONT=20
size=3D2>> > > > to handle it, e.g; something =
like...</FONT>=20
<BR><FONT size=3D2>> > > ></FONT> <BR><FONT size=3D2>> =
> >=20
> Entity external_instance_pattern</FONT> <BR><FONT size=3D2>> =
> >=20
> instance_pattern : SET[1:?]=20
external_instance_identification;</FONT> <BR><FONT size=3D2>> > =
>=20
> name: string;</FONT> <BR><FONT size=3D2>> > > =
> =20
description : OPTIONAL STRING;</FONT> <BR><FONT size=3D2>> > =
> >=20
End_entity;</FONT> <BR><FONT size=3D2>> > > ></FONT> =
<BR><FONT=20
size=3D2>> > > > ENTITY =
external_instance_identification;</FONT>=20
<BR><FONT size=3D2>> > > > source_id : =
STRING;</FONT>=20
<BR><FONT size=3D2>> > > > source_type : =
STRING;</FONT>=20
<BR><FONT size=3D2>> > > > instance_identifier :=20
STRING;</FONT> <BR><FONT size=3D2>> > > > =20
identifier_classification: external_class;</FONT> <BR><FONT =
size=3D2>> >=20
> > description : OPTIONAL STRING;</FONT> <BR><FONT =
size=3D2>>=20
> > > END_ENTITY;</FONT> <BR><FONT size=3D2>> > > =
></FONT>=20
<BR><FONT size=3D2>> > > > This lets us create a reference =
to an=20
instance within another</FONT> <BR><FONT size=3D2>> > > > =
exchange=20
file (it may since have been stored in a</FONT> <BR><FONT =
size=3D2>> >=20
database or other</FONT> <BR><FONT size=3D2>> > > > system =
- but=20
that is not our worry). It also lets us choose</FONT> <BR><FONT =
size=3D2>>=20
> > > which Dex or schema that the exchange was provided =
within=20
(the</FONT> <BR><FONT size=3D2>> > source_id),</FONT> <BR><FONT=20
size=3D2>> > > > the instance type (source_type), the =
identifier=20
used, and the</FONT> <BR><FONT size=3D2>> > > > =
classification that=20
was used.</FONT> <BR><FONT size=3D2>> > > ></FONT> =
<BR><FONT=20
size=3D2>> > > > Hence to reference a Part with the =
identifier=20
"PSU-009"</FONT> <BR><FONT size=3D2>> > classified</FONT> =
<BR><FONT=20
size=3D2>> > > > as a "part_type_code" that was exchanged =
using=20
Dex001, we would</FONT> <BR><FONT size=3D2>> > > > =
have;</FONT>=20
<BR><FONT size=3D2>> > > ></FONT> <BR><FONT size=3D2>> =
> >=20
> #1=3Dexternal_instance_pattern((#2), 'simple design part</FONT> =
<BR><FONT=20
size=3D2>> > reference',</FONT> <BR><FONT size=3D2>> > =
> > $);=20
#2=3Dexternal_source_identification('Dex001',</FONT> <BR><FONT =
size=3D2>> >=20
> > 'Part', 'PSU-009', #3, $);=20
#3=3Dexternal_class('Part_type_code',</FONT> <BR><FONT size=3D2>> =
> >=20
> $);</FONT> <BR><FONT size=3D2>> > > ></FONT> =
<BR><FONT=20
size=3D2>> > > > More complex ones would be something =
like;</FONT>=20
<BR><FONT size=3D2>> > > > For a Version 1.1 of Part with =
the=20
identifier "PSU-009"</FONT> <BR><FONT size=3D2>> > =
classified</FONT>=20
<BR><FONT size=3D2>> > > > as a "part_type_code" we would=20
have;</FONT> <BR><FONT size=3D2>> > > ></FONT> <BR><FONT =
size=3D2>>=20
> > > #1=3Dexternal_instance_pattern_identification((#2, =
#4),</FONT>=20
<BR><FONT size=3D2>> > 'simple design</FONT> <BR><FONT =
size=3D2>> >=20
> > part version reference', $);</FONT> <BR><FONT size=3D2>> =
> >=20
> #2=3Dexternal_source_identification('Dex001', 'Part',</FONT> =
<BR><FONT=20
size=3D2>> > 'PSU-009', #3,</FONT> <BR><FONT size=3D2>> > =
> >=20
$); #3=3Dexternal_class('Part_type_code', $);</FONT> <BR><FONT =
size=3D2>> >=20
> > #4=3Dexternal_source_identification('Dex001',</FONT> =
<BR><FONT=20
size=3D2>> > 'Part_version', '1.1',</FONT> <BR><FONT =
size=3D2>> > >=20
> #5, $); #5=3Dexternal_class('Version_code', $);</FONT> <BR><FONT=20
size=3D2>> > > ></FONT> <BR><FONT size=3D2>> > > =
> For=20
more complex patterns we just add another instance of</FONT> <BR><FONT =
size=3D2>> > > > external_source_identification to the=20
external_instance_pattern.</FONT> <BR><FONT size=3D2>> > > =
></FONT>=20
<BR><FONT size=3D2>> > > > If necessary (for unique & =
complete=20
identification) we might</FONT> <BR><FONT size=3D2>> > > > =
also need=20
to add two other optional attributes to the </FONT><BR><FONT =
size=3D2>> >=20
> > external_source_identification, such as; the organization =
and=20
</FONT><BR><FONT size=3D2>> > > > date/time.</FONT> =
<BR><FONT=20
size=3D2>> > > ></FONT> <BR><FONT size=3D2>> > > =
> This=20
approach is compatible with re-using classification,</FONT> <BR><FONT=20
size=3D2>> > reference</FONT> <BR><FONT size=3D2>> > > =
> data=20
and is straight forward (to me at least!).</FONT> <BR><FONT =
size=3D2>> >=20
> ></FONT> <BR><FONT size=3D2>> > > > To be used,=20
external_instance_pattern would need to be a viable</FONT> <BR><FONT=20
size=3D2>> > > > option in the extensible select lists =
when doing an=20
assignment -</FONT> </P>
<P><FONT size=3D2>> > > > e.g. when assigning a task, =
document,=20
activity,</FONT> <BR><FONT size=3D2>> > observation etc.. =
to</FONT>=20
<BR><FONT size=3D2>> > > > the item of interest being=20
referenced.</FONT> <BR><FONT size=3D2>> > > ></FONT> =
<BR><FONT=20
size=3D2>> > > > This may even help interoperability & =
even=20
allow us to span data</FONT> <BR><FONT size=3D2>> > > > =
over several=20
files (if needed).</FONT> <BR><FONT size=3D2>> > > =
></FONT>=20
<BR><FONT size=3D2>> > > > Just something to think about- =
but=20
comments welcome!</FONT> <BR><FONT size=3D2>> > > ></FONT> =
<BR><FONT=20
size=3D2>> > > > regards,</FONT> <BR><FONT size=3D2>> =
> >=20
> Tim</FONT> <BR><FONT size=3D2>> > > ></FONT> =
<BR><FONT=20
size=3D2>> > > ></FONT> <BR><FONT size=3D2>> > > =
></FONT>=20
<BR><FONT size=3D2>> > > ></FONT> <BR><FONT size=3D2>> =
> >=20
></FONT> <BR><FONT size=3D2>> > > ></FONT> <BR><FONT =
size=3D2>>=20
></FONT> <BR><FONT size=3D2>> ></FONT> <BR><FONT =
size=3D2>>=20
></FONT> </P><BR><BR><BR>
<P><B><FONT size=3D1>DISCLAIMER: ***SECURITY LABEL: NOT PROTECTIVELY=20
MARKED*** The information in this message is confidential =
and may=20
be legally privileged. It is intended solely for the addressee. =
Access=20
to this message by anyone else is unauthorised. If you are not =
the=20
intended recipient, any disclosure, copying, or distribution of the =
message,=20
or any action or omission taken by you in reliance on it, is =
prohibited and=20
may be unlawful. Please immediately contact the sender if you =
have=20
received this message in error. This e-mail originates from LSC Group. =
Registered in England & Wales No 2275471 Registered Office: =
Devonport=20
Royal Dockyard, Devonport, Plymouth, PL1 4SG=20
</FONT></B></P><BR></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_0056_01C4A149.C5C3BB00--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]