S-TEN D2.1: Physical things


Ontology for self-describing networks	S-TEN D2.1

Cover page
Table of contents
1 Introduction
2 Terminology
3 Physical things

4 Temporal part and time
5 Observation and measurement
6 Information
7 Physical quantity, property and scale
8 What is possible

A SensorML
B Weather station example
C PML
D Computer interpretable listing
Index

3 Physical things

3.1 Upper ontology

3.1.1 Physical and abstract

Both SUMO and ISO 15926-2 say that each thing is classified as either:

physical (see classes sumo:Physical and iso15926-2:possible_individual); or
abstract (see classes sumo:Abstract and iso15926-2:abstract_object).

NOTE 1 This not contentious amongst upper ontologists, but in practice it is sometimes convenient to classify a thing as both "physical" and as a member of one of the subclasses of "abstract". This is discussed in Section Physical thing and structure.

The alternative definitions of "physical" are as follows:

sumo:Physical	iso15926-2:possible_individual
An entity that has a location in space-time. Note that locations are themselves understood to have a location in space-time.	A possible_individual is a thing that exists in space and time. This includes: things where any of the space time dimensions are vanishingly small, those that are either all space for any time, or all time and any space, the entirety of all space time, things that actually exist, or have existed, things that are fictional or conjectured and possibly exist in the past, present or future, temporal parts (states) of other individuals, things that have a specific position, but zero extent in one or more dimensions, such as points, lines, and surfaces. In this context existence is based upon being imaginable within some consistent logic, including actual, hypothetical, planned, expected, or required individuals.

sumo:Physical

iso15926-2:possible_individual

An entity that has a location in space-time.

Note that locations are themselves understood to have a location in space-time.

A possible_individual is a thing that exists in space and time.

This includes:

things where any of the space time dimensions are vanishingly small,
those that are either all space for any time, or all time and any space,
the entirety of all space time,
things that actually exist, or have existed,
things that are fictional or conjectured and possibly exist in the past, present or future,
temporal parts (states) of other individuals,
things that have a specific position, but zero extent in one or more dimensions, such as points, lines, and surfaces.

In this context existence is based upon being imaginable within some consistent logic, including actual, hypothetical, planned, expected, or required individuals.

There are different approaches to the next level of subclasses below "physical". The SUMO and ISO 15926-2 alternatives are:

SUMO	ISO 15926-2
sumo:Object	iso15926-2:physical_object
Corresponds roughly to the class of ordinary objects. Examples include normal physical objects, geographical regions, and locations of Processes, the complement of Objects in the Physical class. In a 4D ontology, an Object is something whose spatiotemporal extent is thought of as dividing into spatial parts roughly parallel to the time-axis.	A physical_object is a possible_individual that is a distribution of matter, energy, or both. EXAMPLE 1 A piece of metal is a physical_object. EXAMPLE 2 A tree is a physical_object. EXAMPLE 3 The thing identified by tag P101 is a physical_object. EXAMPLE 4 A light beam is a physical_object. EXAMPLE 5 A tank that is built and dismantled on site is both a materialized_physical_object and a functional_physical_object.
sumo:Process	iso15926-2:activity
Intuitively, the class of things that happen and have temporal parts or stages. Examples include extended events like a football match or a race, actions like Pursuing and Reading, and biological processes. The formal definition is: anything that lasts for a time but is not an Object. Note that a Process may have participants 'inside' it which are Objects, such as the players in a football match. In a 4D ontology, a Process is something whose spatiotemporal extent is thought of as dividing into temporal stages roughly perpendicular to the time-axis.	An activity is a possible_individual that brings about change by causing the event that marks the beginning, or the event that marks the ending of a possible_individual. An activity consists of the temporal parts of those members of possible_individual that participate in the activity. The participating temporal parts will be classified by the participating_role_and_domain that indicates the role of the temporal part in the activity. EXAMPLE Pumping a fluid with a mechanical pump can be represented by an instance of activity.

SUMO says that a physical thing is either a sumo:Object or a sumo:Process. ISO 15926-2 says that a physical thing can be a iso15926-2:physical_object, iso15926-2:activity, iso15926-2:event, or iso15926-2:period_in_time.

NOTE 2 ISO 15926-2 does not explicitly state that a physical thing has to be just one of these, but the layout of the diagramatic presentation suggests that this is the intent.

NOTE 3 ISO 15926-2 is probably wrong in regarding a iso15926-2:period_in_time as not a subclass of iso15926-2:physical_object. ISO 15926-2 regards a quantity of space as a physical object, and it is usual in modern physics to regard space and time as similar.

3.1.2 Types of physical thing

The exact structure at the top of an ontology does not matter very much.

NOTE 1 Many hours of discussion can be wasted on this topic.

The purpose of the structure at the top of the ontology is to specify which relationships are valid for which types of physical thing. These relationship are inherited down the ontology. The principal relationship are discussed in Section Principal relationships.

The top of the ontology for S-TEN, is a variant of that in SUMO and ISO 15926-2 as follows:

A sten:physical_thing is one of:
- sten:classical_object which consists of very many interacting particles for a period;
- sten:classical_object_at_instant which is a sten:classical_object at an instant; or
- non-classical thing which is everything else, including small numbers of particles isolated from the rest of the universe, and a packets of energy.
For a sten:classical_object, time, position and causality are all valid concepts. Non-classical things are not within the scope of S-TEN.
A sten:classical_object can be:
- sten:persistent_object which is created by a sten:activity and which continues to exist until destroyed by another sten:activity; and
- sten:ephemeral_object which is a part of a sten:persistent_object which existed before or continued to exist after.
NOTE 2 The different between sten:persistent_object and sten:ephemeral_object is contentious amonst upper ontologists. An sten:ephemeral_object is something which has been defined by a person for a purpose. The beginning and end of an sten:ephemeral_object is not necessarily obvious to another person. Unfortunately, the same can be sometimes be said for a sten:persistent_object.
There are many types of sten:persistent_object. These include:
- sten:facility, which is an object defined by the role it performs, and which is of interest for operations;
- sten:physical_asset, which is an object defined by defined its material, and which is of interest for materials management;
- computer file, which is an information bearing object defined by a computer system.
EXAMPLE Consider a pump in a process plant. The switch in the control room which operates this pump is labeled "P_101". On 2007-03-19, the pump with serial number "98-1234" is installed as "P_101". A maintenance activity is carried out overnight, so that on 2007-03-20 the pump with serial number "03-5678" is installed.

