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)
|