[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [plcs-dex] Classification of type and individual
OK – I think that we should get back to the original specific question.
We have: State_defnition and State Condition and Condition_evaluated Part and Product_as_individual.
Should we only allow classification of the definition, e.g. State_definition Condition Part With no classification of State, Condition_evaluated, Product_as_individual permissible. Instead, the classification is derived by following the links back from State, Condition_evaluated, Product_as_individual to the definition. In the case of State the link is via State_assertion or State_assement to State_defnition
In the case of Condition, the link is via the condition attribute to Condition_evaluated
In the case of Product_as_individual via Product_design_to_individual
I think that only State_definition Condition should be classified as State and Condition_evaluated have to be individuals of a defined State or Condition
I think that Part and Product_as_indivdiual should be classified separately.
Regards ------------------------------------------- -----Original Message-----
I also do not like to start introducing more (loaded) terminology into the forum - so please lets stick to those already in use (e.g. design, planned and realized)! Of course we distinguish between a design & the (many) products relized from it.
The discussion on the classification of the design being *inherited* in some way by the realized (& I presume the planned) products in focus is mute if the design is ever likely to be separated from the exchange of the product itself. In other words, I do not believe that we will always want to exchange both the design & the realizaed product at the same time.
It is of course possible to reference the design when exchanging a realized product, but this assumes that the design is available, which again may not be true.
The realized product may also become out of sync (as it were) with the configuration allowed by the design authority, so it would be somewhat naive to assume that a realized product matches that of the design configuration. Remember those phrases on the seal of some products... "by removing this cover plate you revoke all warranty to the product should it then fail.."? This is the OEM's way of saying only the design configuration (options) are supported.
I admit that changes to the configuration in the field happens all the time, but how can we anticipate these changes and the reference data required to support them? I don't think it is possible to cater for every future possible classification in advance (nor should we try), but perhaps we should provide the basic original classification (initial?) and some mechanism for any additional classifications. This, I think, is a point that needs to be agreed or an alternative way suggested. However, this raises the question of how to indicate the initial versus the additional classification? The PDM schema has a related issue with context which is resolved by having a distinction between an initial_context and a set of additional_contexts. How the additional classifications should be organised in PLCS is something we need to devise.
regards, Tim
NB by *inherited* I mean thru the use of product_planned_to_realized, product_design_to_individual etc)..
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]