From: Pat Hayes
On Jan 29, 2009, at 1:22 PM, Schiffel, Jeffrey A wrote:
> > Jeff:
> > I suggest that the behaviors among components are better understood
if model as
> > hierarchies of commands and constraints. (01)
> PatH:
> What exactly do you mean by a 'command' here? Do you mean a program?
Jeff:
No, I don't. Perhaps I should have written, "request," or "request for
service." The request may or may not be accompanied by a parameter. The
requestor is blind to how the request is satisfied. The provider is
blind to the reason for the request. (02)
PatH:
Interesting. OK, so what you were saying, above, is that behaviors are
better understood if modeled as hierarchies of requests (in the above
sense) and constraints. Right? I confess that is not a way of thinking
that immediately jumps to my mind, but Im sure one could attempt to
describe it in a ontology. One of the issues I can see immediately is
how to describe a parameter adequately. Can there be situations where a
parameter is left partly unspecified and the servicing of the request
fills in missing detail? (As in a query to s database, for example.)
Because if so, parameter binding will have to be described in rather
painful detail in a logical description. (03)
------------------------------- (04)
Jeff sez:
That's about it. The reason I suggest this is because of one of the
purposes of an engineered system. It is to provide some behavior to the
user. The system level behavior emerges from the individual behaviors of
the subsystems, all the way to the bottom components. The system level
behavior exists only at the system level; no subsystem or component can
provide it. It arises from the coordinated activities of the
subsystem/component behaviors. (05)
If not understood, then a system level behavior (or, more accurately, a
family of system behaviors) will emerge unexpectedly. This emergence may
be good, but is more likely to be adverse. (06)
Passing a parameter is not a strict requirement. It may be the subsystem
or component providing the service needs no information to perform its
duty. That is, outputs do not always require inputs. In either case,
completion of the service results in a change in state of the overall
system. (07)
In the normal course of systems development, the initial parameters may
very well be unspecified. For detailed designs the parameters must be
precisely defined. (In the real world of budget and schedule
constraints, this doesn't always happen. It leads to extended time in
testing, extra cost, and unhappy customers.) The need for a logical
description is met in by items like interface control documents and
interface specification documents. The point you make is well-taken:
many problems in getting an engineered system up and running are found
in the interfaces. (08)
Back to ontologies and systems engineering hierarchy: I do not think a
deep tree of hierarchies is needed. Rather, a set of triples, top,
middle, bottom. If more is needed, a bottom level can become the top of
another nest. This is because of the relative blindness at the levels.
The top is a service requestor, the middle is a provider. The middle is
also a requestor for the bottom, which is only a provider. These are all
part-of relations. The activity of each level is unknown to other
levels, only the results are visible. The interface is the connection
between levels. Tops make requests and may provide parameters. Middles
service the request but also may issue constraints. (09)
Regards, (010)
-- Jeff Schiffel (011)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (012)
|