Jack, sorry to be dredging this post up from as long as 4 days ago.
(Some more recent ones from you are also still outstanding, but I'll get
to them, I hope.) (01)
And now to add to the discourtesy, this reply is merely a further
partial holding operation on your questions. As regrettably still so
often the case, I must ask for more patience until I get the fuller
story up on the wiki. (02)
But I do believe it will be worth the wait! (03)
Briefly for now: (04)
The architecture I spoke of below is that underlying the proposed
"Ontology Chemistry" ecosystem, for which see the provisional and very
incomplete wiki page at
http://ontolog.cim3.net/cgi-bin/wiki.pl?ChristopherSpottiswoode/OntologyChemistry_WorkingDraft.
I usually call the architecture itself "The Mainstream Architecture for
Common Knowledge". (05)
As I said below, I believe it takes full account of the issues that "4D"
of the usual "3D/4D" distinction addresses. That includes, for example,
the requirements you ask about, namely wear and failure. So let's see
if I have understood the implications of your question. (06)
Wear rate is not merely a passive predicate, it can as such also be a
parameter in a simulation, and the AOS (or envisaged Application
Operating System as introduced at the link above) as general-purpose
agent can be configured into whatever hypothetical (or "possible world")
finite and possibly distributed configuration of agent instances with
initial conditions you wish (including alternative behaviours) and the
passage of time simulated, with optional user involvement, whether
actual or simulated. User capabilities can likewise be real or
simulated. Plugging in a measurement and logging function, including of
the relevant metadata, is merely another manifestation of standard
plug-and-play application composition. Given the internal database
(which I've already partially coded) and its fully ontologized
framework, with reflective and dynamic self-optimzation, that is easier
and potentially much more efficient than in conventional environments. (07)
A failure event can likewise be caught (in a live environment), or
hypothetically simulated, by the AOS as the event-driven agent that it
is. (08)
What in your picture might I not have understood? Of course, please
don't ask yet to see it actually running! It might however help at this
stage to point out also that the above is pretty much unthinkable (at
least by me...) without the built-in provision for actual behaviour (or
real semantics) specification in this ontologized environment, and that
that ontological basis is also the "secret" (still, but soon no longer
to be) of that vaunted plug-and-play feature. (09)
Note also that many systems cannot be simulated as described above as
fully real hypothetical worlds because they are too abstracted already.
Accounting systems, for example, already have a very abstracted notion
of real time, with time often missing or too highly granular for
realtime simulation. (010)
Many thanks for putting such questions, though, and please feel free to
ask more or add your proper nuances. (Though perhaps better wait until I
have got the fuller picture on the wiki.) (011)
Christopher (012)
----- Original Message -----
From: "Jack Ring" <jring7@xxxxxxxxx>
To: "Ontology Summit 2012 discussion" <ontology-summit@xxxxxxxxxxxxxxxx>
Sent: Monday, January 30, 2012 7:07 PM
Subject: Re: [ontology-summit] System Components (013)
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. (014)
On Jan 30, 2012, at 6:12 AM, Christopher Spottiswoode wrote: (015)
> 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/ (016)
_________________________________________________________________
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/ (017)
_________________________________________________________________
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/ (018)
|