ontology-summit
[Top] [All Lists]

Re: [ontology-summit] System Components

To: Ontology Summit 2012 discussion <ontology-summit@xxxxxxxxxxxxxxxx>
From: Jack Ring <jring7@xxxxxxxxx>
Date: Mon, 30 Jan 2012 10:07:25 -0700
Message-id: <E4FD5493-5DDF-4C11-95CE-3B75B4B70341@xxxxxxxxx>
CS, This is interesting and important. Looking forward to CS's presentation in 
Feb 2 session.
It might be useful to note that the "or equivalent" tag in many specifications 
is a cause of many problems because an alternative physical part often is not 
equivalent in ALL attributes. 
Also, pls explain how the wear of a part or probability of failure is described 
without 4D representation.    (01)

On Jan 30, 2012, at 6:12 AM, Christopher Spottiswoode wrote:    (02)

> Matthew, many thanks for your trouble.
> 
> You will see how you have provided me with a handy occasion for touching
> on a couple of key points of the architecture I have long been trying to
> describe here.  The fuller (and hopefully better...) exposition will be
> in the material I have been preparing for submission asap for
> discussion, hopefully in time to contribute to the Summit, otherwise on
> the Forum.
> 
> So at this stage perhaps it's better to continue our debate in this
> thread only if there are very specific points you need to make now, for
> immediate Summit purposes, beyond kindly correcting and educating me? 
> Then once I've sketched the fuller picture perhaps we can return to the 
> problems you may still see here?
> 
> Now please jump to my more detailed comments inserted below.
> 
> ----- Original Message ----- 
> From: "Matthew West" <dr.matthew.west@xxxxxxxxx>
> To: "'Ontology Summit 2012 discussion'"
> <ontology-summit@xxxxxxxxxxxxxxxx>
> Sent: Sunday, January 29, 2012 9:15 PM
> Subject: Re: [ontology-summit] System Components
> 
> 
> Dear Christopher,
> 
> That is exactly the problem I mean, this kind of interpretation.
> 
> CS:  And I took your bait because I sensed that it might turn into an
> opportunity for me.
> 
>> Does it not dissolve if you distinguish between SKU_S3556 as an actual
>> physical part, with its individual characteristics and history, on the
>> one hand, and on the other hand P101 as a virtual placeholder for a
>> pump, with its position, connections, physical requirements and system
>> functions.  Then SKU_S3556 isInPlace P101.  Not so?
> 
> MW: The whole point is that a system component is not virtual. You can't
> kick something virtual. It is physical in the same way that the
> installed pump is, it just has a different pattern of existence, which
> seems to be beyond most ontologists.
> 
> CS:  Nor would I normally use the word "virtual" here.  I used it merely
> in trying to spell out the distinction that engineers and other normal
> people usually make automatically in a system specification context,
> without needing it spelt out.
> 
> CS:  Kickability?  You can't kick a pump from a Bill-of-Materials or BOM
> explosion either, and P101 at plan stage is at least the same kind of
> pump, or "pump-requirement", if you wish, even though "P101" or even
> P101 may later be used in referring to the actual pump installed at any
> given time (i.e. "P101" as a mere label, P101 as the fuller entity at
> that point in the system).
> 
> CS:  Certainly, a requirement for a pump with given specs is a different
> kettle of fish from an actual pump.  Engineers know that too, and quite
> possibly better than the unnamed ontologists you have in mind!
> 
>> 
>> There is doubtless a more usual set of nouns and verbs that Mechanical
>> Engineers habitually use for such situations, but some such set of
>> categories or types seems a starter move in a workable direction.
> 
> MW: The usual language is that S3556 is installed as P101, indicating
> temporary identity the two have.
> 
> CS: Such temporary identities are indeed a key feature of my
> architecture too.  I have taken Multiple Inheritance, and even dynamic
> MI, as a requirement for representing our dynamically-multi-context
> conscious existences.  So I have no problem whatever with the language
> you use there, as one way of handling the situation, if the engineers on
> the ground are happy with it.  I've no problem either with using any
> alternative (I am aware of) which the design and planning engineers
> might prefer.
> 
>> There are the usual conventional ways in which the final S-P fact
>> above can easily be given its 4D or temporal aspects.
> 
> MW: In 4D it is a breeze. The system component consists of the temporal
> parts of the things installed whilst they are installed. You have both
> the pattern and the physicality required. In 3D you have to admit a new
> kind of particular.
> 
> CS:  Quite frankly, I have never had the need to make the 3D/4D
> distinction so often made in "ontological" circles.  On the other hand,
> in my architecture I have long insisted - even since 1977, years before
> "ontology" was ever used in IT - on what I already then referred to,
> albeit loosely, as the ever-present "time component of data".  So of
> course the respective temporal aspects of S3556 and P101 are easily and
> naturally handled.  Catering for entity life-histories and periods of
> applicabliity of BOM items, is a response to classic use cases in this 
> area, as you know well enough yourself.  They are no great problem to 
> handle in my architecture either, in a way that I believe is indeed 
> usefully presented as fully ontological.
> 
>> 
>> Or is the problem you've in mind deeper than merely the
>> "a pump" / "the pump" distinction?
> 
> MW: It is certainly nothing to do with "a pump"/"the pump".
> 
> CS:  Here's how my question related to the preceding content:  P101 very
> much represents a requirement for "a pump" with the given
> specifications, maybe including tolerances, and S3556 is "the pump"
> actually installed, with its actual parameters, maybe including
> measurement accuracies.  The indefinite article also well matches the
> indefinite "1", as in "any 1", in the "1 pump" from the BOM explosion.
> Then as I've said, if the technicians then use "P101" to denote S3556,
> they're of course welcome to do so.  Dynamic MI as introduced above
> can - I believe - naturally handle any identity issues that ontologists
> might raise.
> 
> CS:  Perhaps we can together work through the associated detail when
> I've got the body of my main story online?
> 
> CS:  Regards,
> CS:  Christopher
> 
> Regards
> Matthew West
> 
> Information  Junction
> Tel: +44 1489 880185
> Mobile: +44 750 3385279
> Skype: dr.matthew.west
> matthew.west@xxxxxxxxxxxxxxxxxxxxxxxxx
> http://www.informationjunction.co.uk/
> http://www.matthew-west.org.uk/
> 
> This email originates from Information Junction Ltd. Registered in
> England
> and Wales No. 6632177.
> Registered office: 2 Brookside, Meadow Way, Letchworth Garden City,
> Hertfordshire, SG6 3JE.
> 
> 
>> 
>> Regards,
>> Christopher
>> 
>> ----- Original Message -----
>> From: "Matthew West" <matthew.west@xxxxxxxxxxxxxxxxxxxxxxxxx>
>> To: "'Ontology Summit 2012 discussion'"
>> <ontology-summit@xxxxxxxxxxxxxxxx>
>> Sent: Sunday, January 29, 2012 1:48 PM
>> Subject: [ontology-summit] System Components
>> 
>> 
>> Dear Colleagues,
>> 
>> Last Thursday I complained that most ontologies do not give adequate
>> treatment to what I call system components, and if ontology is going
>> to gain traction within the systems world, it needs to get a better 
>> understanding of this central idea in systems engineering.
>> 
>> I illustrated the issue by telling the (simplified) life story of a
>> system component: the pump, P101, at the bottom of a distillation
>> column. Here is its story.
>> 
>> The designer creates a drawing of the distillation column including at
>> the bottom of the column a pump to pump away the column bottoms. He
>> labels it P101, decides that one pump will be sufficient, and gives
>> the specification for the pump in terms of Net Positive Suction Head, 
>> differential head, flow rate, materials of construction, and many 
>> other things.
>> 
>> The construction engineer picks up the drawing and specification and
>> notices he has to install a pump as P101. Fortunately, he has a pump
>> in stock from a previous project, that has been in stores unused for 5 
>> years which exactly meets the specification. On it is stamped Serial 
>> No S3556.
>> 
>> The designer and the Operator comes to see the pump be installed, and
>> once the connections are made, he gives the pump a friendly kick and
>> says to the construction engineer "It's good to see P101 realized at
>> last". The construction engineer says in return "Yes, and it's good to
>> get S3556 off my hands at last." He turns to the operator and says
>> "Why don't we change your drawings to show S3556 instead of P101?" The 
>> operator says "No, don't do that, it's a replaceable part, and one day 
>> another pump will be put there, and I don't want to have to change all 
>> the drawings and other documentation that refers to P101 each time it 
>> is replaced, as far as I am concerned it's the same pump whatever is 
>> installed there."
>> 
>> Some time later the pump breaks down and needs to be taken back to the
>> workshop. The maintenance engineer says to the operator "Hi, can I
>> take S3556 installed as P101 back to the workshop?" The operator 
>> replies "Sure, but what am I supposed to do without my P101? If it 
>> does not exist I cannot operate my distillation column." The 
>> maintenance engineer responds, "I understand. We have another pump 
>> S4567, that meets the same specification as P101. We'll replace S3556 
>> with it and you will only  be without P101 for a few hours. I don't 
>> understand how you can continue to call it P101 though when all the 
>> parts have changed at once." The operator replies "I don't care about 
>> that. What I care about is what is connected in my system to pump the 
>> liquid from the bottom of the column.  As long as it does that, it is 
>> P101 to me."
>> 
>> Later the distillation column is demolished. The operator says, "A sad
>> end, I was very fond of P101, but it is no more." The demolition
>> engineer says, "Yes indeed. Fortunately, we can take S4567 and use it
>> on another plant."
>> 
>> It's probably worth summarising the key characteristics of a system
>> component:
>> - It comes into existence the first time it is installed
>> - It is identical to the equipment items installed, whilst they are 
>> installed (but not before or after).
>> - It can survive complete replacement of all its parts at once.
>> - It can survive periods of non-existence.
>> - It ceases to exist when the system it is a component of ceases to 
>> exist.
>> 
>> This is clearly rather different from the life of ordinary physical
>> objects.  However, relatively few ontologies recognise that such
>> things exist.  Many try to fob system components off as being classes, 
>> or abstract individuals, though these clearly do not have the required 
>> characteristics.
>> 
>> Ontologists need to step up to the mark here and provide proper
>> recognition for system components.
>> 
>> Regards
>> 
>> Matthew West
>> Information  Junction
>> Tel: +44 1489 880185
>> Mobile: +44 750 3385279
>> Skype: dr.matthew.west
>> matthew.west@xxxxxxxxxxxxxxxxxxxxxxxxx
>> http://www.informationjunction.co.uk/
>> http://www.matthew-west.org.uk/
>> 
>> This email originates from Information Junction Ltd. Registered in
>> England and Wales No. 6632177.
>> Registered office: 2 Brookside, Meadow Way, Letchworth Garden City,
>> Hertfordshire, SG6 3JE.
>> 
>> 
>> 
>> 
>> 
>> _________________________________________________________________
>> Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
>> Subscribe/Config:
>> http://ontolog.cim3.net/mailman/listinfo/ontology-summit/
>> Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
>> Community Files: http://ontolog.cim3.net/file/work/OntologySummit2012/
>> Community Wiki:
>> http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2012
>> Community Portal: http://ontolog.cim3.net/wiki/
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> _________________________________________________________________
>> Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
>> Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-
>> summit/
>> Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
>> Community Files: http://ontolog.cim3.net/file/work/OntologySummit2012/
>> Community Wiki: http://ontolog.cim3.net/cgi-
>> bin/wiki.pl?OntologySummit2012
>> Community Portal: http://ontolog.cim3.net/wiki/
> 
> 
> _________________________________________________________________
> Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
> Subscribe/Config:
> http://ontolog.cim3.net/mailman/listinfo/ontology-summit/
> Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
> Community Files: http://ontolog.cim3.net/file/work/OntologySummit2012/
> Community Wiki:
> http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2012
> Community Portal: http://ontolog.cim3.net/wiki/
> 
> 
> 
> 
> _________________________________________________________________
> Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/   
> Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/  
> Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
> Community Files: http://ontolog.cim3.net/file/work/OntologySummit2012/
> Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2012  
> Community Portal: http://ontolog.cim3.net/wiki/     (03)


_________________________________________________________________
Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/   
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/  
Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
Community Files: http://ontolog.cim3.net/file/work/OntologySummit2012/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2012  
Community Portal: http://ontolog.cim3.net/wiki/     (04)
<Prev in Thread] Current Thread [Next in Thread>