Actions

Ontolog Forum

Revision as of 17:08, 8 January 2016 by imported>KennethBaclawski (Text replace - "[ ]LeoObrst[ ]" to " Leo Obrst ")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

OntologySummit2012: (Track-1&2) "Ontology for Big Systems and Systems Engineering" Community Input

Track Co-Champions: Dr. MatthewWest and Dr. HensonGraves

Mission Statement:

We aim to bring key challenges to light with large-scale systems and systems of systems for ontology and identify where solutions exist, where the problems require significant research, and where we can work towards solutions as part of this summit. The areas to be considered include:

  • working with and integrating the results of models using multiple modeling languages,
  • the systems lifecycle and the issues of sharing data within and between lifecycle stages,
  • the difference between requirements and the delivered system,
  • systems of systems vs systems,
  • the nature of system components and the difference between these and the parts installed,
  • the connections between system components and what they carry,
  • the specific role of social, legal, and value-related aspects in systems architecture, modeling and design
  • systems behaviour,
  • federated systems both as a big system, and as a solution to some of the challenges,
  • principles of how to construct good quality reusable models (ontologies),
  • the management of ontologies of and for large systems and the challenges in developing and maintaining them.

see also: OntologySummit2012_BigSystemsEngineering_Synthesis

  • this is a combined track from those previously labeled
    • Track-1: "Large-scale systems engineering"
    • Track-2: "Large-scale engineered systems"

Refinement of Threads we could follow during this summit:

[2012.02.02] ... Brought forward from the session-04 discussion: ... (see: [ below)]

ref. HensonGraves' "Triage" slides

identify thread champions too!

  • #4 - System Descriptions For Different Uses, e.g., Requirements & Design
  • #5 - Success And Relevance Of Semantic Issues In Engineering - to be partially addressed by AmandaVizedom et al. in X-Track-A1 and also by SteveRay et al. in Track-4
  • #6 - (in lieu of the Natural vs Artificial Systems discussion) discussion of rules of engagement where Systems and Ontology discussion would make sense, essentially where Systems can pick up Ontology
  • #7 - Semantic Interoperability - candidate champion: RaviSharma (semantic mapping) with support from Leo Obrst

Triage on Engineering Tracks 1 & 2

-- HensonGraves / 2012.02.03 - 

ref. http://ontolog.cim3.net/forum/ontology-summit/2012-02/msg00082.html

The mission statement for tracks 1 and 2 is within the engineering domain is to bring key challenges to light with large-scale systems and systems of systems for ontology and identify where solutions exist, where the problems require significant research, and where we can work towards solutions as part of this summit. A number of areas are identified in the mission statement. From this list a smaller list of threads has emerged in the dialog.

The next step to achieving the mission goal is to triage the list of threads emerging from the mission statement. The emerging list has been constructed by examining the email and chat dialog. The purpose of the triage is to produce a more manageable for which there is the interest and opportunity to make useful progress within the timescale of the ontology summit. In some cases the progress may be only to identify solutions which already are available. In other cases significant research may be needed, but within the Summit context we can at least identify the research and a plan forward. There will of course a number of other topics which would be relevant to this track, but to pursue them would dissipate our resources.

The following list is the current candidate list of threads. I ask you to weigh in on whether the list should be changed, dropped, reformulated, or added to.

  • Composite System Modeling: There has been a lot of discussion regarding

concepts needed to describe engineered and other systems regarding Including parts, components, roles, qua-objects, functions, part replacement and virtual individuals. Engineers are not the only ones interested in this, but presently it is recognized as critical in engineering. Use cases would be easy to obtain. Some have already been mentioned. While there is an enormous literature from ontologists a triaged list of references suitable for engineers would be very useful. We could also identify issues, based on engineering examples, where we can achieve something beyond literature.

  • System Descriptions for Different Uses, e.g., Requirements & Design: There has

been discussion of different forms of conceptual models based on their use, particularly in AnatolyLevenchuk's presentation and his references, i.e., (ConradBock). This Is also a very topical issue with engineers as they need better methods of translating or relating these different models. There is lot of current system engineering discussion concerning formalizing requirements so they can be embedded as models (ontologies) within engineering languages and in refining requirements models to design models.  

  • Success and Relevance of Semantic Issues In Engineering: This topic was

