Re: [ontology-summit] System Components

[Giancarlo Guizzardi <gguizzardi@xxxxxxxxx>]

Matthew,

Pump 101 story illustrates interesting points which are very recurrent also in Organizations

and other social entities (e.g., societies). For instance, one can argue that the case of (instances of) social roles present many of the same characteristics.

One quick point:

An alternative to this issue can be thought of by considering qua individuals (e.g.http://www.loa.istc.cnr.it/Papers/KR04MasoloC.pdf) or perspectiles http://www.loa.istc.cnr.it/Papers/BottazziFerrarioPerspectilesEuroCogSciv.pdf). 

By the way, this view does not necessarily require the introduction of "additional" ontological entities, since qua individuals can be seen as complex tropes

(e.g, http://www.loa.istc.cnr.it/Papers/FS805MasoloC.pdf).

The most important point: this is indeed an important characteristic to be considred on systems and worth a discussion.

best,

Giancarlo 

 

 

On Mon, Jan 30, 2012 at 11:12 AM, Christopher Spottiswoode <cms@xxxxxxxxxxxxx> wrote:

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/

_________________________________________________________________
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/     (01)