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] Classification of View_definition_context


The strings are just listing the possible exchange values. The RDL route does the same but allows the list of possibles to expand...
 
However, that aside, and assuming the RDL route, your example would then become either;
 
#230=VIEW_DEFINITION_CONTEXT('application_domain', 'life_cycle_stage', 'part definition');
 
#231=CLASSIFICATION_ASSIGNMENT(#232, (#230), '');
#232=EXTERNAL_CLASS($, 'product life cycle support', $, $);
 
#233=CLASSIFICATION_ASSIGNMENT(#234, (#230), '');
#234=EXTERNAL_CLASS($, 'design', $, $);
 
OR;
 
#230=VIEW_DEFINITION_CONTEXT('', '', 'part definition');
 
#231=CLASSIFICATION_ASSIGNMENT(#232, (#230), '');
#232=EXTERNAL_CLASS($, 'product life cycle support', $, $);
 
#233=CLASSIFICATION_ASSIGNMENT(#234, (#230), '');
#234=EXTERNAL_CLASS($, 'design', $, $);
 
I don't really see the benefit of one over the other (or in expanding from 1 instance to 5 for that matter!).
The former just documents the attribute name (class) which we already know from the model & is therefore, arguably
redundant.
 
Neither case dictates any order in which the assignments should be read in terms of the attributes of #230, other 
than their position in the file, so to remove any ambiguity we probably have to use another mechanism.
 
Although not ideal (semantically), Identification_assignment could be used as in the following ..
 
#230=VIEW_DEFINITION_CONTEXT('', '', 'part definition');
#231=IDENTIFICATION_ASSIGNMENT('application_domain', '', $, (#230));
#232=CLASSIFICATION_ASSIGNMENT(#233, (#231), '');
#233=EXTERNAL_CLASS($, 'product life cycle support', $, $);
 
#234=IDENTIFICATION_ASSIGNMENT('life_cycle_stage', '', $, (#230));
#235=CLASSIFICATION_ASSIGNMENT(#236, (#234), '');
#236=EXTERNAL_CLASS($, 'design', $, $);
 
However, maybe there's a property or attribute classification that's better suited to this.
 
I can't comment on the pilot's usage, so I'll leave that to others.
 
kind regards,
Tim
 
-----Original Message-----
From: Rob Bodington [mailto:rob.bodington@eurostep.com]
Sent: 11 August 2004 12:38
To: plcs-dex@lists.oasis-open.org
Subject: [plcs-dex] Classification of View_definition_context

Hi

I have had a look at Capability (C002):— representing_parts

It talks about View_definition_context

However it implies that we should use strings for specifying the application_domain and life_cycle stage.

E.g.

 

#230=VIEW_DEFINITION_CONTEXT('product life cycle support', 'design', 'part definition');
 
I think that it would be better to use reference data. In other words create OWL sub classes of View_definition_context   – one for Application_domain and one for Life_cycle_stage as shown in the screenshot below.
I have also included the classes from AP214 and the PDM Schema. Apart from the obvious one (Product_life_cycle_support)
 
In the various pilots – what values have people used for these attributes?
Can we standardize on them?
 
It also raises a wider question. Where we have an EXPRESS entity which has a mandatory string attribute, e.g.
ENTITY View_definition_context;
  application_domain : STRING;
  life_cycle_stage : STRING;
  description : OPTIONAL STRING;
END_ENTITY;
 
And we use reference data. What String value should we use?
Should we set it to ‘’ or perhaps the name of the class?
 
If we use the name of the class AND classification then we will be compatible with other STEP parts (albeit at an ARM level)
 

 

 

 

 

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

 



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