The object "P_101" is a facility, and is defined by the role it performs. The object "98-1234" is an asset and is defined more or less by the matter it consists of.

The qualification more or less is important, because a major refurbishment may change many of the parts of asset "98-1234". In this case, whether or not an new asset is created is an administrative choice.

NOTE 3 The justification for regarding a computer file as something physical is discussed in Section Information.
There are many types of sten:ephemeral_object. These include:
- sten:period_of_life, which a sten:persistent_object during a sten:period;
- sten:activity, which is one or more instances of sten:period_of_life, and which is defined in order to identify a purpose, cause or result.
NOTE 5 There are particular relationships between an sten:activity and its parts, such as sten:has_input, sten:has_output, sten:creates, sten:destroys, and sten:performed_by.

Top classes in the S-TEN, SUMO and ISO 15926-2 ontologies are shown in Figure 1.

Figure 1: Top of the ontology

3.1.3 Principal relationships

Relationships which are valid for the different types of physical thing are as follows:

relationship	rdfs:Property	rdfs:domain	rdfs:range
whole-part	sten:part_of	sten:physical_thing	sten:physical_thing
whole-part	sten:has_part	sten:physical_thing	sten:physical_thing
temporal whole-part	sten:temporal_part_of	sten:physical_thing	sten:classical_object
temporal whole-part	sten:has_temporal_part	sten:classical_object	sten:physical_thing
assembly	sten:component_of	sten:classical_object	sten:classical_object
assembly	sten:has_component	sten:classical_object	sten:classical_object
at time	sten:at_time	sten:classical_object_at_instant	sten:instant
during	sten:during	physical_thing	sten:part_of_time

EXAMPLE The difference between the relationships sten:part_of, sten:temporal_part_of and sten:component_of is illustrated by Figure 2.

Figure 2: Temporal part and component

In this example:

"object a" has a sten:temporal_part_of relationship with "object X";
"object b" has a sten:component_of relationship with "object X";
"object c" has a sten:part_of (but not sten:temporal_part_of or sten:component_of) relationship with "object X";

3.1.4 Activity and role

An sten:activity (= sumo:Process) is defined in order to identify a purpose, cause or result.

NOTE The SUMO definition is "anything that lasts for a time but is not an Object". This is not enough, because this is true of any sten:period_of_life. An sten:activity is special because it is used to identify roles, such as "input", "output", and "performer".

SUMO identifies the following generic relationships with a sumo:Process:

role	definition
sumo:agent	an active determinant, either animate or inanimate, of the Process with or without voluntary intention.
sumo:experiencer	a passive experiencer of the Process. Note, unlike agent, this does not entail a causal relation.
sumo:patient	a participant in the Process.
sumo:instrument	a sumo:patient that is a tool used in the Process and not changed by it.
sumo:resource	a sumo:patient that is used in the Process and changed by it.
sumo:result	a sumo:patient that is produced by the Process.

S-TEN defines the sten:has_role_player relationship is between an sten:activity and a sten:persistent_object. This is not a relationship with a temporal part (see What is a temporal part). because an sten:activity is specifically defined to express a relationship between instances of sten:persistent_object.

EXAMPLE 1 Consider the manufacturing sten:activity "F. Bloggs production on 2007-04-23". This sten:activity creates the sten:physical_asset with serial number "07/123456". The sten:activity does not create a temporal part of "07/123456", but instead the sten:persistent_object which continues to exist after the sten:activity has finished.

There are many possible roles in an activity, which are specific to the type of activity.

EXAMPLE 2 A meeting activity has the roles:

chair person;
minute taker;
teller (who counts votes); and
attender.

For S-TEN, the roles "input" and "output" have been introduced. The part of speech has also been changed so that the relationships are not identified by nouns and cannot be easily mistaken for objects. (In SUMO, the object "Agent" is distinguished from the relationship "agent" by the capitalisation.) This gives the following generic roles:

role	definition
sten:performed_by	identical to sumo:agent.
sten:has_input	identical to sumo:resource.
sten:has_output	identical to sumo:result.
sten:destroys	a sten:has_input, where the input does not exist after the activity.
sten:creates	a sten:has_output, where the output did not exist before the activity.

A temporal part can be related to an sten:activity by a sten:has_part relationship.

An sten:activity can have a relationship with an object which is neither sten:has_role_player or sten:has_part. Examples of this are:

sten:causes where one sten:activity causes another to happen;
sten:has_input_record and sten:has_output_record where a sten:information_carrier is input or output.
sten:investiates where information is sought about an object which may not play a role in the sten:activity.

3.1.5 Relationships with parts of life

The relationship sten:component_of is a sten:simultaneous_mapping which applies to each temporal part of the part and of the whole.

EXAMPLE 1 The statement:

The gearbox with serial number 98/1234 has a sten:component_of relationship with the car with chassis number 99/4567.

is untrue because the gearbox existed before the car, and may continue to exists after the car if the car is disassembled. If the car has the same gearbox throughout its life, then the correct statement is:

A temporal part of the gearbox with serial number 98/1234 has a sten:component_of relationship with the car with chassis number 99/4567.

Serialised in N3, this statement is:

[ sten:temporal_part_of :98/1234 ]  sten:component_of  :99/4567 .

There is no need to be specific about the start and end times of the temporal part of :98/1234, because this can be deduced from the start and end times of :99/4567.

The relationship sten:has_role_player is a does not apply to temporal parts.

EXAMPLE 2 The statement that Monty Panesar played in the 2006 Perth Test Match can be made as follows:

:2006_Perth_Test_Match sport:has_player :Monty_Panesar .

where sport:has_player is a subProperty of sten:has_role_player.

The statement that Monty Panesar" is part of the 2006 Perth Test Match, is not true, because Monty Panesar existed both before and afterwards. The correct statement, serialised in N3, is:

