Structural Ontology

From Developer Documents
Revision as of 13:19, 22 March 2012 by Tuukka Lehtonen (talk | contribs) (→‎Connection)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Structural ontology contains basic concepts for describing the structure of systems. These concepts are described separately from domain specific ontologies in order to make their reuse possible. The benefit of the reuse is increased possibilities for reusing also code visualizing and manipulating structural models. The structural ontology does not specify the behavior of the structural models, but this is defined in domain specific ontologies.

The diagrams in this page follow Graphical ontology notation in File:Layer0.pdf.

Basic concepts

Component

A component is the basic building block of a structural model. The configuration of the model itself is usually a component. A component may have substructure that contains other components.

Example:

An apartment "JMT 10 104" is a component. It has substructure that contains a component "Kitchen in JMT 10 104". This component contains a component "A chair in the kitchen in JMT 10 104". The chair is composed of four legs and other components and they are composed of smaller components such as screws and wooden pieces.

Structural1.png

Composite

A composite is a component that is defined as a set of components connected to each other.

Example:

In the example above, the chair is a composite that consists of four legs, a seat and a back.

Composite may have subtypes that allow only certain kind of compositions. For example, an automation composite would allow only automation components in its substructure.

Structural2.png

Property

Components have usually properties that describe them.

Example

The size of "JMT 10 104" is 38m2. The length of the leg of the chair is 60cm.

There are no special concepts for describing that a certain component has some properties: properties are written as any other attribute of the resource.

This is an example drawn in graph notation (not in ontology notation):

Structural3.png

Connection

Components may have connection points that can be connected to each other. The meaning of the connection varies by context and also by connection type. In many cases, the connection between connection points means that the connection points share the same spatial position and some other properties. For example, if a leg of the chair is connected to the seat, the connection points do not just happen to share the same position, there is glue between the components to keep the connection points together even if force is applied to one of the components. Connection may also conduct, for example, electricity or signals. More than two connection points can be connected with the same connection.

In structural ontology, the connection points are modelled as relations. For each connection point, there is a specific relation and two or more connection points of different components are connected by giving as a shared connection entity as a value to the connections using the connection points as relations.

Connections may have properties and the Connection type may be inherited. In the domains where this is not necessary, the pure Connection-type can be used directly.

Structural4.png

Connection Joins

The components that are connected with a connection entity must share the the same parent composite. In order to connect components in different composites ConnectionJoins are used:

Example:

Component type

Each component has a component type. Some component types, such as Composite, are defined in Structural ontology, and have predefined semantics. Other component types belong to domain specific ontologies and their meaning is defined in applications using the ontology. In addition, new component types can be defined from already existing component types.

The component type of the component is denoted by InstanceOf-relation.

Component type declares the properties its instances may have using Property Definitions. This mechanism comes directly from Layer0 ontology (File:Layer0.pdf).

Structural7.png

For defining connection points, there is a type ConnectionPointDefinition that inherits PropertyDefinition.

Defined component types

Component types can be defined by giving a parametrized template component that defines the behavior of the instances of the type.

Structural8.png

Structural ontology defines the following ways to refer the parameters in the component:

Structural9.png

The variable is used to refer to the parameter when a property value is expected:

Structural10.png

In order to connect defined connection points to internal connection, the Binds-relation is directly used on Connections:

Structural11.png

In complex defined component types, new values must be calculated from parameters using expressions. Structural ontology does not define an expression syntax but this is done in other ontologies. In these ontologies, other ways to refer parameters can also be defined.

Component name

Every component must have a name that attached the component with HasName-relation. Two different components reachable from the same composite with ConsistsOf-relation must also have different names. Different component types may contain components with the same names even if they are instantiated to the same structural model.

Flattening

The most of the semantics defined in structural ontology concerns flattening of the structural model. Flattening is rewriting of the structural model such that all components with defined component types are replaced by their definitions. The components remaining are the primitive components defined in domain specific ontologies, composites or other combining components.

type Expression
type Component =
  Composite((String, Component)[])
| Component(ComponentType, Property[])
type Property = (Resource, Expression)
type ComponentType = {
  definition : Optional(Component)
}
type Bindings = (Resource, Expression)[]

bind : (Expression, Bindings) -> Expression
flatten(Composite(children), bindings) = Composite(
    map(
        (name, component) -> (name, flatten(component, bindings)), 
        children
    )
)
 
flatten(Component(type, properties), bindings) = {
    transformedProperties = map(
        (property, value) -> (property, bind(value, bindings)), 
        properties
    ) ;
    match type.definition {
        null -> Component(type, transformedProperties)
      | definition -> flatten(definition, transformedProperties)
    }
}

Typing connections and properties

Connection types are terms with the following structure:

  • ?a, ?b, ... are types.
  • If t1,...,tn are types, so is C(t1,...,fn) where C is a type constructor.
  • Type C() can be written as C.