introduced by JohnSowa among others. There has been push back on this topic on the grounds that it was covered last year. However, marketing ontology is not the same as establishing where there are successes and analysis of failures, and conditions that might drive success. SteveRay and AmandaVizedom are addressing this, respectively, in track-4 and cross-track-A1, but there is need to relate this particularly for engineers. The topic is of great concern to engineering decision makers and any insight on this would help.

  • Ontology for engineered systems which uses ontologies and semantic methods: It

has been noted that existing engineered systems already use ontologies in the pursuit of objectives. This seems a perfect place to apply upper level ontological concepts of plans, actions, and such concepts. Use cases are not too hard to come by. ElisaKendall introduced examples. Military systems offer a rich collection of use cases. Autonomous systems are likely already being given rules of engagement in the same way that soldiers are given them. The rules specify circumstances in which it is ok or not ok to kill someone, or mandatory that someone be killed. Clearly these situations also have legal and moral implications. There are more prosaic examples as well such as systems using ontologies to monitor their health and safety and make decisions of whether to abort a mission.

  • Semantic Interoperability: Semantic interoperability crosses many tracks, but

has specific relevance for engineering. Many current engineering problems result from this lack of semantic interoperability. We have seen some suggestions such as GiancarloBuizzardi posing ontologies as reference models of consensus to provide bridges, Leo Obrst posing hierarchies of ontologies for semantic integration. It would be good to have more specifics e.g., how to deal with different levels of abstraction, different terminology and different axioms sets. Triaged literature relevant to solutions, not the problem would help.

Please feel free edit, comment, and most importantly sign up to champion a thread.

Enter your input below ... (please identify yourself and date your entry)

  • Semantic Interoperability: Some of these are indicated in Triage slides from Dr. HensonGraves (ref. GiancarloGuizzardi and literature relevant to solutions, not the problem) and provide direction for some of the approaches / inputs to Questions on SI -Semantic Interoperability; other topics / inputs from community are invited. Where are we in defining Big Systems and Systems Engineering related or general semantics? Are there one or multiple formal definitions? What other attributes are required / involved beside vocabularies, terms, data and information (sharing and exchange), XML as transport or exchange medium, XMI as model data exchange, when we talk of Semantic Interoperability (SI)? Are there tools beyond Information Sharing and Exchange (e.g. NIEM and UCore) or Models (E-R, O-R or Metadata models) that we can leverage when determining SI? For this thread we would hope to list summary: Where are we -Current literature survey and topics on SI, in Ontolog and other forums? What additional value is brought by ontology considerations when added to semantics? Topics - Etc. more to come. (--RaviSharma / 2012.02.04)