[ sten:temporal_part_of :Monty_Panesar ]  sten:part_of  :2006_Perth_Test_Match .

If it is necessary to be precise about the temporal parts of Monty Panesar, it is necessary to decide:

whether the 2006 Perth Test Match continues during the tea interval;
whether Monty Panesar is part of the test match whilst sitting in the pavilion waiting for his turn to bat.

3.2 Ontology for physical thing - taxonomy

3.2.1 physical_thing

An object is an sten:physical_thing if and only if it exists in space and time.

NOTE In S-TEN, neither the ISO 15926 nor the SUMO term is used for sten:physical_thing. The reasons are as follows:

The ISO 15926 term "possible individual" implies that the members are "individuals" as commonly understood. As members include packets of energy and single particles, which do not have individuality, this is inappropriate.
The SUMO term "physical" is better, but is an adjective. The most neutral way of making this a noun is to add the suffix "thing".

OWL specification:

-->
<owl:Class rdf:about="&sten;physical_thing">
 <owl:sameAs rdf:resource="&sumo;Physical"/>
 <owl:sameAs rdf:resource="&iso15926-2;possible_individual"/>
 <meta:defined_by rdf:resource="&D2.1;/physical_things.htm#physical_thing"/>
</owl:Class>
<!--

3.2.2 classical_object

An object is an sten:classical_object if and only if:

it is an sten:physical_thing;
it is a large number of interacting particles which exists for finite periods of time.

NOTE 1 A sten:classical_object can have more than one creation and destruction activity because can cease to exist for periods of time.

OWL specification:

-->
<owl:Class rdf:about="&sten;classical_object">
 <rdfs:subClassOf rdf:resource="&sten;physical_thing"/>
 <meta:defined_by rdf:resource="&D2.1;/physical_things.htm#classical_object"/>
</owl:Class>
<!--

3.2.3 classical_object_at_instant

An object is an sten:classical_object_at_instant if and only if:

it is an sten:physical_thing;
it is a sten:classical_object at an instant.

OWL specification:

-->
<owl:Class rdf:about="&sten;classical_object_at_instant">
 <rdfs:subClassOf rdf:resource="&sten;physical_thing"/>
 <rdfs:subClassOf rdf:resource="&sumo;Object"/>
 <owl:sameAs rdf:resource="&iso15926-2;event"/>
 <meta:defined_by rdf:resource="&D2.1;/physical_things.htm#classical_object_at_instant"/>
</owl:Class>
<!--

3.2.4 persistent_object

An object is an sten:persistent_object if and only if:

it is an sten:classical_object;
the periods of time during which it exists results from creation and destruction activities.

NOTE 1 A single sten:persistent_object can have more than one creation and destruction activity because can cease to exist for periods of time.

OWL specification:

-->
<owl:Class rdf:about="&sten;persistent_object">
 <rdfs:subClassOf rdf:resource="&sten;classical_object"/>
 <owl:sameAs rdf:resource="&iso15926-2;whole_life_individual"/>
 <rdfs:subClassOf rdf:resource="&iso15926-2;physical_object"/>
 <meta:defined_by rdf:resource="&D2.1;/physical_things.htm#persistent_object"/>
</owl:Class>
<!--

3.2.5 ephemeral_object

An object is an sten:ephemeral_object if and only if:

it is an sten:classical_object;
its spatial and temporal boundaries are a choice to support the recording of information.

NOTE A boundary of an sten:ephemeral_object in time or space is not necessarily be obvious to an observer.

OWL specification:

-->
<owl:Class rdf:about="&sten;ephemeral_object">
 <rdfs:subClassOf rdf:resource="&sten;classical_object"/>
 <meta:defined_by rdf:resource="&D2.1;/physical_things.htm#ephemeral_object"/>
</owl:Class>
<!--

3.2.6 facility

An object is a sten:facility if and only if:

it is a sten:persistent_object;
it is created by commissioning activities and is destroyed by decomissioning activities.

NOTE 1 A sten:facility is operated. The creation and destruction activities are recognised as such by the operator. A single sten:facility can have more than one creation activity because it can cease to exist for periods of time.

NOTE 2 A sten:facility is distinguished from a sten:physical_asset by the nature of the creation and destruction activities. A sten:facility is created when physical assets are combined into a whole that can be operated.

NOTE 3 The quantity of matter that is a facility can change during the life of the facility, by the removal of some matter and the addition of other matter. It often changes completely, so that all the matter previously present is removed and replaced by different matter.

EXAMPLE The feedwater pump for boiler "B_101" is a facility with tag "P_101". Operating the boiler involves operating pump "P_101". The quantity of matter that is pump "P_101" changes a little whenever pump "P_101" is maintained, perhaps by replacing a seal or a bearing.

If the pump with serial number 98-1234 is installed as "P_101" until 2006-10-16, and is then replace by the pump with serial number 06-4567, then the quantity of matter that is pump "P_101" changes completely on 2006-10-16.

OWL specification:

-->
<owl:Class rdf:about="&sten;facility">
 <rdfs:subClassOf rdf:resource="&sten;persistent_object"/>
 <meta:defined_by rdf:resource="&D2.1;/physical_things.htm#facility"/>
</owl:Class>
<!--

3.2.7 physical_asset

An object is a sten:physical_asset if and only if:

it is a sten:persistent_object;
it is created by an assembly or fabrication activity and is ended by a disassembly or recycling activity.

NOTE 1 A sten:physical_asset is owned and maintained. The creation and destruction activities are recognised by the owner or maintainer.

NOTE 2 The quantity of matter that is a physical_asset can change during the life of the physical_asset, by the removal of some matter and the addition of other matter. There is only rarely a complete change, in which that all the matter previously present is removed and replaced by different matter.

EXAMPLE The pump with serial number "98-1234" is a physical_asset. This pump is recorded in the inventory of equipment owned by J. Bloggs and Co..

If the pump with serial number 98-1234 is maintained by replacing the bearings and seals, the the quantity of matter changes, but the physical_asset continues to exist. Replacing the body of the pump would probably be regarded as a manufacturing a new physical_asset, rather than a maintenance activity carried out on a existing physical_asset.

