Questions of Scope and Other 'mid-level' stuff

[neilotte]

Starting a thread here on scope. We can address scope by coming up with principles that say what is mid-level and what's not, but we can also address scope by looking at examples of (apparently) mid-level schemas/ontologies/term lists.

Some that come to mind:

• Core Ontology for Biology and Biomedicine (COB)
• schema.org
• DBpedia

It would be an worthwhile exercise in establishing scope to gather these and additional resources and identify the degree of overlap across them. A possible candidate conception of mid-level would be the (loose) intersection of the term lists in these artifacts.

Looking now for other candidate artifacts that you would offer belong on this list.

[BMandrick]

The following comments start by calling into question the CCO taxonomical structure, which then leads to scoping issues. When reviewing the Common Core Ontologies (CCO), we found that some classes were misplaced and that a more accurate placement (sub-classification) would suggest the addition of parent classes under which they would be more accurately classified. These intervening classes would exist at the level that we feel is appropriate for scoping CCO. If we focus on that level specifically, and get it right, it will provide more clarity at the core level and reduce potential problems with logic in the future.

Our position is rooted in work done in Model Based Systems Engineering (MBSE) and Canonical Systems Modeling, wherein a 'System' is defined as:

1. A set of elements in interaction. (von Bertalanffy 1968)
2. A combination of interacting elements organized to achieve one or more stated purposes (ISO/IEC/IEEE 2015)
3. A system is an arrangement of parts or elements that together exhibit behavior or meaning that the individual constituents do not. (INCOSE Fellows, 2019)

Based upon these authoritative definitions we are of the opinion that the appropriate parent class for ‘System’ is bfo: ‘Object Aggregate’ which is defined as:

(Elucidation) an object aggregate is a material entity consisting exactly of a plurality (≥1) of objects as member parts which together form a unit

b is an object aggregate means: b is a material entity consisting exactly of a plurality of objects as member_parts at all times at which b exists. (axiom label in BFO2 Reference: [025-004]) Examples of usage include:

1. A symphony orchestra
2. a swarm of bees is an aggregate of members who are linked together through natural bonds

The class ‘System’ is not currently in CCO, but 9 types of systems are subcategorized under cco: ‘Artifact’. Our position is that the class ‘System’ should be added to CCO under bfo: 'Object Aggregate'.

Furthermore, just as CCO distinguishes between ‘Artifact’ and other (naturally produced) material objects, we suggest distinguishing between human ‘Engineered System’ and those produced by nature. One might object that the distinction is not clear enough; that there are cases where a system combines both human engineering and naturally occurring elements, making the class 'Engineered System' ambiguous. An example is human engineered streams in Pennsylvania, where Fluvial Geomorphologists and Engineers strategically place large boulders and tree trunks into fast moving streams to slow their currents and create trout habitats. This is done in cases where a stream's fast-moving current erodes its banks over time until the channeling of water is completely destroyed and the stream dries up. One could argue that this is an example of a human engineered, yet naturally occurring ecosystem.

However, if we are to accept this argument re: Systems, then it applies equally to the CCO distinction between 'Artifact' and all other bfo: [Material Entity] Objects, which is already included in the CCO taxonomy. If the distinction between a 'Environmental Feature' [bfo: Material Entity] and a 'Weapon' [cco: Artifact] is in CCO, then the distinction between a 'Solar System' and a 'Satellite Communications System' should also be included in the CCO.

We also want to make assertions about human Engineered Systems:

• They are designed by humans (stakeholders) • They are the bearers of system functions (their purpose)
• They have artifacts as parts • They are located in some operating environment • They participate in System Behaviors

This would result in a definition for 'Engineered System' along the lines of:

Engineered System: A 'System' [bfo: Object Aggregate] that is designed by some 'System Stakeholder' [cco: Person], and has_part some System Component [cco: Artifact] which participates_in some System Behavior [cco: Behavior] that realizes the 'System Function' [bfo:Function].

The addition of the class cco: ‘System’ and ‘Engineered System’ would mean moving (or removing) 9 examples of ‘System’ currently listed under cco: ‘Artifact’. These include:

• Communication System (move to: example of usage)
• Control System (move to: example of usage)
• Environment Control System (move to: example of usage)
• Fuel System (move to: example of usage)
• Ignition System (move to: example of usage)
• Lighting System (move to: example of usage)
• Lubrication System (move to: example of usage)
• Navigation System (move to: example of usage)
• Propulsion System (move to: example of usage)

Our position is that the proper scope of CCO ends where individual (instance level) subject matter expertise begins. In Systems Engineering this means CCO should cover classes such as 'System' as well as 'Natural System and 'Engineered System' but should NOT cover 'Communication System' where a canonical domain ontology would start. Classes such as 'Communication System' should be "examples of usage" for 'Engineered System' in the owl-rdf ontology, so that the Communication System Ontology module would extend from that point.

[swartik]

@BMandrick That's an interesting perspective. If System was a subclass of Object Aggregate, what axiom(s) would you assign to System that do not apply to its parent?

[BMandrick]

@swartik I am thinking that not all Object Aggregates have a function (purpose) nor do they participate in some type of System Process--i.e. the interaction of component parts that make up the System and realize the system's function. Examples of Object Aggregates that are NOT Systems include: Object Aggregates that are defined through physical containment: the aggregate of molecules of carbon dioxide in a sealed container or Object Aggregates that are defined via attributive delimitations such as: the patients in this hospital. In contrast to these Object Aggregates, a System is the 'bearer of' some System Function and 'participates in' some System Process, which realizes that System Function.

[neilotte]

Update: New work by @johnbeve addresses the primary issue in this issue. Because this remains a more open ended subject, converting now to a discussion thread.