SV: [plcs-dex] Representing parts Issue RBN-14

[Gyllström Leif <leif.gyllstrom@aerotechtelub.se>]

Title: Representing parts Issue RBN-14

Nigel

 

Even though there mignt be a resemblance between the two I would still argue the requirement for defining two separate capabilities.

 

The capability 'assigning_observation' adresses the area mainly described within the AP239 module 'Observation'.

 

The capability 'assigning_descriptor' adresses the usage (or should I say the non-usage') of description attributes

for any type of entity.

 

I.E. The capability 'assigning_observation' should use the capability 'assigning_descriptor' for the assignment of

descriptive text, rather than use the Observation.description attribute (which shall be /IGNORE'ed)

 

Regards

 

Leif

-----Ursprungligt meddelande-----
Från: Nigel Newling [mailto:nfn@lsc.co.uk]
Skickat: den 12 augusti 2005 11:01
Till: Gyllström Leif; DEXS-PLCS-OASIS (E-mail)
Ämne: RE: [plcs-dex] Representing parts Issue RBN-14

Leif,

 

Before we set off creating an endless series of extra Capabilities, should we not check what has already been identified as required by specific DEXs. From your description of your proposed 'assigning_descriptor', I see a significant overlap with Capability (C025): assigning_observation, which was always intended to allow the attachment of freeform notes. Can we settle on one or the other?

 

I am leery of allowing multiple descriptions of equal status. It has the potential to create trouble when using AP239 as an integration model. Best practice is to define one as master and make the others subordinate aliases, e.g. 'also known as.. '.

 

Nigel

-----Original Message-----
From: Gyllström 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

 

As Agreed, I'm working on the capability 'assigning_descriptor', which among other things covers

the assignment ocf descriptions, notes, comments etc

 

Regards

Leif

-----Ursprungligt meddelande-----
Från: Tim Turner [mailto:tjt@lsc.co.uk]
Skickat: den 12 augusti 2005 02:08
Till: DEXS-PLCS-OASIS (E-mail)
Ämne: [plcs-dex] Representing parts Issue RBN-14

In the interest of visibility My response & comments to the issue are provided below;

Issue: RBN-14 by Rob Bodington (05-07-27) minor_technical issue

Should assigning_description be used to capture the parts description?

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.

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.

Questions for consistency purposes:

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

2. Should attribute_classification also be used to represent the name (see issue RBN-15)?

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

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
* e-mail: tjt@lsc.co.uk <mailto:tjt@lsc.co.uk> Internet: <http://www.lsc.co.uk/>
*
*************************************************************************

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

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