OWL specification:

-->
<owl:Class rdf:about="&sten;physical_asset">
 <rdfs:subClassOf rdf:resource="&sten;persistent_object"/>
 <meta:defined_by rdf:resource="&D2.1;/physical_things.htm#physical_asset"/>
</owl:Class>
<!--

3.2.8 period_of_life

An object is a sten:period_of_life if and only if:

it is an sten:ephemeral_object;
the sten:period during which it exists is a choice to support the recording of information.

OWL specification:

-->
<owl:Class rdf:about="&sten;period_of_life">
 <rdfs:subClassOf rdf:resource="&sten;ephemeral_object"/>
 <rdfs:subClassOf rdf:resource="&iso15926-2;physical_object"/>
 <meta:defined_by rdf:resource="&D2.1;/physical_things.htm#period_of_life"/>
</owl:Class>
<!--

3.2.9 activity

An object is an sten:activity if and only if:

it is an sten:ephemeral_object;
it is defined in order to identify a purpose, cause or result.

NOTE The ISO 15926 term "activity" is prefered to the SUMO term "process", because it is more general and does not imply that there is an intention or that there is a well defined outcome.

OWL specification:

-->
<owl:Class rdf:about="&sten;activity">
 <rdfs:subClassOf rdf:resource="&sten;ephemeral_object"/>
 <owl:sameAs rdf:resource="&sumo;Process"/>
 <owl:sameAs rdf:resource="&iso15926-2;activity"/>
 <meta:defined_by rdf:resource="&D2.1;/physical_things.htm#activity"/>
</owl:Class>
<!--

3.2.10 set_of_physical_thing

An object is a sten:set_of_physical_things if and only if it is the powerset of sten:physical_thing.

OWL specification:

-->
<owl:Class rdf:about="&sten;set_of_physical_things">
 <owl:equivalentClass>
  <owl:Restriction>
   <owl:onProperty rdf:resource="&rdfs;subClassOf"/>
   <owl:someValuesFrom>
    <Class>
     <owl:oneOf rdf:parseType="Collection">
      <owl:Class rdf:about="&sten;physical_thing"/>
     </owl:oneOf>
    </Class>
   </owl:someValuesFrom>
  </owl:Restriction>
 </owl:equivalentClass>
 <meta:defined_by rdf:resource="&D2.1;/physical_things.htm#set_of_physical_things"/>
</owl:Class>
<!--

3.2.11 set_of_persistent_objects

An object is a sten:set_of_persistent_objects if and only if it is the powerset of sten:persistent_object.

OWL specification:

-->
<owl:Class rdf:about="&sten;set_of_persistent_objects">
 <owl:equivalentClass>
  <owl:Restriction>
   <owl:onProperty rdf:resource="&rdfs;subClassOf"/>
   <owl:someValuesFrom>
    <Class>
     <owl:oneOf rdf:parseType="Collection">
      <owl:Class rdf:about="&sten;persistent_object"/>
     </owl:oneOf>
    </Class>
   </owl:someValuesFrom>
  </owl:Restriction>
 </owl:equivalentClass>
 <rdfs:subClassOf rdf:resource="&sten;set_of_physical_things"/>
 <meta:defined_by rdf:resource="&D2.1;/physical_things.htm#set_of_persistent_objects"/>
</owl:Class>
<!--

3.2.12 device

An object is a sten:device if and only if:

it is a sten:persistent_object;
it is made by people so that it can be used when required to perform an sten:activity.

NOTE A sten:device can be either a sten:facility or a sten:physical_asset.

OWL specification:

-->
<owl:Class rdf:about="&sten;device">
 <rdfs:subClassOf rdf:resource="&sten;persistent_object"/>
 <meta:defined_by rdf:resource="&D2.1;/physical_things.htm#device"/>
</owl:Class>
<!--

3.2.13 device_supplier

An object is a sten:device_supplier if and only if:

it is a sten:persistent_object;
it is a person or an organisation that supplies a sten:device and specifies what it is intended for.

OWL specification:

-->
<owl:Class rdf:about="&sten;device_supplier">
 <rdfs:subClassOf rdf:resource="&sten;persistent_object"/>
 <meta:defined_by rdf:resource="&D2.1;/physical_things.htm#device_supplier"/>
</owl:Class>
<!--

3.3 Ontology for physical thing - properties

3.3.1 has_part

An object is an sten:has_part relationship if and only if:

it is a basics:mapping relationship between sten:physical_thing and sten:physical_thing;
all the matter which is the part is also part of the whole for all of its life.

NOTE 1 The definition above is recursive. SUMO says merely: "The basic mereological relation."

NOTE 2 A set of sten:has_part relationships can specify that each member of a set S is a part of X. However:

there may be parts of X which are not members of S; and
there may be parts of X which are parts of more than one member of S.

Hence a set of has_part relationships cannot be used to calculate the mass of X from the mass of its parts. In order to calculate properties of the whole, from properties of the parts, it is necessary to use a sten:has_partition relationship.

OWL specification:

-->
<owl:TransitiveProperty rdf:about="&sten;has_part">
 <rdfs:domain rdf:resource="&sten;physical_thing"/>
 <rdfs:range rdf:resource="&sten;physical_thing"/>
 <owl:sameAs rdf:resource="&sumo;part"/>
 <rdfs:subPropertyOf rdf:resource="&iso15926-2;composition_of_individual.part"/>
 <rdfs:subPropertyOf rdf:resource="&sumo;part"/>
 <meta:defined_by rdf:resource="&D2.1;/physical_things.htm#has_part"/>
</owl:TransitiveProperty>
<!--

3.3.2 part_of

An object is a sten:part_of relationship if and only if:

it is a basics:mapping relationship between sten:physical_thing and sten:physical_thing;
it is the inverse of sten:has_part.

OWL specification:

-->
<owl:TransitiveProperty rdf:about="&sten;part_of">
 <owl:inverseOf rdf:resource="&sten;has_part"/>
 <rdfs:domain rdf:resource="&sten;physical_thing"/>
 <rdfs:range rdf:resource="&sten;physical_thing"/>
 <rdfs:subPropertyOf rdf:about="&iso15926-2;composition_of_individual.whole"/>
 <meta:defined_by rdf:resource="&D2.1;/physical_things.htm#part_of"/>
