Metadata specification for Discrete Event Systems
Specification (DEVS) simulation models

Version: 1.0

Summary

This metadata specification documents Discrete Event Systems Specification (DEVS) simulation models with the goal of supporting model discoverability, composability and reusability. The specification aims to strike a balance between convenience and useful preservation of models for future use.

The specification subsets relevant elements of the Dublin Core Metadata Initiative (DCMI) and adds a DEVS specific set of metadata properties. Most properties of the DCMI used are specialized by assuming that the documented resource is a DEVS simulation model

Table of contents

1. Specification overview

1.1 Descriptive metadata

element summary mandatory repeatable
identifier An unambiguous reference to a resource. ×
title Name given to the model. × ×
alternative Alternative name to the model title. ×
creator Person or organization responsible for developing the model. ×
contributor Person or organization contributing to the development of the model. ×
type Identifies whether the DEVS model is “atomic” or “coupled”. ×
language Language of the model (i.e. English, French, etc.) ×
description A summary description of the model. ×
subject A topic for the model. ×
spatial_coverage Spatial coverage for which the model can be used. ×
placename Name of the location for which the model can be used. ×
extent Spatial coverage specified by geographic extent. ×
reference Spatial reference for the spatial coverage (i.e. epsg 4326). ×
x_min Minimum x coordinate for the spatial coverage. ×
x_max Maximum x coordinate for the spatial coverage. ×
y_min Minimum y coordinate for the spatial coverage. ×
y_max Maximum y coordinate for the spatial coverage. ×
temporal_coverage Temporal coverage for which the model can be used. ×
start Start date or time of the temporal coverage. ×
end End date or time of the temporal coverage. ×
scheme Date or time schema used to represent the temporal coverage. ×

1.2 Administrative metadata

element summary mandatory repeatable
license A legal document giving official permission to do something with the model. ×

1.3 Technical metadata

element summary mandatory repeatable
created Date of creation for the model. ×
modified Date on which the model was changed. ×

1.4 DEVS specific metadata

element summary mandatory repeatable
time Time representation used for the model. ×
behavior High level description of the model’s behavior. ×
state State of the model. Only applicable to "atomic" models.
description High level description of the model’s state.
message State message type unique identifier. ×
subcomponent A subcomponent model instance of the coupled model, only applicable for “coupled” models. ×
identifier Identifier for the subcomponent, unique within a coupled model. ×
model Unique identifier reference for the model used for the subcomponent. ×
coupling A coupling between an origin and destination model, only applicable for “coupled” models. ×
from_model Origin subcomponent unique identifier for the coupling. ×
from_port Origin subcomponent port for the coupling. ×
to_model Destination subcomponent unique identifier for the coupling. ×
to_port Destination subcomponent port for the coupling. ×
port An input or output port of the model. ×
type Indicates whether the port is an “input” port or an “output” port. ×
name Non unique name of the port. ×
message Message type unique identifier. ×
message Message type used by the model. ×
identifer Unique identifier for the message type. ×
field A field of the message type. × ×
name Name of the field, unique within the message type. ×
description Description of the field. ×
type Indicates whether the field value is “nominal”, “numerical” or “ordinal”. ×
uom Unit of measure used for the field, only for “numerical” values.
scalar Scalar factor applied to the value, only for “numerical” values.
decimals Number of decimal digits, only for “numerical” values.

2. Elements of the specification

Each element of the specification is described using the following attributes:

Element Name
Label The human-readable label assigned to the element.
Definition A statement that represents the concept and essential nature of the element.
Comment Additional information about the element or its application.
Cardinality Indicates whether the element is "mandatory", "optional" and/or "repeatable".
Sub-element of An element of which the described term is a Sub-element.
Domain A list of acceptable values for this element.
Examples A series of example values that can be assigned to the element.

2.1 Elements of descriptive metadata

Element Name: identifier
Label identifier
Definition An unambiguous reference to a resource.
Comment Recommended practice is to identify the resource by means of a string conforming to an identification system (i.e. UUID).
Cardinality mandatory
Sub-element of
Domain
Examples b867ca77-ee01-46bc-9ee2-71a0110f13f2

Element Name: title
Label title
Definition Name given to the model.
Comment
Cardinality mandatory, repeatable
Sub-element of
Domain
Examples Hospital Case Load

