[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [plcs-dex] Classification of type and individual
Sorry for stirring this up again, but I've only just got round to reading the debate.
1) I would expect the same issue to arise between all type/instance models, including Person/Person_type, Organization/Organization_type, Activity/Activity_as_realized - indeed (following Rob's comments in the capability), Activity can be both a type and a planned occurrence, which makes things even more confusing.
2) Say a product_as_individual takes classifications from the product - this is an assertion that the product_as_individual always belongs to the same class as the product it is realized from. However, were we to classify the Product as "airworthy", we would not be allowed to make the same assertion of every individual. This leads to three possibilities:
A) (Some) We apply a rule to every classification of the type Product to say whether it is also a classification of Product_as_individual;
B) (All) We assert every classification of the type Product must also be a valid classification of Product_as_individual, and require every candidate classification which does not meet this rule to be modelled as a property;
C) (None) We assert that not classification of the type Product is a classification of Product_as_individual, and accept the duplication of some classes.
With the exception of State and Condition, we would assert the same of every other type/individual pair.
I do not think we have the ability to do A successfully, and I think that B would cause much confusion, so I would prefer C.
3) One of the reasons for classification not propagating across the type/instance link is that classifications are always done within a context, and the context for the design (the design office) is not the same as that of the individual (the operational environment). State is an exception. State is the product of a set of state variables and a state viewing matrix - here the term "state variables" is synonymous with "variables taken from the context". That is State carries round its context, or alternately, we could have a state data model which differentiates "state-definition" from "state-individual" by classification, although this might be rather confusing [If this is not true, then we have to go back to the product/product-as-individual paradigm.]
Condition can be viewed as a limited state, where only the states "true" and "false" exist, i.e. something that carries its context with it.
Therefore, it would be reasonable for State to inherit the classifications of State_definition.
For these reasons, I do think that Product/Product_as_individual and State_definition/State are not analogous, and should be treated separately.
Sean Barker
ATC Filton
0117 302 8184
-----Original Message-----
From: timturner11@bellsouth.net [mailto:timturner11@bellsouth.net]
Sent: 08 March 2005 12:59
To: Gyllström Leif; plcs-dex@lists.oasis-open.org
Subject: Re: SV: [plcs-dex] Classification of type and individual
*** WARNING ***
This mail has originated outside your organization,
either from an external partner or the Global Internet.
Keep this in mind if you answer this message.
Rob,
I agree - good to get back to the original question.
Leif, your response below leads me to believe that your concern is to do more with the organization & classification of the classes within the RDL / ref data than with the original question, which is another issue (to me) that I will return to.
I think that we should again be consistent in are approach. I think that from the discussion there are needs for ;
Part and Product_as_indivdiual to be classified separately & Leif argues to allow the same for State_definition and Condition.
Back to Leif's earlier point regarding the duplication of classes within the RDL ref data. I would suppose that this might be an inevitability. Perhaps this means we need a network of such classes in the RDL? Just because the realized product has the same classification as that of a design, it does not mean that it has a valid configuration. However, I would also expect to see many classes in the realized products that do not appear under the design configuration and that these require a link back to the classes from the design. Hence the classes either need to be duplicated or networked in some way in the RDL, unless there is a guarrentteed mechanism to access the design artefact & it's own classification to derive this.
Regards,
Tim
>
> From: Gyllström Leif <leif.gyllstrom@aerotechtelub.se>
> Date: 2005/03/08 Tue AM 02:42:16 EST
> To: <plcs-dex@lists.oasis-open.org>
> Subject: SV: [plcs-dex] Classification of type and individual
>
> I would not go so far as to say that no classification of State and Condition should be allowed.
>
> There are may different types of classifications that needs to be assigned to a State and Condition
> from the actual point of view (e.g. subclasses of State_assertion such as Measured_state_assertion or ....).
>
> The point that I tried to make was that we should avoid allowing the same classification hierachy to appear
> as subclasses of more than one PLCS entity. If not, have created many entities for the same thing in PLCS ??
>
> Leif
>
>
> -----Ursprungligt meddelande-----
> Från: Rob Bodington [mailto:rob.bodington@eurostep.com]
> Skickat: den 8 mars 2005 08:15
> Till: plcs-dex@lists.oasis-open.org
> Ämne: 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
> Rob
>
> -------------------------------------------
> Rob Bodington
> Eurostep Limited
> Web Page: <http://www.eurostep.com> http://www.eurostep.com <http://www.share-a-space.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: Tim Turner [mailto:timturner11@bellsouth.net]
> Sent: 07 March 2005 20:30
> To: plcs-dex@lists.oasis-open.org
> Subject: RE: [plcs-dex] Classification of type and individual
>
>
>
> 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)..
>
> -----Original Message-----
> From: Nigel Newling [mailto:nfn@lsc.co.uk]
> Sent: 07 March 2005 10:56
> To: 'plcs-dex@lists.oasis-open.org'
> Subject: FW: [plcs-dex] Classification of type and individual
>
> I have grave reservations about using the term "typical". I will leave to my office colleagues to debate the finer point of change control but I fear the impression of imprecision that the word creates.
>
>
>
> In PLCS we have always had to grapple with the bridge from the design environment to the real world of supporting realised products. In the design world, product definitions go through iterations as the design is improved to eliminate failure modes, enhance functionality and simplify manufacture. As digital data, each iteration can be identified as a new version through the application of a rigorous change control mechanism.
>
>
>
> At some point we actually get round to building a few. Once built, each product takes on a life of its own, able to be referenced back to a design version only if you are lucky ( :-( but remember I am a real world support engineer by trade so forgive the doubt!)
>
>
>
> PLCS must cope with the fact that the as-built version of a realised product behaves differently from a design version. Realised products can always be defined, not necessarily by reference to an identifiable design version but always by identification of actual parts fitted (because you can go and have a look). The differences from the design may or may not be covered by authorised variances (concessions).
>
>
>
> I cannot see what value a "typical" option is adding.
>
>
>
> Nigel
>
> -----Original Message-----
> From: David Price [mailto:david.price@eurostep.com]
> Sent: 07 March 2005 14:31
> To: plcs-dex@lists.oasis-open.org
> Subject: RE: [plcs-dex] Classification of type and individual
>
> Please be careful here. Actual individuals are members of the class defined by their design. However, actual individuals are not necessarily members of all the classes of which their design is a member. Classification is not transitive. I realize that a lot of classification in PLCS replaces subtyping, however that's not true for all PLCS classifications.
>
>
>
> David
>
>
>
>
>
> -----Original Message-----
> From: Rob Bodington [mailto:rob.bodington@eurostep.com]
> Sent: 07 March 2005 13:38
> To: 'Gyllström Leif'; plcs-dex@lists.oasis-open.org
> Subject: RE: [plcs-dex] Classification of type and individual
>
>
>
> Thinking about this a bit more .....
>
> I think that this approach will get really complicated.
>
>
>
> Imagine I have a bike design classified as an "ordinary" bike.
>
> I then build an individual bike from this design.
>
> The individual bike will be classified as an "ordinary" bike.
>
>
>
> I then make a modification to my individual bike, so it is now a "Souped up bike".
>
> The change was not a change to a design, but to my individual bike so "Souped up bike"
>
> is not a classification of the design, but a classification of my individual bike.
>
>
>
>
>
> So can we be sure that:
>
> a) all classifications of the typical apply equally to the actual thing being classified.
>
> b) If we classify a typical will that classification apply to all of the actual things
>
>
>
> I'm not convinced (yet)
>
>
>
> Regards
> Rob
>
> -------------------------------------------
> Rob Bodington
> Eurostep Limited
> Web Page: <http://www.eurostep.com> http://www.eurostep.com <http://www.share-a-space.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: Gyllström Leif [mailto:leif.gyllstrom@aerotechtelub.se]
> Sent: 07 March 2005 13:11
> To: plcs-dex@lists.oasis-open.org
> Subject: SV: [plcs-dex] Classification of type and individual
>
>
>
> Rob
>
>
>
> I would suggest that we only classify the typical due to the implications that the other approach will have on the reference data library.
>
>
>
> We have agreed that refdata should be regarded as specializations (subclasses) of PLCS Entities. This would mean that an instance of
>
> reference data would have to be defined for both the typical and the actual thing. Yes, OWL will allow for a class being a subclass of
>
> several Entity classes. But I'm convinced that this will cause confusion and classes for typical will only appear as specializations of
>
> the entity representing the actual etc.
>
>
>
> I'm stongly in favor of keeping the separation of typical and actual,and exchange both instances, and have a consistent approach
>
> throughout PLCS.
>
>
>
> Regards
>
>
>
> Leif
>
> -----Ursprungligt meddelande-----
> Från: Rob Bodington [mailto:rob.bodington@eurostep.com]
> Skickat: den 18 februari 2005 17:27
> Till: plcs-dex@lists.oasis-open.org
> Ämne: [plcs-dex] Classification of type and individual
>
> Hi
>
> In PLCS we make a distinction between a typical something and an actual something.
>
>
>
> E.g
>
> Part and product_as_realized
>
> State_definition and State_observed
>
>
>
> We are also able to classify things.
>
> E.g.
>
> A Part is classified as a Bicycle
>
> A State_definition is classified as a Fault state.
>
>
>
> The question is, if I classify the typical things, do I need to classify the actual thing?
>
>
>
> For example, if I classify a Part as being a bicycle, do I need to classify the Product as realised as representing my bike, as a being a bicycle, or do I just classify the Part?
>
>
>
> Similarly for states.
>
>
>
> If we impose a rule that you only classify the typical - not the actual, then you will always have to exchange both the typical and the actual.
>
> Which may be overkill.
>
>
>
> Any thoughts?
>
> Regards
> Rob
>
> -------------------------------------------
> Rob Bodington
> Eurostep Limited
> Web Page: <http://www.eurostep.com> http://www.eurostep.com <http://www.share-a-space.com> http://www.share-a-space.com
> Email: Rob.Bodington@eurostep.com
> Phone: +44 (0)1454 270030
> Mobile: +44 (0)7796 176 401
>
>
>
>
>
> 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
>
>
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]