</owl:TransitiveProperty>
<!--

3.3.3 has_component

An object is an sten:has_component relationship if and only if:

it is a sten:has_part relationship;
there is a sten:has_part relationships between each temporal part of the whole and a temporal part of the part;
there is a sten:part_of relationships between each temporal part of the part and a temporal part of the whole.

OWL specification:

-->
<owl:TransitiveProperty rdf:about="&sten;has_component">
 <rdfs:subPropertyOf rdf:resource="&sten;has_part"/>
 <rdfs:domain rdf:resource="&sten;classical_object"/>
 <rdfs:range rdf:resource="&sten;classical_object"/>
 <meta:defined_by rdf:resource="&D2.1;/physical_things.htm#has_component"/>
</owl:TransitiveProperty>
<!--

3.3.4 component_of

An object is a sten:component_of relationship if and only if:

it is a sten:part_of relationship;
it is the inverse of sten:has_component.

OWL specification:

-->
<owl:TransitiveProperty rdf:about="&sten;component_of">
 <rdfs:subPropertyOf rdf:resource="&sten;part_of"/>
 <owl:inverseOf rdf:resource="&sten;has_component"/>
 <rdfs:domain rdf:resource="&sten;classical_object"/>
 <rdfs:range rdf:resource="&sten;classical_object"/>
 <meta:defined_by rdf:resource="&D2.1;/physical_things.htm#component_of"/>
</owl:TransitiveProperty>
<!--

3.3.5 has_partition

An object is a sten:has_partition relationship if and only if:

it is a basics:mapping from sten:physical_thing to sten:set_of_physical_things;
each part of the sten:physical_thing is a part of exactly one member of the sten:set_of_physical_things.

NOTE A partition of a topology:directed_manifold_edge into an topology:open_path is specified by a topology:decomposition_of_directed_manifold_edge. This relationship can be used to partition a sten:period_of_life into an basics:ordered_set of temporal parts.

OWL specification:

-->
<owl:ObjectProperty rdf:about="&sten;has_partition">
 <rdfs:domain rdf:resource="&sten;physical_thing"/>
 <rdfs:range rdf:resource="&sten;set_of_physical_things"/>
 <meta:defined_by rdf:resource="&D2.1;/physical_things.htm#has_partition"/>
</owl:ObjectProperty>
<!--

3.3.6 partition_of

An object is a sten:partition_of relationship if and only if:

it is a basics:partial_function from sten:set_of_physical_things to sten:physical_thing;
it is the inverse of sten:has_partition.

OWL specification:

-->
<owl:ObjectProperty rdf:about="&sten;partition_of">
 <rdf:type rdf:resource="&basics;partial_function"/>
 <rdfs:domain rdf:resource="&sten;set_of_physical_things"/>
 <rdfs:range rdf:resource="&sten;physical_thing"/>
 <owl:inverseOf rdf:resource="&sten;has_partition"/>
 <meta:defined_by rdf:resource="&D2.1;/physical_things.htm#partition_of"/>
</owl:ObjectProperty>
<!--

3.4 Relationships with an activity

3.4.1 has_role_player

An object is a sten:has_role_player relationship if and only if:

it is a basics:mapping from sten:activity to sten:persistent_object;
the sten:persistent_object plays a role in the sten:activity.

NOTE A temporal part of the sten:persistent_object has a sten:part_of relationship with the sten:activity.

OWL specification:

-->
<owl:ObjectProperty rdf:about="&sten;has_role_player">
 <rdfs:domain rdf:resource="&sten;activity"/>
 <rdfs:range rdf:resource="&sten;persistent_object"/>
 <meta:defined_by rdf:resource="&D2.1;/physical_things.htm#has_role_player"/>
</owl:ObjectProperty>
<!--

3.4.2 plays_role_in

An object is a sten:plays_role_in relationship if and only if:

it is a basics:mapping from sten:persistent_object to sten:activity;
the sten:persistent_object plays a role in the sten:activity.

NOTE A temporal part of the sten:persistent_object has a sten:part_of relationship with the sten:activity.

OWL specification:

-->
<owl:ObjectProperty rdf:about="&sten;plays_role_in">
 <rdfs:domain rdf:resource="&sten;persistent_object"/>
 <rdfs:range rdf:resource="&sten;activity"/>
 <owl:inverseOf rdf:resource="&sten;has_role_player"/>
 <meta:defined_by rdf:resource="&D2.1;/physical_things.htm#plays_role_in"/>
</owl:ObjectProperty>
<!--

3.4.3 performs

An object is a sten:performs relationship if and only if:

it is a sten:plays_role_in relationship;
the sten:period_of_life is a part of the sten:activity;
sten:persistent_object is regarded as being a cause of the sten:activity.

OWL specification:

-->
<owl:ObjectProperty rdf:about="&sten;performs">
 <rdfs:domain rdf:resource="&sten;persistent_object"/>
 <rdfs:range rdf:resource="&sten;activity"/>
 <rdfs:subPropertyOf rdf:resource="&sten;plays_role_in"/>
 <meta:defined_by rdf:resource="&D2.1;/physical_things.htm#performs"/>
</owl:ObjectProperty>
<!--

3.4.4 performed_by

An object is an sten:performed_by relationship if and only if:

it is a sten:has_role_player relationship;
it is the inverse of sten:performs.

OWL specification:

-->
<owl:ObjectProperty rdf:about="&sten;performed_by">
 <owl:inverseOf rdf:resource="&sten;performs"/>
 <rdfs:domain rdf:resource="&sten;activity"/>
 <rdfs:range rdf:resource="&sten;persistent_object"/>
 <owl:sameAs rdf:resource="&sumo;agent"/>
 <rdfs:subPropertyOf rdf:resource="&sten;has_role_player"/>
 <meta:defined_by rdf:resource="&D2.1;/physical_things.htm#performed_by"/>
</owl:ObjectProperty>
<!--