Element Name: alternative
Label alternative
Definition Alternative name to the model title.
Comment The distinction between titles and alternative titles is model-specific.
Cardinality optional, repeatable
Sub-element of
Domain
Examples HCL

Element Name: creator
Label creator
Definition Person or organization responsible for developing the model.
Comment Examples of a Creator include a person, an organization, or a service. Typically, the name of a Creator should be used to indicate the entity.
Cardinality optional, repeatable
Sub-element of
Domain
Examples Bruno St-Aubin

Element Name: contributor
Label contributor
Definition Person or organization contributing to the development of the model.
Comment The guidelines for using names of persons or organizations as creators apply to contributors.
Cardinality optional, repeatable
Sub-element of
Domain
Examples William Anderson
Carleton University
ARSLab

Element Name: type
Label type
Definition Identifies whether the DEVS model is “atomic” or “coupled”.
Comment
Cardinality mandatory
Sub-element of
Domain atomic, coupled
Examples

Element Name: language
Label language
Definition Language of the model (i.e. English, French, etc.)
Comment Recommended practice is to use either a non-literal value representing a language from a controlled vocabulary such as ISO 639-2 or ISO 639-3, or a literal value consisting of an IETF Best Current Practice 47 [IETF-BCP47] language tag.
Cardinality optional, repeatable
Sub-element of
Domain
Examples en-CA
fr-CA

Element Name: description
Label description
Definition A summary description of the model.
Comment
Cardinality optional, repeatable
Sub-element of
Domain
Examples Geographic areas generate emergency periodically. Emergencies are sent to 3 closest hospitals by road network. If the hospitals have capacity, they are accepted otherwise rejected.

Element Name: subject
Label subject
Definition A topic for the model.
Comment Recommended practice is to refer to the subject with a literal value that identifies the subject. It should preferably refer to a subject in a controlled vocabulary.
Cardinality optional, repeatable
Sub-element of
Domain
Examples network
computer systems

Element Name: spatial_coverage
Label spatial coverage
Definition Spatial coverage for which the model can be used.
Comment
Cardinality optional, repeatable
Sub-element of
Domain
Examples

Element Name: placename
Label placename
Definition Name of the location for which the model can be used.
Comment A place name may be a location specified by name (i.e. Ottawa) or by its geographic coordinates.
Cardinality optional, repeatable
Sub-element of spatial_coverage
Domain
Examples Ottawa
USA
New York

Element Name: extent
Label extent
Definition Spatial coverage specified by geographic extent.
Comment
Cardinality optional, repeatable
Sub-element of spatial_coverage
Domain
Examples

Element Name: reference
Label reference
Definition Spatial reference for the spatial coverage (i.e. epsg 4326).
Comment Recommended practice is to use a URI based reference to a spatial reference from spatialreference.org
Cardinality mandatory
Sub-element of extent
Domain
Examples https://spatialreference.org/ref/epsg/4326/json/
https://spatialreference.org/ref/sr-org/7483/json/

Element Name: x_min
Label x min
Definition Minimum x coordinate for the spatial coverage.
Comment Coordinate values must be provided using the spatial reference specified for the extent.
Cardinality mandatory
Sub-element of extent
Domain
Examples -76.037

Element Name: x_max
Label x max
Definition Maximum x coordinate for the spatial coverage.
Comment Coordinate values must be provided using the spatial reference specified for the extent.
Cardinality mandatory
Sub-element of extent
Domain
Examples -75.243

Element Name: y_min
Label y min
Definition Minimum y coordinate for the spatial coverage.
Comment Coordinate values must be provided using the spatial reference specified for the extent.
Cardinality mandatory
Sub-element of extent
Domain
Examples 45.151

Element Name: y_max
Label y max
Definition Maximum y coordinate for the spatial coverage.
Comment Coordinate values must be provided using the spatial reference specified for the extent.
Cardinality mandatory
Sub-element of extent
Domain
Examples 45.489

Element Name: temporal_coverage
Label temporal coverage
Definition Temporal coverage for which the model can be used.
Comment
Cardinality optional, repeatable
Sub-element of
Domain
Examples

Element Name: start
Label start
Definition Start date or time of the temporal coverage.
Comment Start date must be provided using the time schema specified for the temporal coverage.
Cardinality mandatory
Sub-element of temporal_coverage
Domain
Examples 2020-01-01

