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>