3.4.5 input_to

An object is an sten:input_to relationship if and only if:

it is a sten:plays_role_in relationship;
the sten:persistent_object is used by the sten:activity.

OWL specification:

-->
<owl:ObjectProperty rdf:about="&sten;input_to">
 <rdfs:domain rdf:resource="&sten;persistent_object"/>
 <rdfs:range rdf:resource="&sten;activity"/>
 <rdfs:subPropertyOf rdf:resource="&sten;plays_role_in"/>
 <meta:defined_by rdf:resource="&D2.1;/physical_things.htm#input_to"/>
</owl:ObjectProperty>
<!--

3.4.6 has_input

An object is an sten:has_input relationship if and only if:

it is a sten:has_role_player relationship;
it is the inverse of sten:input_to.

OWL specification:

-->
<owl:ObjectProperty rdf:about="&sten;has_input">
 <owl:inverseOf rdf:resource="&sten;input_to"/>
 <rdfs:domain rdf:resource="&sten;activity"/>
 <rdfs:range rdf:resource="&sten;persistent_object"/>
 <owl:sameAs rdf:resource="&sumo;resource"/>
 <rdfs:subPropertyOf rdf:resource="&sten;has_role_player"/>
 <meta:defined_by rdf:resource="&D2.1;/physical_things.htm#has_input"/>
</owl:ObjectProperty>
<!--

3.4.7 has_set_of_inputs

An object is an sten:has_set_of_inputs relationship if and only if:

it is a basics:function from sten:activity to sten:set_of_persistent_objects;
the sten:set_of_persistent_objects contains each sten:persistent_object that is sten:input_to the sten:activity.

NOTE A possible alternative approach is the specification of a single input which can be partitioned into a set of inputs as required. The alternative does not satisfy all requirements because sten:persistent_object is an input is a choice, and the partition of a single input is also a choice.

OWL specification:

-->
<owl:FunctionalProperty rdf:about="&sten;has_set_of_inputs">
 <rdfs:domain rdf:resource="&sten;activity"/>
 <rdfs:range rdf:resource="&sten;set_of_persistent_objects"/>
 <meta:defined_by rdf:resource="&D2.1;/physical_things.htm#has_set_of_inputs"/>
</owl:FunctionalProperty>
<!--

3.4.8 output_from

An object is an sten:output_from relationship if and only if:

it is a sten:plays_role_in relationship;
the sten:persistent_object is produced by the sten:activity.

OWL specification:

-->
<owl:ObjectProperty rdf:about="&sten;output_from">
 <rdfs:domain rdf:resource="&sten;persistent_object"/>
 <rdfs:range rdf:resource="&sten;activity"/>
 <rdfs:subPropertyOf rdf:resource="&sten;plays_role_in"/>
 <meta:defined_by rdf:resource="&D2.1;/physical_things.htm#output_from"/>
</owl:ObjectProperty>
<!--

3.4.9 has_output

An object is an sten:has_output relationship if and only if:

it is a sten:has_role_player relationship;
it is the inverse of sten:output_from.

OWL specification:

-->
<owl:ObjectProperty rdf:about="&sten;has_output">
 <owl:inverseOf rdf:resource="&sten;output_from"/>
 <rdfs:domain rdf:resource="&sten;activity"/>
 <rdfs:range rdf:resource="&sten;persistent_object"/>
 <owl:sameAs rdf:resource="&sumo;resource"/>
 <rdfs:subPropertyOf rdf:resource="&sten;has_role_player"/>
 <meta:defined_by rdf:resource="&D2.1;/physical_things.htm#has_output"/>
</owl:ObjectProperty>
<!--

3.4.10 has_set_of_outputs

An object is an sten:has_set_of_outputs relationship if and only if:

it is a basics:function from sten:activity to sten:set_of_persistent_objects;
the sten:set_of_persistent_objects contains each sten:persistent_object that is sten:output_from the sten:activity.

NOTE A possible alternative approach is the specification of a single output which can be partitioned into a set of outputs as required. The alternative does not satisfy all requirements because sten:persistent_object is an output is a choice, and the partition of a single input is also a choice.

OWL specification:

-->
<owl:FunctionalProperty rdf:about="&sten;has_set_of_outputs">
 <rdfs:domain rdf:resource="&sten;activity"/>
 <rdfs:range rdf:resource="&sten;set_of_persistent_objects"/>
 <meta:defined_by rdf:resource="&D2.1;/physical_things.htm#has_set_of_outputs"/>
</owl:FunctionalProperty>
<!--

3.4.11 creates

An object is a sten:creates relationship if and only if:

it is a sten:has_output relationship;
the sten:persistent_object does not exist before the sten:activity.

OWL specification:

-->
<owl:ObjectProperty rdf:about="&sten;creates">
 <rdfs:subPropertyOf rdf:resource="&sten;has_output"/>
 <rdfs:domain rdf:resource="&sten;activity"/>
 <rdfs:range rdf:resource="&sten;persistent_object"/>
 <meta:defined_by rdf:resource="&D2.1;/physical_things.htm#creates"/>
</owl:ObjectProperty>
<!--

3.4.12 created_by

An object is an sten:created_by relationship if and only if:

it is a sten:output_from relationship;
it is the inverse of sten:creates.

OWL specification:

-->
<owl:ObjectProperty rdf:about="&sten;created_by">
 <owl:inverseOf rdf:resource="&sten;creates"/>
 <rdfs:domain rdf:resource="&sten;persistent_object"/>
 <rdfs:range rdf:resource="&sten;activity"/>
 <meta:defined_by rdf:resource="&D2.1;/physical_things.htm#created_by"/>
</owl:ObjectProperty>
<!--

3.4.13 destroys

An object is a sten:destroys relationship if and only if:

it is a sten:has_input relationship;
the sten:persistent_object does not exist after the sten:activity.

OWL specification:

-->
<owl:ObjectProperty rdf:about="&sten;destroys">
 <rdfs:subPropertyOf rdf:resource="&sten;has_input"/>
 <rdfs:domain rdf:resource="&sten;activity"/>
 <rdfs:range rdf:resource="&sten;persistent_object"/>
 <meta:defined_by rdf:resource="&D2.1;/physical_things.htm#destroys"/>