Element Name: end
Label end
Definition End date or time of the temporal coverage.
Comment End date must be provided using the time schema specified for the temporal coverage.
Cardinality mandatory
Sub-element of temporal_coverage
Domain
Examples 2022-01-01

Element Name: scheme
Label scheme
Definition Date or time schema used to represent the temporal coverage.
Comment Recommended practice is to use a well known time schema such as ISO-8601
Cardinality mandatory
Sub-element of temporal_coverage
Domain
Examples ISO 8601

2.2 Elements of administrative metadata

Element Name: license
Label license
Definition A legal document giving official permission to do something with the model.
Comment Recommended practice is to identify the license document with a URI. If this is not possible or feasible, a literal value that identifies the license may be provided.
Cardinality optional, repeatable
Sub-element of
Domain
Examples MIT License
https://creativecommons.org/licenses/by/4.0/

2.3 Elements of technical metadata

Element Name: created
Label created
Definition Date of creation for the model.
Comment Recommended practice is to specify the date using a well known time schema such as ISO-8601
Cardinality mandatory
Sub-element of
Domain
Examples 2020-05-11

Element Name: modified
Label modified
Definition Date on which the model was changed.
Comment Recommended practice is to specify the date using a well known time schema such as ISO-8601
Cardinality optional, repeatable
Sub-element of
Domain
Examples 2021-02-13

2.4 Elements of DEVS specific metadata

Element Name: time
Label time
Definition Time representation used for the model.
Comment
Cardinality mandatory
Sub-element of
Domain
Examples NDTime

Element Name: behavior
Label behavior
Definition High level description of the model’s behavior.
Comment
Cardinality optional, repeatable
Sub-element of
Domain
Examples Every 24 hours, a random number of emergencies are generated by a geographic area. The number of emergencies is proportional to the population count of the area and uses a random factor for variance. Emergencies are sent to the first closest hospital by driving distance. Hospitals have a capacity and a number of active cases. If a hospital is over capacity, the emergency is rejected and returned to the geographic area. The area then sends it to the second hospital, then third hospital to be processed. If the emergencies are rejected by all 3 hospitals, they are counted as casualties.

Element Name: state
Label state
Definition State of the model. Only applicable to "atomic" models.
Comment
Cardinality optional
Sub-element of
Domain
Examples

Element Name: description
Label description
Definition High level description of the model’s state.
Comment
Cardinality optional
Sub-element of state
Domain
Examples The state of this model contains the population count, number of active cases and number of resolved cases

Element Name: message
Label message
Definition State message type unique identifier.
Comment
Cardinality mandatory
Sub-element of state
Domain
Examples 3

Element Name: subcomponent
Label subcomponent
Definition A subcomponent model instance of the coupled model, only applicable for “coupled” models.
Comment
Cardinality optional, repeatable
Sub-element of
Domain
Examples

Element Name: identifier
Label identifier
Definition Identifier for the subcomponent, unique within a coupled model.
Comment
Cardinality mandatory
Sub-element of subcomponent
Domain
Examples generator_1

Element Name: model
Label model
Definition Unique identifier reference for the model used for the subcomponent.
Comment
Cardinality mandatory
Sub-element of subcomponent
Domain
Examples 773656ca-169c-4858-9a94-1814da118156

Element Name: coupling
Label coupling
Definition A coupling between an origin and destination model, only applicable for “coupled” models.
Comment
Cardinality optional, repeatable
Sub-element of
Domain
Examples

Element Name: from_model
Label from model
Definition Origin subcomponent unique identifier for the coupling.
Comment
Cardinality mandatory
Sub-element of coupling
Domain
Examples 1dbb558d-813d-4b0e-81a2-18f071848fc0

Element Name: from_port
Label from port
Definition Origin subcomponent port for the coupling.
Comment
Cardinality mandatory
Sub-element of coupling
Domain
Examples out_port_1

Element Name: to_model
Label to model
Definition Destination subcomponent unique identifier for the coupling.
Comment
Cardinality mandatory
Sub-element of coupling
Domain
Examples da168216-d2a3-4a6a-ba1d-4685b8e0b893

Element Name: to_port
Label to port
Definition Destination subcomponent port for the coupling.
Comment
Cardinality mandatory
Sub-element of coupling
Domain
Examples in_port_1

