[ontology-summit] OS-2012 Problem Space

[Ali SH <asaegyn+out@xxxxxxxxx>]

Dear Colleagues,

I believe the email quoted below from Joseph Simpson highlights an important aspect of what we're grappling with in this year's summit. I'd like to take a step back and attempt to provide a characterization of this year's problem space, what might be feasible given our time frame and resource constraints and proffer some suggestions to help structure our conversations with an eye towards producing deliverables that don't just record what happened, but act as a growing resource for others working on systems and ontology.

As stated on the summit website ( http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2012#nid309A ), we're considering "big systems" very broadly, while aiming to facilitate knowledge transfer between systems and ontology communities.

Given this context, let the scope extend to any community / subculture that would self-identify as working on a "big system." This includes not just traditional systems engineering (power plants, cars) but also urban planning, climatology, ecology, biology, economics, cognitive engineering, human factors engineering and so on. Thus far, we have had the systems engineering and IT communities well represented, but have heard nary a word from other subcultures.

From this, observe that the number of communities working on "big systems" is quite large (c1, ... , cn), each quite likely with their own interpretation of what counts as a system (s1, ... , sn). Indeed, it looks like we have the classic semantic interoperability problem, but with people. At worst, we have _n_ different interpretations of systems, with some overlap among them. Indeed, as noted here ( http://ontolog.cim3.net/forum/ontology-summit/2012-02/msg00132.html ), there are sundry definitions of Sysetms and System of Systems. 

Of course, we do not have access, nor the ability to accommodate all these communities in this summit. That is, we will be working with a subset of these "big systems" communities, and more specifically, with de facto representatives who in turn will only articulate a subset of specific problems from each of these communities.

Further, it should be noted that each of these communities / subcultures have their own methodologies, literature, artifacts and effectively local background / contextual information that is largely a given (or obvious, or uninteresting) for those who participate in said subculture.

What each of the systems representatives are best positioned to do (see Sessions 1 and 2), is to articulate their specific needs and problems. Of course, much of their language is situated within their community context, and they may take for granted (or as obvious) what their particular interpretation of system entails. There was an email earlier about how the local context alters meaning, and I think part of what is important in our discussions is to make explicit the basic / background assumptions of each distinct community. 

The summit is not a standards body, and the scope too large, the problem space too complex for the summit to be able to unify all these different communities or perspectives. The engineers and practitioners participating this year are most interested in deriving actionable knowledge or information to apply to their specific problems. We don't want to create "fluff", but detailed, practical guidelines / suggestions, if not solutions for the problems that have been articulated.

This introduces some tension between creating a body of knowledge that is extensible (and facilitates knowledge transfer between disciplines) and creating solutions for specific problems. Namely, imagine that you are someone from a community that has thus far not been represented in the discourse. You are interested in how ontology might apply to _your_ big system and come to the summit looking for information. One of your concerns is to map your contextual situation (including your subculture's understanding of system) to what has been produced. It is vitally important to be able to identify how your understanding of system is similar / different from others, and how that affects the problem and proposed solutions.

I don't think we'll be able to define "Systems" or "System of Systems" satisfactorily for all communities in this summit. In one of the earlier chats, ChrisWelty suggested that we simply enumerate the systems we're addressing. I think that's too coarse. What I would suggest is that for each participant to articulate their background assumptions for the salient features of their systems. That is, for each of the systems that participants bring to the table, we should try to systematically capture their salient characteristics and features. Indeed, I would suggest that this is the interface that links systems between each of the communities.

To this end, I would like to highlight the slide entitled Ontological Patterns from Giancarlo's slide deck ( http://ontolog.cim3.net/file/work/OntologySummit2012/2012-01-26_OntologySummit2012-ProblemSpace/OntologySummit2012_Ontology-Engineering-for-Complex-Systems--GiancarloGuizzardi_20120126.pdf ).

In this way, I think our best shot is to start capturing 

• Modeling Patterns 
• Analysis Patterns 
• Problem Patterns 
• Codification Patterns
• Transformation Patterns 

(if the term pattern is opaque, I believe it is intended to be analogous to software design patterns - http://en.wikipedia.org/wiki/Software_design_pattern ).

If we can frame the problems that each participant brings to the table in terms of patterns that address characteristics or features of systems, and link our proposed solutions / guidelines / recommendations to such a body of knowledge, then I think we will have created something that will be relevant not just to the immediate summit participants but members of other system communities.

In summary, I suggest that when we engage in the summit, we be clear about what assumptions we have about systems. What aspects of a system are relevant to the problem at hand? Is there a pattern to this problem? What are the relevant system characteristics that sketch the contours and give rise to the problem? Similarly, what are the different solution types / facets that can help address the problem?

Again, this doesn't mean that we try to definitively define systems (though a track on an ontology of systems would begin this process), nor does it mean that we speak in generalities. But it does mean that we bring more to the table than specific concerns. It is important that we situate our contributions in the background context of the communities we are representing, and focus on trying to extract reusable patterns from any subsequent elaborations.

Thoughts?

Best,

Ali 

On Fri, Feb 3, 2012 at 3:16 AM, joseph simpson <jjs0sbw@xxxxxxxxx> wrote:

It appears to me that there is a wide range of system types.

Many attributes, behaviors and characteristics could be used to begin the classification of systems into groups.

Without some basic agreement about the type of system under discussion, the information content of the messages in the discussion plummets.

In my view when a lack of system types is mixed in a discussion that includes concepts related to a system of systems, the rate of information decrease increases radically.

The opportunity for recursive application of these ill defined concepts drives the information content to near zero in very short order.

But it sure makes a neat "world cloud."

Have fun,

Joe

_________________________________________________________________
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)