[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
-----Original Message-----
From: Gyllstr=F6m Leif [mailto:leif.gyllstrom@aerotechtelub.se]
Sent: 12 August 2005 09:24
To: Tim Turner; DEXS-PLCS-OASIS (E-mail)
Subject: SV: [plcs-dex] Representing parts Issue RBN-14
All
=20
As Agreed, I'm working on the capability 'assigning_descriptor', which =
among
other things covers
the assignment ocf descriptions, notes, comments etc
=20
Regards=20
Leif
-----Ursprungligt meddelande-----
Fr=E5n: Tim Turner [mailto:tjt@lsc.co.uk]
Skickat: den 12 augusti 2005 02:08
Till: DEXS-PLCS-OASIS (E-mail)
=C4mne: [plcs-dex] Representing parts Issue RBN-14
In the interest of visibility My response & comments to the issue are
provided below;=20
Issue: RBN-14 by Rob Bodington (05-07-27) minor_technical issue=20
Should assigning_description be used to capture the parts description?=20
TJT Response: just as a name may change over time, so might the
description. In addition, multiple descriptions of the same part may be
applicable.
I could not find a "assigning_description" capability or entity in
Dexlib/PLCS anywhere. However, there is a skeletal =
representing_description
capability (completely undeveloped) which suggests to use =
"document/version
and document_assignment to represent descriptions that are assigned to =
items
such as part." I assume that the suggestion is to document the =
description
within the document to be referenced. However, this means that the
description is not available to a processor until the document is =
opened and
the contents extracted. A document (a subtype of product) also has it's =
own
description attribute which would require another document to describe =
it.
A document needs a document_version and document_definition which also =
have
a description attribute, which makes for a potentially circular & =
ambiguous
usage. This makes me feel uncomfortable recommending or accepting this =
route
without clearer justification.
In my mind that leaves 2 options; either assigning_identification or
attribute_classification.=20
1. The description can be specified through C001 - =
assigning_identification
where the identification_assignment.name carries the product =
description,
and the corresponding external_class_library.class_name is set to
"Description". However, this is not so elegant a solution.
2. The description could also be specified through =
attribute_classification
where the attribute_classification.attribute_name carries the product
description, and the corresponding =
attribute_classification.allowed_value,
which can be an instance of external_class_library - whose .class_name
attribute can be set to "Description", whilst the classified_entity (a
classified_attribute_select type) has products (& most other entities) =
in
scope.=20
Questions for consistency purposes:=20
1. Is the Organization specifying the description required to be =
identified
(according to current C001 template, the Organization assigning the =
name is
also required to be specified)?=20
2. Should attribute_classification also be used to represent the name =
(see
issue RBN-15)?=20
3. Aside from this, if there are multiple names & descriptions assigned
(thru some means), how should should we know which is the most relevant =
or
intended for everday use? Is there a relationship between a name and a
description which should be kept together somehow?
regards,=20
Tim=20
Note: attribute_classification has been suggested for other uses in the =
past
but has so far (to my knowledge) still not being advocated for use in =
PLCS
(in general).
************************************************************************=
*
*
* Mr. Timothy J. Turner BSC(Hons) MSc, MBCS
* Executive Consultant, Enterprise Integration Technologies
* LSC Group, Lincoln House, Wellington Crescent, Fradley Park, =
LICHFIELD,
Staffordshire WS13 8RZ, ENGLAND
* UK Switchboard: +44-1543 446800 Fax: +44-1543 446900
* US Direct telephone: +1-803-327 2829 (Rock Hill)
* Mobile (US) telephone: +1-843-4759179
* Mobile (UK) telephone: +44-7885-393225=20
* e-mail: tjt@lsc.co.uk < mailto:tjt@lsc.co.uk <mailto:tjt@lsc.co.uk> >
Internet: < http://www.lsc.co.uk/ <http://www.lsc.co.uk/> >
*
************************************************************************=
*=20
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=20
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=20
------_=_NextPart_001_01C59F1C.669245D0
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>Representing parts Issue RBN-14</TITLE>
<META content=3D"MSHTML 6.00.2800.1505" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D996454908-12082005>Leif,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D996454908-12082005></SPAN></FONT> </DIV>
<DIV><FONT size=3D2><SPAN class=3D996454908-12082005><FONT face=3DArial =
color=3D#0000ff>Before we set off creating an endless series of extra=20
Capabilities, should we not check what has already been identified as =
required=20
by specific DEXs. From your description of your proposed=20
'assigning_descriptor', I see a significant overlap with =
Capability (C025):=20
assigning_observation, which was always intended to allow the =
attachment of=20
freeform notes. Can we settle on one or the =
other?</FONT></SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D996454908-12082005></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D996454908-12082005>I am=20
leery of allowing multiple descriptions of equal status. It has the =
potential to=20
create trouble when using AP239 as an integration model. Best practice =
is to=20
define one as master and make the others subordinate aliases, e.g. =
'also known=20
as.. '.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D996454908-12082005></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D996454908-12082005>Nigel</SPAN></FONT></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
<DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
size=3D2>-----Original Message-----<BR><B>From:</B> Gyllstr=F6m Leif=20
[mailto:leif.gyllstrom@aerotechtelub.se]<BR><B>Sent:</B> 12 August =
2005=20
09:24<BR><B>To:</B> Tim Turner; DEXS-PLCS-OASIS =
(E-mail)<BR><B>Subject:</B>=20
SV: [plcs-dex] Representing parts Issue RBN-14<BR><BR></FONT></DIV>
<DIV><SPAN class=3D753502208-12082005><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>All</FONT></SPAN></DIV>
<DIV><SPAN class=3D753502208-12082005><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D753502208-12082005><FONT face=3DArial =
color=3D#0000ff size=3D2>As=20
Agreed, I'm working on the capability 'assigning_descriptor', which =
among=20
other things covers</FONT></SPAN></DIV>
<DIV><SPAN class=3D753502208-12082005><FONT face=3DArial =
color=3D#0000ff size=3D2>the=20
assignment ocf descriptions, notes, comments etc</FONT></SPAN></DIV>
<DIV><SPAN class=3D753502208-12082005><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D753502208-12082005><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Regards <BR></FONT></SPAN></DIV>
<DIV><SPAN class=3D753502208-12082005><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Leif</DIV></FONT></SPAN>
<BLOCKQUOTE>
<DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
size=3D2>-----Ursprungligt meddelande-----<BR><B>Fr=E5n:</B> Tim =
Turner=20
[mailto:tjt@lsc.co.uk]<BR><B>Skickat:</B> den 12 augusti 2005=20
02:08<BR><B>Till:</B> DEXS-PLCS-OASIS (E-mail)<BR><B>=C4mne:</B> =
[plcs-dex]=20
Representing parts Issue RBN-14<BR><BR></FONT></DIV>
<P><FONT face=3DArial size=3D2>In the interest of visibility My =
response &=20
comments to the issue are provided below;</FONT> </P>
<P><B><FONT face=3DArial size=3D2>Issue: RBN-14 by Rob Bodington =
(05-07-27)=20
minor_technical issue </FONT></B></P>
<P><FONT face=3DArial size=3D2>Should assigning_description be used =
to capture=20
the parts description?</FONT> </P><BR>
<P><B><FONT face=3DArial size=3D2>TJT =
Response:</FONT></B> <FONT face=3DArial=20
size=3D2> just as a name may change over time, so might the =
description. In=20
addition, multiple descriptions of the same part may be=20
applicable.</FONT></P>
<P><FONT face=3DArial size=3D2>I could not find a =
"assigning_description"=20
capability or entity in Dexlib/PLCS anywhere. However, there is a =
skeletal=20
representing_description capability (completely undeveloped) which =
suggests=20
to use "document/version and document_assignment to represent =
descriptions=20
that are assigned to items such as part." I assume that the =
suggestion is to=20
document the description within the document to be referenced. =
However, this=20
means that the description is not available to a processor until =
the=20
document is opened and the contents extracted. A document (a =
subtype of=20
product) also has it's own description attribute which would =
require another=20
document to describe it. A document needs a document_version =
and=20
document_definition which also have a description attribute, which =
makes for=20
a potentially circular & ambiguous usage. This makes me feel=20
uncomfortable recommending or accepting this route without clearer=20
justification.</FONT></P>
<P><FONT face=3DArial size=3D2>In my mind that leaves 2 options; =
either=20
assigning_identification or attribute_classification.</FONT> </P>
<P><FONT face=3DArial size=3D2>1. The description can be specified =
through C001=20
- assigning_identification where the identification_assignment.name =
carries=20
the product description, and the corresponding=20
external_class_library.class_name is set to "Description". However, =
this is=20
not so elegant a solution.</FONT></P>
<P><FONT face=3DArial size=3D2>2. The description could also be =
specified=20
through attribute_classification where the=20
attribute_classification.attribute_name carries the product =
description, and=20
the corresponding attribute_classification.allowed_value, which can =
be an=20
instance of external_class_library - whose .class_name attribute =
can be set=20
to "Description", whilst the classified_entity (a=20
classified_attribute_select type) has products (& most other =
entities)=20
in scope. </FONT></P>
<P><B><FONT face=3DArial size=3D2>Questions</FONT></B><FONT =
face=3DArial size=3D2>=20
for consistency purposes:</FONT> </P>
<P><B><FONT face=3DArial size=3D2>1.</FONT></B><FONT face=3DArial =
size=3D2> Is the=20
Organization specifying the description required to be identified =
(according=20
to current C001 template, the Organization assigning the name is =
also=20
required to be specified)? </FONT></P>
<P><B><FONT face=3DArial size=3D2>2.</FONT></B><FONT face=3DArial =
size=3D2> Should=20
attribute_classification also be used to represent the name (see =
issue=20
RBN-15)?</FONT> </P>
<P><B><FONT face=3DArial size=3D2>3.</FONT></B><FONT face=3DArial =
size=3D2> Aside=20
from this, if there are multiple names & descriptions assigned =
(thru=20
some means), how should should we know which is the most relevant =
or=20
intended for everday use? Is there a relationship between a name =
and a=20
description which should be kept together somehow?</FONT></P>
<P><FONT face=3DArial size=3D2>regards,</FONT> <BR><FONT =
face=3DArial=20
size=3D2>Tim</FONT> </P>
<P><FONT face=3DArial size=3D2>Note: attribute_classification has =
been suggested=20
for other uses in the past but has so far (to my knowledge) still =
not being=20
advocated for use in PLCS (in general).</FONT></P><BR>
<P><FONT face=3D"Times New Roman"=20
=
size=3D2>***************************************************************=
**********</FONT><FONT=20
face=3D"Times New Roman"><BR></FONT><FONT face=3D"Times New Roman"=20
size=3D2>*</FONT><FONT face=3D"Times New Roman"><BR></FONT><FONT=20
face=3D"Times New Roman" size=3D2>* Mr. Timothy J. Turner BSC(Hons) =
MSc,=20
MBCS</FONT><BR><FONT face=3D"Times New Roman" size=3D2>* Executive =
Consultant,=20
Enterprise Integration Technologies</FONT><FONT=20
face=3D"Times New Roman"><BR></FONT><FONT face=3D"Times New Roman" =
size=3D2>* LSC=20
Group, Lincoln House, Wellington Crescent, Fradley Park, LICHFIELD, =
Staffordshire WS13 8RZ, ENGLAND</FONT><FONT=20
face=3D"Times New Roman"><BR></FONT><FONT face=3D"Times New Roman" =
size=3D2>* UK=20
Switchboard: +44-1543 446800 Fax: +44-1543 446900</FONT><BR><FONT=20
face=3D"Times New Roman" size=3D2>* US Direct telephone: +1-803-327 =
2829 (Rock=20
Hill)</FONT><FONT face=3D"Times New Roman"><BR></FONT><FONT=20
face=3D"Times New Roman" size=3D2>* Mobile (US) telephone:=20
+1-843-4759179</FONT><BR><FONT face=3D"Times New Roman" size=3D2>* =
Mobile (UK)=20
telephone: +44-7885-393225</FONT> <BR><FONT face=3D"Times New =
Roman" size=3D2>*=20
e-mail:<U> </U></FONT><U><FONT face=3D"Times New Roman" =
color=3D#0000ff=20
size=3D2>tjt@lsc.co.uk <<A=20
=
href=3D"mailto:tjt@lsc.co.uk";>mailto:tjt@lsc.co.uk</A>></FONT></U><FO=
NT=20
face=3D"Times New Roman" size=3D2> Internet:</FONT><U> <FONT=20
face=3D"Times New Roman" color=3D#0000ff size=3D2><<A=20
href=3D"http://www.lsc.co.uk/"=20
target=3D_blank>http://www.lsc.co.uk/</A>></FONT></U><FONT=20
face=3D"Times New Roman"><BR></FONT><FONT face=3D"Times New Roman"=20
size=3D2>*</FONT><FONT face=3D"Times New Roman"><BR></FONT><FONT=20
face=3D"Times New Roman"=20
=
size=3D2>***************************************************************=
**********</FONT><FONT=20
face=3DArial size=3D2></FONT> </P><BR><BR>
<P><B><FONT face=3DArial size=3D1>DISCLAIMER: ***SECURITY LABEL: =
NOT=20
PROTECTIVELY MARKED*** The information in this message =
is=20
confidential and may be legally privileged. It is intended solely =
for the=20
addressee. Access to this message by anyone else is=20
unauthorised. If you are not the intended recipient, any =
disclosure,=20
copying, or distribution of the message, or any action or omission =
taken by=20
you in reliance on it, is prohibited and may be unlawful. =
Please=20
immediately contact the sender if you have received this message in =
error.=20
This e-mail originates from LSC Group. Registered in England & =
Wales No=20
2275471 Registered Office: Devonport Royal Dockyard, Devonport, =
Plymouth,=20
PL1 4SG </FONT></B></P><BR></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>
<BR>
<BR>
<P><B><FONT SIZE=3D1 FACE=3D"Arial">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 </FONT></B></P>
<BR>
<BR>
------_=_NextPart_001_01C59F1C.669245D0--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]