Element Name: port
Label port
Definition An input or output port of the model.
Comment
Cardinality optional, repeatable
Sub-element of
Domain
Examples

Element Name: type
Label type
Definition Indicates whether the port is an “input” port or an “output” port.
Comment
Cardinality mandatory
Sub-element of port
Domain input, output
Examples

Element Name: name
Label name
Definition Non unique name of the port.
Comment
Cardinality mandatory
Sub-element of port
Domain
Examples out_port_1

Element Name: message
Label message
Definition Message type unique identifier.
Comment
Cardinality mandatory
Sub-element of port
Domain
Examples 2

Element Name: message
Label message
Definition Message type used by the model.
Comment
Cardinality optional, repeatable
Sub-element of
Domain
Examples

Element Name: identifier
Label identifier
Definition Unique identifier for the message type.
Comment
Cardinality mandatory
Sub-element of message
Domain
Examples 2

Element Name: field
Label field
Definition A field of the message type.
Comment
Cardinality mandatory, repeatable
Sub-element of message
Domain
Examples

Element Name: name
Label name
Definition Name of the field, unique within the message type.
Comment
Cardinality mandatory
Sub-element of field
Domain
Examples recovered

Element Name: description
Label description
Definition Description of the field.
Comment
Cardinality optional, repeatable
Sub-element of field
Domain
Examples the number of recovered cases for this model

Element Name: type
Label type
Definition Indicates whether the field value is “nominal”, “numerical” or “ordinal”.
Comment
Cardinality mandatory
Sub-element of field
Domain nominal, numerical, ordinal
Examples

Element Name: uom
Label uom
Definition Unit of measure used for the field, only for “numerical” values.
Comment
Cardinality optional
Sub-element of field
Domain
Examples person

Element Name: scalar
Label scalar
Definition Scalar factor applied to the value, only for “numerical” values.
Comment A scalar factor must be a factor of 10.
Cardinality optional
Sub-element of field
Domain
Examples 1000

Element Name: decimals
Label decimals
Definition Number of decimal digits, only for “numerical” values.
Comment
Cardinality optional
Sub-element of field
Domain
Examples 3

3. Examples

3.1 JSON example