</owl:ObjectProperty>
<!--

3.4.14 destroyed_by

An object is an sten:destroyed_by relationship if and only if:

it is a sten:input_to relationship;
it is the inverse of sten:destroys.

OWL specification:

-->
<owl:ObjectProperty rdf:about="&sten;destroyed_by">
 <owl:inverseOf rdf:resource="&sten;destroys"/>
 <rdfs:domain rdf:resource="&sten;persistent_object"/>
 <rdfs:range rdf:resource="&sten;activity"/>
 <meta:defined_by rdf:resource="&D2.1;/physical_things.htm#destroyed_by"/>
</owl:ObjectProperty>
<!--

3.4.15 causes

An object is a sten:causes relationship if and only if:

it is a basics:mapping from sten:activity to itself;
the domain sten:activity causes the range sten:activity.

OWL specification:

-->
<owl:ObjectProperty rdf:about="&sten;causes">
 <rdfs:domain rdf:resource="&sten;activity"/>
 <rdfs:range rdf:resource="&sten;activity"/>
 <meta:defined_by rdf:resource="&D2.1;/physical_things.htm#causes"/>
</owl:ObjectProperty>
<!--

3.4.15 caused_by

An object is a sten:caused_by relationship if and only if:

it is a basics:mapping from sten:activity to itself;
the domain sten:activity is caused by the range sten:activity.

OWL specification:

-->
<owl:ObjectProperty rdf:about="&sten;caused_by">
 <rdfs:domain rdf:resource="&sten;activity"/>
 <rdfs:range rdf:resource="&sten;activity"/>
 <owl:inverseOf rdf:resource="&sten;causes"/>
 <meta:defined_by rdf:resource="&D2.1;/physical_things.htm#caused_by"/>
</owl:ObjectProperty>
<!--

3.5 Physical thing and structure

3.5.1 Why there is a difference

A sten:physical_thing is something that exists in the real world and may have immense complexity. It is often not possible to say of a physical object "it has a structure of type A", because if it is looked at in more detail a more complicated structure is discovered.

A basics:structure is specified set of things with specified relationships. A basics:structure is different to a sten:physical_thing, because for a sten:physical_thing there is no specified "set of things" or relationships.

NOTE 2 A simple subclass of basics:structure is basics:topological_object. This is a set of things and a subset of the powerset, which defines the nearness of the things.

The class basics:structure and its subclasses is defined in ISO 15926-3.

The class basics:structure is a subclass of the class iso15926-2:abstract_object. ISO 15926-2 says that a thing is either a iso15926-2:possible_individual or an iso15926-2:abstract_object, but not both. This is probably correct, but it is not practical because most (perhaps all) statements about a sten:physical_thing rely upon the assumption of a structure. If the separation of structures from physical things is followed to the letter, then we end up with an instantiation such that:

a sten:physical_thing is identified, but it is just a "concept" about which few statements made;
a sten:physical_thing is associated with one or more instances of structure which are models of the sten:physical_thing; and
statements made about the models.

This is very irritating to work with and turns the straightforward statement "A is part of B", into "there is a model of B which has a part which is a model of A". Two avoid this, we explicitly violate the rules of ISO 15926-2 and assume that a sten:physical_thing is also a basics:structure.

3.5.2 Space time and manifold

A quantity of space-time is a sten:physical_thing and it is usually convenient to regard it as a 4D manifold, even if this may not be true at extremely small scales.

We can produce reduced dimensions views of space time. Hence we can regard a volume of space for a period of time as a 3D manifold of temporal fibres.

EXAMPLE The volume "my_volume_of_space" is regarded as both a sten:physical_thing and a basics:structure. This is a pragmatic violation if ISO 15926-2.

