RE: Roles, Fillers, and Role Relations
Pat C,
(I hope this makes sense)
"The point is that, although 'Role' is not itself a Physical concept, it
can have subtypes that are physical objects."
1) 'Role' should not have subtypes that are physical objects. Reference: Fan, Barker, Porter and Clark, year?, Roles and Purpose. This reference can be found on the Web. If you can't find it I'll provide a link to my copy.
2) In systems analysis, architecture and engineering (at least in my practice), it is required that, for example, role and physical (concrete) object taxonomies (and ontologies) be distinct so that at build time one may reason over the architecture description (role descriptions are a part of an architecture description), the physical part descriptions of the design (those things that are **expected** to satisfy the role) , the design (a description of the system of interest) as a whole (architecture description + concrete part description + context description), the capabilities of the concrete parts, individually or in any combination of these.
At Run time
- the architecture description is made manifest in the physical system (the physical system has an architecture) through the interaction of the concrete parts and satisfaction of their roles, based on some criteria. It is possible, and desirable, and in some cases required, that roles may be satisfied regardless of the type of physical part. That is, what is important is the physical parts capability. Not only can a physical part be replaced by one of the same type, but one of a different type. Because, role satisfaction is defined in terms of an group of expectations based on a group of criteria, one may then monitor the capability of the physical part to satisfy the role. A physical part may be required to satisfy many roles. Over time, role satisfaction may deteriorate as a consequence of declining capabilities, external events that affect those capabilities, etc. On the other hand, it is possible in some systems, such as an enterprise, for the roles to change and thus the archit
ecture.
Note: any collection of "concrete" parts may be the domain of discourse / world of interest, including language.
Note: a recursive pattern exists in the relations of roles and parts in moving back and forth from (super-)system to (sub-)system - in a SoS.
Ontology, Ontology Systems and moving, forward and backward, between build-time and run-time.
At build time are model systems (symbols sets, rules of construction, and models, e.g ontology), created by modeling systems (engineers and their tools, e.g. ontology engineers, ontology tools), to create/realize run-time modeled systems (which may or may not be an ontology system). The use of ontologies and ontology systems, especially under conditions of multiple build-time systems working collaboratively to create some common run-time system (big systems), is to endure 1) semantic clarity and interoperability between interacting systems (within and between build-time environments and run-time environments, and between run-time and build-time), 2) ensure that what is intended by the modeling system / system engineer, as captured in models, is realized as measured against a set of quality criteria. The analysis models are using the same semantics as the engineering models.
The point of all of this is that the above is difficult to do, if at all, with a taxonomy/ontology that explicitly confounds roles and the parts that are expected to satisfy roles.
Some examples of role relations:
between a role (architecture part) and the (system) part **expected** to satisfy the role
relations between 2 roles
relations between more than 2 roles
relations between any given particular role and the system as a whole made up by the interaction of system parts
there is a collection of role relations within a system boundary, any collection of role relations may be shared between systems
relations may have roles
the networked collection of roles may be thought as a low level architecture layer
--
Matthew K. Hettinger
|