{
   "identifier": "b867ca77-ee01-46bc-9ee2-71a0110f13f2",
   "title": "Hospital Case Load",
   "alternative": "HCL",
   "creator": "Bruno St-Aubin",
   "contributor": ["Carleton University", "ARSLab"],
   "type": "coupled",
   "language": ["en-ca", "fr-ca"],
   "description": "Geographic areas generate emergency periodically. Emergencies are sent to 3 closest hospitals by 
                   road network. If the hospitals have capacity, they are accepted otherwise rejected.",
   "subject": ["network", "web", "computer systems"],
   "spatial coverage": [{
      "placename": "Ottawa",
      "extent": {
         "reference": "epsg:4326",
         "x min": -76.037,
         "x max": -75.243
         "y min": 45.151,
         "y max": 45.489,
      }
   },{
      "placename": "Gatineau",
      "extent": {
         "reference": "epsg:4326",
         "x min": -76.070,
         "x max": -75.306
         "y min": 45.402,
         "y max": 45.685,
      }
   }],
   "temporal coverage": {
      "start": "2020-01-01",
      "end": "2022-01-01",
      "scheme": "ISO 8601",
   },
   "license": "MIT License",
   "created": "2020-05-11",
   "modified": ["2021-02-13", "2021-03-28", "2021-07-06"],
   "time": "NDTime",
   "behavior": "Every 24 hours, a random number of emergencies are generated by a geographic area. The number of emergencies 
                is proportional to the population count of the area and uses a random factor for variance. Emergencies are sent 
                to the first closest hospital by driving distance. Hospitals have a capacity and a number of active cases. If
                a hospital is over capacity, the emergency is rejected and returned to the geographic area. The area then sends 
                it to the second hospital, then third hospital to be processed. If the emergencies are rejected by all 3
                hospitals, they are counted as casualties.",
   "state": null,
   "subcomponent": [{
      "identifier": "generator_1",
      "model": "75b388da-5ac6-11ec-bf63-0242ac130002"
   },{
      "identifier": "receiver_1",
      "model": "7ae167dc-5ac6-11ec-bf63-0242ac130002"
   },{
      "identifier": "subnet_1",
      "model": "800ea31e-5ac6-11ec-bf63-0242ac130002"
   },{
      "identifier": "network_1",
      "model": "856306b6-5ac6-11ec-bf63-0242ac130002"
   },{
      "identifier": "network_2",
      "model": "856306b6-5ac6-11ec-bf63-0242ac130002"
   }],
   "port": [{
      "type": "output",
      "name": "rejected",
      "message": 1
   },
   "message":[{
      "identifier": 1,
      "field": [{
         "name": "area",
         "description": "geographic area id that rejected the emergencies.",
         "type": "nominal"
      },{
         "name": "count",
         "description": "number of emergencies rejected by the geographic area.",
         "type": "numerical",
         "uom": "persons",
         "scalar": "unit",
         "decimals": 0
      }]
   }]
}
		

3.2 XML example

<metadata>
   <identifier>b867ca77-ee01-46bc-9ee2-71a0110f13f2</identifier>
   <title>Hospital Case Load</title>
   <creator>Bruno St-Aubin</creator>
   <contributor>Carleton University</contributor>
   <contributor>ARSLab</contributor>
   <type>coupled</type>
   <language>en-ca</language>
   <language>fr-ca</language>
   <description>Geographic areas generate emergency periodically. Emergencies are sent to 3 closest hospitals by road network. 
		If the hospitals have capacity, they are accepted otherwise rejected.</description>
   <subject>network</subject>
   <subject>web</subject>
   <subject>computer systems</subject>
   <spatial_coverage>
      <placename>Ottawa</placename>
      <extent>
         <reference>epsg:4326</reference>
         <x_min>-76.037</x_min>
         <x_max>-75.243</x_max>
         <y_min>45.151</y_min>
         <y_max>45.489</y_max>
      </extent>
   </spatial_coverage>
   <spatial_coverage>
      <placename>Gatineau</placename>
      <extent>
         <reference>epsg:4326</reference>
         <x_min>-76.070</x_min>
         <x_max>-75.306</x_max>
         <y_min>45.402</y_min>
         <y_max>45.685</y_max>
      </extent>
   </spatial_coverage>
   <temporal_coverage>
      <start>2020-01-01</start>
      <end>2022-01-01</end>
      <scheme>ISO 8601</scheme>
   </temporal_coverage>
   <license>MIT License</license>
   <created>2020-05-11</created>
   <modified>2021-02-13</modified>
   <modified>2021-03-28</modified>
   <modified>2021-07-06</modified>
   <time>NDTime</time>
   <behavior>
	Every 24 hours, a random number of emergencies are generated by a geographic area. The number of emergencies 
	is proportional to the population count of the area and uses a random factor for variance. Emergencies are sent to the 
	first closest hospital by driving distance. Hospitals have a capacity and a number of active cases. If a hospital is 
	over capacity, the emergency is rejected and returned to the geographic area. The area then sends it to the second 
	hospital, then third hospital to be procesed. If the emergencies are rejected by all 3 hospitals, they are counted as 
	casualties.
   </behavior>
   <state></state>
   <subcomponent>
      <identifier>generator</identifier>
      <model>773656ca-169c-4858-9a94-1814da118156</model>
   </subcomponent>
   <subcomponent>
      <identifier>receiver</identifier>
      <model>1dbb558d-813d-4b0e-81a2-18f071848fc0</model>
   </subcomponent>
   <subcomponent>
      <identifier>subnet</identifier>
      <model>3c185942-6e91-40c6-9cad-aa02d7d94a50</model>
   </subcomponent>
   <subcomponent>
      <identifier>network</identifier>
      <model>da168216-d2a3-4a6a-ba1d-4685b8e0b893</model>
   </subcomponent>
   <port>
      <type>output</type>
      <name>rejected</name>
      <message>1</message>
   </port>
   <message>
      <identifier>1</identifier>
      <field>
         <name>area</name>
         <description>geographic area id that rejected the emergencies.</description>
         <type>nominal</type>
      </field>
      <field>
         <name>count</name>
         <description>number of emergencies rejected by the geographic area.</description>
         <type>numerical</type>
         <uom>persons</uom>
         <scalar>unit</scalar>
         <decimals>0</decimals>
      </field>
   </message>
</metadata>