:my_volume_of_space a sten:physical_thing ;
                    a sten:manifold_of_temporal_fibres ;
                    a solid:solid_sphere ;
                    geometry_basics:has_radius [ sten:metre_scale [basics:decimal "10.0 ] ] .

The class basics:manifold is a subclass of basics:structure. The classes sten:manifold_of_temporal_fibres and solid:solid_sphere are subclasses of basics:manifold.

3.5.3 Physical object and manifold

A sten:classical_object is a sten:physical_thing that consists of large numbers of interacting atoms or molecules. A sten:classical_object obeys the laws of classical physics, and has entropy.

A sten:classical_object is often assumed to be a basics:manifold, even though this is wrong because matter is made up of atoms and molecules. Examples, of this are as follows.

EXAMPLE 1 The temperature distribution within "my_forged_part" is recorded at instant "t1" during the forging process. The domain of the distribution is assumed to be a 3D manifold of material points.

:my_forged_part_at_t1 a            sten:classical_object_at_instant ;
                      a            basics:manifold_3D .

:temperature_distribution_in_my_forged_part_at_t1
                      a            owl:FunctionalProperty ;
                      rdfs:domain  :my_forged_part_at_t1 ;
                      rdfs:range   iso31:temperature ;
                      rdfs:comment "... and properties which define the distribution" .

A basics:structure can be the domain or range of a function.

EXAMPLE 2 The sten:physical_asset "my_physical_asset", is assumed to be a 1D manifold of temporal instants. The temporal part "my_physical_asset_in_2007-02" is specified by a start and end instant.

:my_physical_asset    a sten:physical_asset ;
                      a basics:manifold_1d .

:my_physical_asset_in_2007-02
                      a sten:period_of_life ;
                      a sten:temporal_part_of :my_physical_asset ;
                      a topology:directed_manifold_edge ;
                      topology:end_1
                        [ a sten:classical_object_at_instant ;
                          sten:at_time [ sten:utc_iso8601 2007-01-31T24:00 ] ;
                      topology:end_2
                        [ a sten:classical_object_at_instant ;
                          sten:at_time [ sten:utc_iso8601 2007-02-28T24:00 ] .

The properties topology:end_1 and topology:end_2 are defined for the class topology:directed_manifold_edge. The instances of sten:classical_object_at_instant are defined by the times at which they occur.

Time can also be regarded as a basics:manifold_1D of temporal planes. This gives an alternative way of specifying "my_physical_asset_in_2007-02", as follows:

:my_physical_asset_in_2007-02
                      a sten:period_of_life ;
                      a sten:temporal_part_of :my_physical_asset ;
                      sten:during
                        [ topology:end_1
                           [ sten:utc_iso8601 2007-01-31T24:00 ]
                         topology:end_2
                           [ sten:utc_iso8601 2007-02-28T24:00 ] ] .

Manifolds are not the only structures of interest.

EXAMPLE 3 The hired asset "my_hired_asset" is on a daily contract. Hence this object can be regarded conveniently as a finite ordered set of one day temporal parts.

:my_hired_asset       a sten:period_of_life ;
                      a basics:finite_set ;
                      a basics:ordered_set ;
                      sten:first
                       [ a      sten:period_of_life ;
                         during [ sten:has_nominal_value
                                      [ sten:utc_iso8601 2007-02-01 ] ] ;
                      sten:last
                       [ a      sten:period_of_life ;
                         during [ sten:has_nominal_value
                                      [ sten:utc_iso8601 2007-02-28 ] ] .

3.5.4 Physical quantity space and manifold

ISO 31-0 says 'Physical quantities may be grouped together into categories of quantities which are mutually comparable. Lengths, diameters, distances, heights, wavelengths and so on would constitute such a category. Mutually comparable quantities are called "quantities of the same kind".'

A sten:physical_quantity_space consists of all quantities of a kind.

A sten:physical_quantity_space has a structure. The fact that the members are "mutually comparable" requires that they have a structure. This is discussed by Leal, Partridge and West [1])

EXAMPLE "Thermodynamic temperature" is a sten:physical_quantity_space. Thermodynamic temperature has structure, because its members can be added, subtracted, and multiplied by real numbers. Its members are also a basics:manifold_1d. Hence a temperature range can be defined by an topology:end_1 and an topology:end_2.

The sten:physical_quantity_space "thermodynamic_temperature" and the temperature range "comfortable_room_temperature" are defined below.

iso31:thermodynamic_temperature a basics:manifold_1d ;
                                a basics:ordered_set .

:comfortable_room_temperature
                          a basics:directed_manifold_edge ;
                          basics:has_defining_superstructure iso31:thermodynamic_temperature ;
                          topology:end_1 [ bipm:celsius [basics:decimal 20.0 ] ] ;
                          topology:end_2 [ bipm:celsius [basics:decimal 28.0 ] ] .

3.5.4 Physical things and mereotopology

The criteria for being a manifold are very stringent. Object which obey these criteria have properties which are unlike those of most (perhaps all) physical things. If the only statements you need to make about a sten:physical_thing are part-whole relationships, then it is not necessary to assume that a sten:physical_thing is a basics:manifold. Instead it is only necessary to assume that a sten:physical_thing has "mereotopology" (see Stell and West [2]).

The criteria for being a "mereotopological object" are less stringent than the criteria for being a manifold and are more similar to the real world. Nonetheless a merotopological object is an ISO15926-2:abstract_object just the same, so that an assumption of mereotopology also violates ISO 15926-2.

The mathematics of merotopological objects is less familiar than the mathematics of manifolds, and a manifold assumption gives the same result for whole-part relationships. Hence in many cases, assuming that a sten:physical_thing is a manifold is pragmatic.

[1] Leal, D, Partidge C. and West, M., Property and Structure, unpublished working document for use by standards developers, 2006-07-27

[2] Stell, J. G. and West, M., in: Varzi,A. C. , and Vieu, L. (Eds) Formal Ontology in Information Systems . Proceedings of the third International Conference (FOIS-2004) IOS Press, pp261-272, 2004. (http://www.comp.leeds.ac.uk/jgs/StellWestFOIS2004Final.pdf)

3.6 Physical thing and structure

NOTE Most of this section is just mathermatics, and belongs in some other ontology.

3.6.1 selection_from

An object is an sten:selection_from relationship if and only if:

it is a basics:mapping from owl:Class (the selection) to owl:Class (the set of classes) which is a set of disjoint classes;
the selection consists one member from each of the set of classes.

EXAMPLE The class {a, x} has a sten:selection_from relationship with {{a, b}, {x, y}}.

The owl:Restriction class defined by:

owl:onProperty sten:selection_from;
owl:someValuesFrom {{{a, b}, {x, y}}},

is {{a, x}, {a, y}, {b, x}, {b, y}}.

OWL specification:

-->
<owl:ObjectProperty rdf:about="&sten;selection_from">
 <rdfs:domain rdf:resource="&owl;Class"/>
 <rdfs:range>
  <owl:Restriction>
   <owl:onProperty rdf:resource="rdfs;subClassOf"/>
   <owl:someValuesFrom rdf:resource="owl;Class"/>
  </owl:Restriction>
 </rdfs:range>
 <meta:defined_by rdf:resource="&D2.1;/physical_things.htm#selection_from"/>
</owl:ObjectProperty>
<!--

3.6.2 less_than

An object is an sten:less_than relationship if and only if:

it is a basics:mapping between two instances of basics:structure_point within an basics:ordered_set;
the domain object is before the range object.

OWL specification:

-->
<owl:ObjectProperty rdf:about="&sten;less_than">
 <rdfs:domain rdf:resource="&basics;structure_point"/>
 <rdfs:range rdf:resource="&basics;structure_point"/>
 <meta:defined_by rdf:resource="&D2.1;/physical_things.htm#less_than"/>
</owl:ObjectProperty>
<!--

3.6.3 greater_than

An object is an sten:greater_than relationship if and only if:

it is a basics:mapping between two instances of basics:structure_point within an basics:ordered_set;
the domain object is after the range object.

OWL specification:

-->
<owl:ObjectProperty rdf:about="&sten;greater_than">
 <rdfs:domain rdf:resource="&basics;structure_point"/>
 <rdfs:range rdf:resource="&basics;structure_point"/>
 <meta:defined_by rdf:resource="&D2.1;/physical_things.htm#greater_than"/>
</owl:ObjectProperty>
<!--