dialog between Henson Graves and Matthew West: Dear Matthew, I have been attempting to follow the discussion on system components, roles, fillers, and role relations. For the most part I think that I agree with you and disagree with a lot of people. Sometimes I am not sure whether this is the case and wonder if the problem is different terminology. Perhaps we can sort this out.

  • MW: The main problem is that most people with any background in philosophical ontology, especially if it is slight, have preconceptions about what sorts of things there possibly are at a high level, and system component does not fit neatly into any of them. So mostly what you have seen is various people trying to shoehorn system components into the things they do know. Most of my comments on the proposals of others have been to point out why their scheme is not correct, or where their approach falls short of meeting natural intuitions of engineers.
  • HG: This is my impression also. They keep talking about earth worms or space-time worm holes or in any case things I am not very familiar with. So your comments are to address what ontologists need to know about the ontology of engineered systems.
  • MW: The obscure language (to us) here is a space-time worm. To translate, they mean what we would understand by a state, i.e. something for a period of time during which some property is true, e.g. a door whilst it is open. One of the tricks I have noticed philosophical ontologists play is to wrap ideas they do not like up in obscure language like space-time worm when there are perfectly ordinary words they could use. These then get absorbed into the literature, and so when they get read back to people like you and I, we think that the idea is strange rather than just the language.
  • HG: To attempt to sort out terminology and see who is really arguing what I would like to put the discussion in the OMG MOF framework. As you no doubt know the MOF specification adopts a four-layer metamodeling architecture:
    • M0 What is to be modeled within the real world
    • M1 Models (for example, a UML model of some part of the world
    • M2 Metamodels (for example, an abstract syntax model in the UML specification)
    • M3 The meta-metamodel which specifies the metamodel languages.
  • MW: I should probably point out that I am not a fan of the OMG four layer architecture. It's not so much the layers, but that they are disjoint. My view would be that all these things are in the real world or things that are themselves signs for other things, or classes of those things, and classes of classes. The 4 level architecture requires that at each level that you have classes, but no way of saying which things across all the levels are classes.
  • HG: I too have never been a fan of the OMG 4 level architecture for similar reasons. However, speaking of MO and M1 do enable separating the models in some engineering language to be distinguished from their interpretations in the sense of logic. Note that in the 4 level architecture the interpretations of an M1 model which consist of physical parts is in M0. However, an M1 model which contains individuals may be used to construct valid interpretions of the model in M1 which are in M1.
  • HG: Actually for this discussion one only needs M0 and M1, but for a discussion of the relationship between conceptual models and ontologies, M2 seems to be needed. My impression is that a lot of confusion arises by an inability to distinguish between M0 and M1. I suspect that I am using terminology somewhat differently from you. But maybe we can figure this out.
  • HG: M0 is where the real world of airplanes, oil refineries with their parts with identification numbers live. Further in this world one part may be connected to another. For example a pump with serial number no. 5755/A may be connected to two tanks. Also I agree that the components live in a 4D world.
  • MW: That's a pretty good start. Where do properties live, and the manufacturer's model for the pump? HG: Properties live in M0 and a manufacture's model lives in M1. The models in M1 are expressed in some language that is assumed to have individuals, classes, and binary properties as specified by an M2 metamodel. I will defer discussion their semantics for a bit. M0 is the target for valid real world interpretations of the models in M1. In my naïve view I do not assume that M0 has classes as extensional things, rather one has procedures to evaluate if an individual component satisfies a class. I am assuming that the component has a model number which identifies the class that is presumed to be an instance of and a serial number which identifies the component uniquely. As you are aware in some industries counterfeit components is a real issue. As a result one may need elaborate testing procedures to determine if a component is a valid instance of the specification class. On your last flight on a commercial aircraft take a guess as to how many counterfeit parts were on it.
  • HG: M1 is where models live. There are different kinds of models. One kind of model attempts to describe say a particular crude distillation unit uniquely at a point in space-time.
  • MW: A key question here is whether your model is a representation of the crude distillation unit, or a specification of a crude distillation unit, i.e. are we looking at some signs that stand for it, or some classes that it is a member of. I'm not sure the OMG architecture is clear about this distinction. HG: I agree that OMG does not appear to appreciate the difference between a representation of the crude distillation unit and a specification for the unit.
  • HG: Such a model would have serial numbers for all of the components and connection lines between them.
  • MW: OK. So these are signs. HG: yes a model that attempts to describe a particular distillation unit would consist of individuals which are within the language in M1. Lets look at your crude distillation unit example from the 4 layer perspective. The diagram on the right looks like an M1 model which could be a design specification or a description of a particular distillation unit. I cannot tell without more detail. The pump symbol on the left with the label "Serial No. 5755/A" appears to be an individual within an M1 language.
  • MW: Yes. I always try to start analysis from real world individuals, and then work out from there in various directions (classes, things that might be, etc). I find this keeps you grounded. So the diagram is supposed to represent a real distillation unit that you can walk up to and kick. There are specifications for the items in the diagram, but the diagram shows particular objects that meet those specifications.
Figure: A crude distillation unit.
P101 is a system component of the Crude Distillation Unit. It is the bottoms pump from C1 to C2. Initially the pump with serial No S1234 is installed. At a later date this pump is removed and pump with serial no S3456.
  • HG: However, this is not the kind of model used for a design specification. An architecture or design specification describes a class of implementations or realizations.
  • MW: Right. The second type of model I mentioned.
  • HG: In UML, SysML or OWL such a model would use three classes: C1 and C2 for tanks and 101H for pumps. The distillation unit model would likely have a connection relation R1 between C1 and 101H and another connection relation R2 between 101H and C2.
  • MW: You need to be careful here. I think what you are calling a connection relation, is really class of connection, in that it is a member of one class that is connected to a member of the other class, i.e. it is an instance of the C1 tank class that is connected to an instance of the 101H class. HG: Yes that is what I mean. A connection relation is a subtype of the Cartesian product (C1,101H) and a connection instance in M0 is a pair <c1,p1> in Conn1 where c1 is an instance of C1 and p1 is an instance of 101H.
  • HG: In many languages these connection relations would be called properties or roles.
  • MW: Which does nothing to aid clarity. Actually, even relation is a mathematical structure, and not what is really being represented
    HG: yes but I am talking about models in M1. I am making some assumptions regarding the expressiveness of the language in which the distillation unit is being modeled. I am assuming that one has at least individuals, classes, and subtypes of Cartesian products of classes. As I am sure that you know there are a lot of logical languages other than set theory which provide these constructions as well as semantics for the constructions. The distillation unit model would be called a class model. The real distillation unit on the M0 level would presumably be a valid interpretation (in the sense of logic). By adding sufficiently many individual terms to the model one could construct a term model for the distillation unit within an M1 model.
  • MW: Actually, in logical terms, strictly model theoretic terms, the real live distillation unit is a model of the ontology 

of the class model at the M1 level. HG: I am being careful. In strictly model theoretic terms the models in M1 are really axiom sets and the valid interpretations of them are distillation units in M0.

  • MW: NO!! In strict model theoretic terms the real physical distillation unit (or at least a representation of it) is a model of the axiom set. I know that sounds crazy, but logicians have what is a model of what the opposite way round from us engineers. In model theory logicians take an axiom set and consider valid instantiations (models) of the theory and are concerned about unintended models, i.e. models (instantiations) that are valid, but which they did not wish to be valid. HG: I do not see that we are in disagreement, see below.
  • HG: I am not sure how ontology got in at this point. I just haven't said what logic I assume that I am working in. I haven't really mentioned it except to say that it is an M3 concern. I will generously assume that you are in some way referring to the semantics of classes, properties and any other language constructions I use to build my models in M1.
  • MW: You introduced it with the phrase (in the sense of logic) above. That sent us down this rat hole. It's useful to have the engineers and logicians different uses of the word "model" clarified, but that was the only purpose of this section for me. HG: I perfectly understand that what engineers call models are what logicians call axiom sets and what logicians call models or valid interpretations are what engineers call implementations, realizations, or maybe virtual reality if the interpretations are not in the real world. By the way there are a lot of results which show how engineer's models in UML or SysML can be embedded within various kinds of logics. When the engineer's model is embedded it becomes in a natural way an axiom set. We may have gone down a rabbit hole in our dialog as we didn't realize when one of us what using the word "model" in the engineer's sense and when it was being used in the logician's sense. The real rabbit holes in conversation result in my opinion when people cannot keep the distinction between an axiom set and its valid interpretations straight.
  • HG: There may be many other valid interpretations of the distillation class model. One interesting problem for logicians is how to build something like a class model for which all valid interpretations have the same structure. You really cannot do this in OWL without some extensions.
  • MW: We have had problems rendering ISO 15926 in OWL, even OWL 2. HG: That is not surprising. I don't know anything about ISO 15926 but if it can be used to build effective models of things beyond Napa wines and pizza toppings then OWL2 would be insufficient. This statement does not cast any aspersions on OWL it simply notes that OWL2 for good reason does not have constructions for embedded parts, operations (functions), or behavior.
  • MW: Strictly it doesn't need to. It only needs the things that you can build those with. For ISO 15926 the problem is that OWL only allows a single level of classification. So if I have some items of equipment, then I can talk about types of equipment, but not classifications of equipment types (where the equipment types are instances). Or at least I cannot do that using the internal instance of relation. HG: I think that I agree with you, but this need more discussion. It sounds like you are saying that you need a higher order logic in which a type of equipment can be an instance of for example a power type.
  • MW: First order logic is sufficient for this. I've not yet found a need for anything genuinely beyond FOL.
  • HG: The way that I think about roles is that R1 is a subtype of the product type (C1,101H).
  • MW: Sorry, this does not really tell me what R1 is.
  • HG: An instance of R1 would be a pair <c1,p1> where p1 and c1 are instances of the respective classes.
  • MW: OK, it looks like R1 is intended to be a relationship type between C1 and 101H. HG: yes R1 is a relation type. As a relation type it can have subtypes as well as instances. An instance <c1,p1> of R1 could be called an R1-relationship.
  • HG: I would call the M0 connection a relation instance. The M1 property can of course have subtypes.

M2 which is the OMG meta-model level is where one would specify properties for part classes and roles. Of course to expressive properties at M2 one really needs a meta-logic rather than a meta model.

  • MW: Well, one of the good things is that as long as you are dealing between just two levels, then the same logic will do the job, because logic, well OWL at least knows about classes and instances, and the classes at one level of the architecture are instances at the next level up. HG: Yes, OWL has classes and instances and in some cases the instances can be used to build a valid interpretation (logician's model) of the axiom set (engineer's model). Of course in the M1 logic you have to equate equal terms of the logic, e.g. 2+2 is the same thing as 4.
  • HG: Let me know how this fits or doesn't fit with your way of thinking about things.
  • MW: Yes, that seems reasonable. But it does not cover a system component (M0) being replaced, but still remaining the same system component. HG: what I have said does not cover the issues of identity and we still haven't talked much about ontology, or the semantics of classes, properties, and language constructions in M1. My impression is that if a part with a specific serial number is replaced with another component with a different serial number that the two components certainly are not identical but the unit in which they were replaced is still the same unit.
  • MW: Terminology alert. I am using system component for what you are calling unit. So I talk about a system component being the thing that is invariant over the life of the system, where several equipment items might be installed and spend some time as that system component. HG: This is a good and interesting point.
  • MW: The next bit is that in allowing something to still be the same unit/system component but have all of its parts replaced when one component/equipment item replaces another as that unit sets of all kinds of identity alarms for your average philosophical ontologist. Physical objects are not supposed to retain identity when all their parts change. Take your car, if I borrow it and smash it up, buy a replacement exactly the same and re-register it with your registration no, is it the same car really? No. But what we are saying here is that for a unit/system component, when you take all its parts a way and put another one in its place, it is the same thing. It is not too hard to see why they might find this hard to accept.
  • HG: All this says is that the criteria for identity of a unit that I am using allows replacement components.
  • MW: Exactly. The problem for most ontologists is that they do not have such a category in their armoury, and are reluctant to admit one (another feature of ontologists is the very high value put on parsimony). HG: This is reminiscent of the problem that fire, air, water, and earth are possibly not the right concepts for an upper ontology for engineers.
  • HG: The replaced component still has the same specification, i.e., it is still a member of the same specification class. But after being swapped out it is no longer part of a relationship instance of the connection class.
  • MW: There are actually a number of relationships here. Being the Unit/system component means being connected to other components of the system, and being a part of (component of) the system. That is part of being a system component. The tricky bit is becoming the system component, because what I would want to say is that whilst the component/equipment item is installed, it is the unit/system component. Or to put that slightly more formally, there is a state of the component/equipment item that is also a state of the unit/system component. Now the relationships here are those of this state being a state of both the component/equipment item, and of the unit/system component. HG: This sounds like a fruitful topic for ontologists.
  • HG: Relationship instances change with respect to space-time. People who once were friends of mine are no longer friends. So friendship and partOf are not invariant relationships.
  • MW: Actually, in the way I have said it above, all the relationships are eternal. That state will always be a state of the system component and the equipment item. The temporality is determined by the start and end date/time of the state. Some people (myself included) would argue that having temporal relationships is problematic, because they are essentially abstract (you cannot kick them) and it is questionable whether abstract things can exist in space-time, and hence cannot really have a temporal extent (since they do not have a spatial one). But there are plenty of people who ignore that difficulty without dying. HG: This argues the need for more ontological analysis of how things are indexed by space-time.
  • HG: Other than your non-smiley face we have avoided talking about ontology.
  • MW: Well there a plenty of ontological issues you have touched on in your latest comments.
  • HG: What is the difference between an ontology and one of my design models (axiom sets)? The distinction between an ontology and a model is imprecise in the literature. However, a conventional definition might say that an engineering ontology provides terminology for modeling physical objects, their properties such as parts and connections as well as properties which are observed and measured. For example, candidate terminology for an engineering domain might include physical object for entities as vehicles.
  • MW: Well I would want an ontology of both your physical objects and your design models, and the relationships between them. HG: Yes I agree and this is where I think that upper or foundation ontologies are extremely useful in the engineering of systems.
  • HG: In OMG terminology, Models are created using a modeling language that is described by a metamodel (M3). OMG also describes a level M3 metamodel as a specification for an ontology and the modeling language in which the ontology is expressed. This makes some sense in that their metamodels which are class models describe the syntax used within a model constructed according to the metamodel. For example, the OMG MOF facility contains definitions of metamodels for UML, SysML, and OWL. This is ok as far as it goes. The metamodel does syntactically specify the terminology, e.g., that classes and property are language constructions to be used in a model of the language in which the model is defined. This is a start, but of course it does not provide any semantics for the language constructions. This could be done by using a meta-logic rather than simply a meta-model.
  • MW: There is no such thing, that I am aware of, as meta-logic. You can of course apply logic to meta-models, but that does not make a meta-logic, it is just the same old stuff applied at a different level of abstraction. HG: Sure there is such a thing. The UML metamodels can be embedded as axioms within a logic whose valid interpretations are axiom sets in M1. In fact if one replaces metomodels with meta-logic then many of the axioms about mereology can be stated there and can be syntactically checked when axiom sets (engineer's models) are parsed. MW: Hmm. Well for me an example of a logic is: and, or, not, implication, universal quantifier, existential quantifier. Everything else is part of the lexicon. So I would say you are dealing with different lexicons in M0, M1, etc, but the same logic.
  • HG: Within a meta-logic one could express axioms for classes such a Part class. My impression is that the properties of Part classes needed for modeling oil refineries and aircraft have somewhat different axioms than are used by most ontologists. This of course requires more discussion.
  • MW: Well, the philosophical ontology literature has quite a lot of mereology and mereotopology (the posh words for whole-part and connection) but relatively little on what I have called system component. So this is what I think is the biggest are that needs more work. The other area I think could do with work is on the class of part relationship that you get in e.g. a bill of materials. It seems to me that there are many possible flavours here, e.g.:
    • A whole of class A may have a part that is a class B.
    • A whole of class A must have a part that is a class B.
  • HG: Again I agree with you. What you are saying are typical issues of creating design specifications and acceptance criteria for the resulting manufactured articles. By the way the OWL and Description Logic class constructions can be used effectively to express necessary parts. For example, I am told that a water molecule must have exactly one oxygen and two hydrogen atoms connected in a specific way to be a water molecule. One can express the necessary parts with Water subclass of hasoxygenatom [1]Oxygen and hashydrogenatom [2]Hydrogen. Here Oxygen and Hydrogen are classes and hasoxygen is a part relation whose domain is Water and whose range is Oxygen. This is a restricted existential quantification statement.
  • HG: I notice that you have used the word system occasionally. I have not used it yet. It is not that I don't like it; I do like it. I am just tired of people insisting that we cannot proceed with discussion without defining "system" or "engineered system". Another suggestion has been that we enumerate all of the systems or engineered systems as opposed to defining them. This idea does not seem very realistic to me. One could give examples of system of course. I am sure that the same argument that one has to define terms could be applied to "unit" or most any other common word in order to stop discussion, as well as providing cover for those who do not believe the discussion should be continued. While I agree that one should work towards precision in classification the lack of precision need not stop useful discussion. To quote the mathematician Bruno De Finetti it is better to build on sand than on nothing at all.
  • MW: Hmmm. Well on the one hand I don't think it is that difficult to come up with a definition of a system. The only problem is coming up with one definition that everyone agrees to, and I don't think that is necessary. I think it is enough to list as many definitions as people wish to propose, in fact I think such a list has already been contributed. I agree examples are always useful.
  • MW: My definition would be that: a system is a physical object that consists of components where the components are connected and interact such that the system has behavior that is more than that of the sum of the parts.
  • MW: The importance of having a system as something that is defined, is that unit/system component does not exist without it. A system component is a component of a system, and without a system that it is a component of, does not exist. HG: Ok I can go with that. My units certainly have that property. My basic objection to the word "system" in the Ontology Summit context is that mention of it seems to set people off on a line of magical thinking in the sense of conflating somebody trying to build an oil refinery to refine oil and the oil refinery having some intrinsic intension to refine oil. I do not think the latter is needed to talk about oil refineries. If one is discussing the political and social aspects of oil refineries, then more may be needed.
  • HG: I hope that we haven't added too many more worms to our can. (-- HensonGraves and MatthewWest / February 18 2012)

System Descriptions for Different Uses. We should distinguish at least 5 stakeholder groups with different interests in big systems: designers, analysts, builders, users, and theorists. Designers imagine new configurations of materials, new communication networks, or new transformations of energy to produce novel results. They write down their imaginings for the benefit of analysts and builders. Analysts apply specialized techniques, usually from an established discipline, to vet known aspects of designers' creations. (For example, the materials engineer will verify the strength requirements of structural components.) Builders of systems create physical manifestations of the designer's imagination: they obtain the materials, arrange the activities, fabricate and assemble the components, and deliver the product or service. And users adapt themselves as needed--for better or worse--when a big system intersects their lives.

Lastly we have the theorists (a class which includes all of us in this forum along with various OMG and ISO technical committees and Sowa's pantheon of knowledge engineers: Aristotle, Leibniz, Kant, Peirce, Whitehead, and others). Theorists are usually the least relevant players in big systems, and the most likely to be wrong about them. It is off topic to explore in depth the reasons for this, but let us be aware of the different ideals and motivations of theorists, and therefore wary of their recommendations and pronouncements. We theorists favor the abstract, eternal, universal, static, and rational; those who do real work are intricately bound up with the real world of special cases, exceptions, creativity, change, and irrationality. Theorists are immune to the profit motive and exempt from budget constraints; and if they have any interest in market share it is only in the marketplace of ideas. (I say this as one who believes that "there is nothing so practical as a good theory" and finds nothing more pleasing than an apt principle or pattern.) I don't say all theory is useless. I just suggest we ask of our theories how, specifically, they favorably affect the day-to-day activities of designers, analysts, builders, or users of big systems.

I don't mean to impose a rigid or unnatural separation of duties on these groups. Designers can be competent analysts or builders; practically anyone touched by a system can contribute to its design. Different stakeholders can often profit from close communication--in some phases of system development a great deal of interaction is required. Furthermore each group has activity specializations within it, with specialized information diets.

An ontology, in this forum, is a theory about the classification and relationships of things of interest to users of that ontology. It seems clear that no single ontology can simultaneously satisfy the needs of designers, analysts, builders, and users of a big system. Their mental models of the world are different; they parse the universe differently; their evaluation-execution loops are triggered by different signals and effected with different affordances (to borrow a model and terminology from Donald Norman, The Design of Everyday Things). However, it is equally clear that there are some threads of meaning that connect multiple stakeholders in a big system. The required research program is: how to construct separately useful ontologies for each group of stakeholders, and connect them as necessary in natural and useful ways. (--PaulTyson / 2012-02-18)

Retrieved from "https://ontologforum.com/index.php?title=OntologySummit2012_BigSystemsEngineering_CommunityInput&oldid=236"