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


Good points Dave. I'm all for openess & free standards.
 
However, the issues remain and are arguably more complex than when dealing with just an AP.
 
regards,
Tim
-----Original Message-----
From: David Price [mailto:david.price@eurostep.com]
Sent: 12 August 2004 11:23
To: plcs-dex@lists.oasis-open.org
Subject: RE: [plcs-dex] Classification of View_definition_context

On Tim’s last concern about access to and standardization of the RDL, isn’t that why we’re talking on an OASIS exploder?

 

The benefit of OASIS is that its standards are free and on the Web. Isn’t that, by definition, a better approach than making ISO standards out of string values?

 

Cheers,

DP

 

-----Original Message-----
From: tim turner [mailto:timturner11@bellsouth.net]
Sent: 12 August 2004 15:46
To: 'Rob Bodington'; plcs-dex@lists.oasis-open.org
Subject: RE: [plcs-dex] Classification of View_definition_context

 

I don't necessarily disagree.

 

However, playing the role of a devil's advocate (occaisonally), I would suggest that this approach has a number of possible flaws;

 

0. the solution below is potentially ambiguous since the same information is present in more than 1 place (redudancy?) & people tend to use the most simple approach when faced with simple/complex route to the same answer. (e.g. people may just read the attr vals instead of going to the RDL). Placing the values in the VDC adds no value if you still have to traverse the RDL to achieve the same.

 

1. the assumption is that all systems are capable of reasoning through/over an RDL (to identify class super types)

 

2. the assumption that everyone has access to the same RDL, RDL version etc.,

 

Most of which can be overcome in various ways within the context of exchange partners/scenarios and more software. Though how do we ensure each user's software navigates the RDL in the same way - or perhaps these would be free utilities provided by the RDL manager?

 

In fact, all other things aside, I think the atttribute classification is the best solution since it clearly identifies both the external_class and the attribute being classified. Using this method is unambiguous without the need (or s/w) to be able to traverse across a RDL (in addition to the lookup). However, I'd remove the values from the VDC instance for the same reasons stated above. 

 

Of separate, wider concern I think, is that what used to be part of the AP standard is now shifting to the realm of an RDL (which I wouldn't necessarily disagree with), but which raises it's own questions about how the RDL is standardised and managed. Again this can be overcome within the context of exchange partners, but raises the doubt of accuracy across distributed systems that may not have access to the same RDL, or how the evolving nature of an RDL is to be reconciled with the need for Long Term Data Retention/Archiving for future use of exchange files. I guess when the RDL is complete it will also be archived with the exchange files, along with all the software since owl may not be still around in 20 years time.

 

kind regards,

Tim

-----Original Message-----
From: Rob Bodington [mailto:rob.bodington@eurostep.com]
Sent: 12 August 2004 03:34
To: plcs-dex@lists.oasis-open.org
Subject: RE: [plcs-dex] Classification of View_definition_context

I agree with David.

The strings are nearly always hidden in mapping paths or usage guides etc. I think that the RD is a better approach. The allowable string values are documented and agreed and stored in one place – the RDL.  After all, we have been advocating the approach in PLCS since the beginning.

 

(BTW – this email contains diagrams – if anyone does not receive the diagrams please let us know as I am not sure if I am using too much Microsoft  specific stuff to create the email)

 

I would advocate using both strings and classification as shown in the diagram below

You can deduce which classification is the application_domain and which is the life_cycle stage by looking at the super classes in the reference data. 

The only rule is that the entity string values should be the same as the class names.

 

We do have the option to use attribute classification as shown in the diagram below. However, I am not sure what benefit this brings as we can achieve exactly the same affect using classification assignment as described above. Hence we agreed a while back that we would avoid using attribute classcifcation – this is documented in Capability (C010): assigning_reference_data

 

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

-----Original Message-----
From: David Price [mailto:david.price@eurostep.com]
Sent: 11 August 2004 21:36
To: plcs-dex@lists.oasis-open.org
Subject: RE: [plcs-dex] Classification of View_definition_context

 

All,

 

I’d say one benefit to the RD approach is that users can debate and agree on domain and life cycle stage and then, most importantly, easily *share* that agreement. Attribute value constraints could well be hidden in text or EXPRESS rules or not agreed at all if RD isn’t used. Even if pilots decide agree to use the attribute values for some reason (e.g. they only ever use one domain and life cycle stage), publishing the RD as the source of the standard values is still useful.

 

Cheers,

David

 

-----Original Message-----
From: tim turner [mailto:timturner11@bellsouth.net]
Sent: 11 August 2004 21:18
To: 'Rob Bodington'; plcs-dex@lists.oasis-open.org
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]