Business process model and notation (.bpmn)

A business process model and notation file can serve as input to the following commands:

A business process model and notation file can be the output of the following commands:

File format specification: A Business Process Model and Notation (BPMN) model follows the OMG 2.0.2 standard. Currently, a sub-set of elements is supported.

Comma separated values (.csv)

A comma-separated values file can serve as input to the following commands:

A comma-separated values file can be the output of the following commands:

On importing .csv files, the following optional importer parameters may be given, where X is the rank of the input in the command:

--inputX_csv_activity	The name or number of the column that contains the activity. The default value is `1'.
--inputX_csv_no_header	Without this flag set, the first line is read as the header. With this flag set, the first line is read as an event. In the latter case, the columns are given numbers, starting from 0.
--inputX_csv_quote_character	The character(s) that begin and end a quote. The default value is `"'.
--inputX_csv_resource	The name or number of the column that contains the resource. The default value is `2'.
--inputX_csv_separator	The character(s) that separate the columns. The default value is `,'.
--inputX_csv_time	The name or number of the column that contains the timestamp. The default value is `3'.
--inputX_csv_trace_id	The name or number of the column that contains the trace id. The default value is `0'.

File format specification: A text file, of which each row is a comma-separated list of attribute values. The first row contains the names of the attributes (unless the no-header flag is provided). You'll likely need to set some import parameters to make importing succeed. A restriction imposed by Ebi is that there must be at least two attributes and at least two events. For instance:

case_id,activity
1,a
2,a
1,b
3,a
2,b
3,b

Compressed event log (.xes.gz)

A compressed event log file can serve as input to the following commands:

A compressed event log file can be the output of the following commands:

On importing .xes.gz files, the following optional importer parameters may be given, where X is the rank of the input in the command:

--inputX_xes_event_classifier

The attribute that defines, for each event, what its activity is.
The default value is `concept:name'.

File format specification: A compressed event log is a gzipped event log file in the IEEE XES format. Parsing is performed by the Rust4PM crate.

Deterministic finite automaton (.dfa)

A deterministic finite automaton file can serve as input to the following commands:

A deterministic finite automaton file can be the output of the following commands:

File format specification: A deterministic finite automaton is a JSON structure with the top level being an object. This object contains the following key-value pairs:

initialState being the index of the initial state. This field is optional: if omitted, the DFA has an empty language.
finalStates being a list of indices of the final states. A final state is not necessarily a deadlock state.
transitions being a list of transitions. Each transition is an object with from being the source state index of the transition, to being the target state index of the transition, and {label} being the activity of the transition. Silent transitions are not supported. The file format supports deadlocks and livelocks.

For instance:

{
	"initialState": 0,
	"transitions": [
		{"from": 0, "to": 1, "label": "a"},
		{"from": 0, "to": 4, "label": "b"},
		{"from": 1, "to": 2, "label": "a"},
		{"from": 1, "to": 3, "label": "b"},
		{"from": 4, "to": 5, "label": "a"}
	],
	"finalStates": [2,3,5]
}

The following table gives an overview of several directly follows-based file types and their features:

File type	stochastic	multiple nodes with the same label	silent transitions	file syntax
directly follows model (.dfm)	no	yes	no	line-based
directly follows graph (.dfg)	weights	no	no	JSON
stochastic directly follows model (.sdfm)	yes	yes	no	line-based
stochastic deterministic finite automaton (.sdfa)	yes	yes	no	line-based
stochastic non-deterministic finite automaton (.snfa)	yes	yes	yes	line-based

Directly follows graph (.dfg)

A directly follows graph file can serve as input to the following commands:

A directly follows graph file can be the output of the following commands:

Ebi discover directly-follows-graph

File format specification: A directly follows graph is a JSON structure. For instance:

{
	"activities": {"a":"6/5","b":"4/5"},
	"directly_follows_relations": [
		[["a", "a"], "1/5"],
		[["a", "b"], "1/5"],
		[["b", "a"], "3/5"]
	],
	"end_activities": ["a", "b"],
	"start_activities": ["a", "b"]
}

The following table gives an overview of several directly follows-based file types and their features:

File type	stochastic	multiple nodes with the same label	silent transitions	file syntax
directly follows model (.dfm)	no	yes	no	line-based
directly follows graph (.dfg)	weights	no	no	JSON
stochastic directly follows model (.sdfm)	yes	yes	no	line-based
stochastic deterministic finite automaton (.sdfa)	yes	yes	no	line-based
stochastic non-deterministic finite automaton (.snfa)	yes	yes	yes	line-based

Directly follows model (.dfm)

A directly follows model file can serve as input to the following commands:

A directly follows model file can be the output of the following commands:

File format specification: A directly follows model is a line-based structure. Lines starting with a # are ignored. This first line is exactly `directly follows model'.
The second line is a boolean indicating whether the model supports empty traces.
The third line is the number of activities in the model.
For a single-line activity, escape a starting `$' by doubling it to `$'. For a multiline activity, start with a line `$multiline', and end with a line `multiline$' To end any line end with `$', double it to `$$'.
The next line contains the number of start activities, followed by, for each start activity, a line with the index of the start activity.
The next line contains the number of end activities, followed by, for each end activity, a line with the index of the end activity.
The next line contains the number of edges, followed by, for each edge, a line with first the index of the source activity, then the `>` symbol, then the index of the target activity. For instance:

directly follows model
# empty traces
false
# number of activities
2
# activities
a
b
# number of start activities
1
# start activities 
0
# number of end activities
1
# end activities
1
# number of edges
2
# edges
0>1
1>1

The following table gives an overview of several directly follows-based file types and their features:

File type	stochastic	multiple nodes with the same label	silent transitions	file syntax
directly follows model (.dfm)	no	yes	no	line-based
directly follows graph (.dfg)	weights	no	no	JSON
stochastic directly follows model (.sdfm)	yes	yes	no	line-based
stochastic deterministic finite automaton (.sdfa)	yes	yes	no	line-based
stochastic non-deterministic finite automaton (.snfa)	yes	yes	yes	line-based

Executions (.exs)

An executions file can serve as input to the following commands:

An executions file can be the output of the following commands:

Ebi analyse-non-stochastic executions

File format specification: An executions file is a JSON structure, of which the root is an object with one element called `executions`. This is a list of executions, where each execution contains:

The trace.
The index of the move within the trace.
An activity label (may be null).
Whether the transition was also in the log (true = synchronous move, false = model move or silent move).
The index of the transition that fired.
A list of other enabled transitions.
The name of the resource of the execution (may be null).
The index of the move that enabled the execution (may be null).
The time of execution (may be null). In case of a model move, contains the time of the next synchronous or log move.
The resource utilisation of the transition that fired.
A list of the resource utilisation for each other enabled transition.

The executions should be sorted in order of increasing execution time; the position of missing execution timestamps is arbitrary. For instance:

{
  "executions": [
    {
      "activity": "a",
      "also_in_log": true,
      "event_attributes": {
        "concept:name": "a",
        "org:resource": "John",
        "other_attribute": "z",
        "time:timestamp": "2017-05-09 00:00:00 +01:00"
      },
      "fired_transition": 0,
      "move_index": 0,
      "move_index_of_enablement": null,
      "other_enabled_transitions": [
        1,
        2
      ],
      "other_enabled_transitions_resource_utilisation": [
        "0",
        "0"
      ],
      "resource": "John",
      "resource_utilisation_fired_transition": "0",
      "time_of_execution": "2017-05-09 00:00:00 +01:00",
      "trace": 0
    },
    {
      "activity": null,
      "also_in_log": false,
      "event_attributes": null,
      "fired_transition": 4,
      "move_index": 1,
      "move_index_of_enablement": 0,
      "other_enabled_transitions": [],
      "other_enabled_transitions_resource_utilisation": [],
      "resource": null,
      "resource_utilisation_fired_transition": null,
      "time_of_execution": null,
      "trace": 0
    },
    {
      "activity": "b",
      "also_in_log": true,
      "event_attributes": {
        "concept:name": "b",
        "org:resource": "Doe",
        "other_attribute": "y",
        "time:timestamp": "2017-05-09 00:00:00 +01:00"
      },
      "fired_transition": 1,
      "move_index": 0,
      "move_index_of_enablement": null,
      "other_enabled_transitions": [
        0,
        2
      ],
      "other_enabled_transitions_resource_utilisation": [
        "0",
        "0"
      ],
      "resource": "Doe",
      "resource_utilisation_fired_transition": "0",
      "time_of_execution": "2017-05-09 00:00:00 +01:00",
      "trace": 1
    },
    {
      "activity": null,
      "also_in_log": false,
      "event_attributes": null,
      "fired_transition": 4,
      "move_index": 1,
      "move_index_of_enablement": 0,
      "other_enabled_transitions": [],
      "other_enabled_transitions_resource_utilisation": [],
      "resource": null,
      "resource_utilisation_fired_transition": null,
      "time_of_execution": null,
      "trace": 1
    }
  ]
}

Extensible event stream (.xes)

An extensible event stream file can serve as input to the following commands:

An extensible event stream file can be the output of the following commands:

On importing .xes files, the following optional importer parameters may be given, where X is the rank of the input in the command:

--inputX_xes_event_classifier	The attribute that defines, for each event, what its activity is. The default value is `concept:name'.
--inputX_xes_resource	The attribute that defines, for each event, what its resource is. The default value is `org:resource'.
--inputX_xes_time	The attribute that defines, for each event, what its timestamp is. The default value is `time:timestamp'.

File format specification: An event log file follows the IEEE XES format. Parsing is performed by the Rust4PM crate. For instance:

<?xml version="1.0" encoding="UTF-8" ?>
<log xes.version="1.0">
  <extension name="Concept" prefix="concept" uri="http://code.deckfour.org/xes/concept.xesext"/>
  <extension name="Time" prefix="time" uri="http://code.deckfour.org/xes/time.xesext"/>
  <extension name="Organizational" prefix="org" uri="http://code.deckfour.org/xes/org.xesext"/>
  <global scope="trace">
    <string key="concept:name" value="name"/>
  </global>
  <global scope="event">
    <string key="concept:name" value="name"/>
  </global>
  <classifier name="Activity" keys="Activity"/>
  <trace>
    <string key="concept:name" value="first trace"/>
    <int key="attribute" value="1"/>
    <event>
      <string key="concept:name" value="a"/>
      <string key="other_attribute" value="z"/>
      <date key="time:timestamp" value="2017-05-09T00:00:00.000+01:00"/>
      <string key="org:resource" value="John"/>
    </event>
  </trace>
  <trace>
    <string key="concept:name" value="second trace"/>
    <int key="attribute" value="2"/>
    <event>
      <string key="concept:name" value="b"/>
      <string key="other_attribute" value="y"/>
      <date key="time:timestamp" value="2017-05-09T00:00:00.000+01:00"/>
      <string key="org:resource" value="Doe"/>
    </event>
  </trace>
</log>

Finite language (.lang)

A finite language file can serve as input to the following commands:

A finite language file can be the output of the following commands:

File format specification: A finite language is a line-based structure. Lines starting with a # are ignored. This first line is exactly `finite language'. The second line is the number of traces in the language. For each trace, the first line contains the number of events in the trace. Then, each subsequent line contains the activity name of one event. For a single-line event, escape a starting `$' by doubling it to `$'. For a multiline event, start with a line `$multiline', and end with a line `multiline$' To end any line end with `$', double it to `$$'. For instance:

finite language
# number of traces
3
# trace 0
# number of events
2
a
a
# trace 1
# number of events
2
a
b
# trace 2
# number of events
2
b
a

Finite stochastic language (.slang)

A finite stochastic language file can serve as input to the following commands:

A finite stochastic language file can be the output of the following commands:

File format specification: A finite stochastic language is a line-based structure. Lines starting with a # are ignored. This first line is exactly `finite stochastic language'. The second line is the number of traces in the language. For each trace, the first line is the probability of the trace as a positive fraction or a decimal value. The second line contains the number of events in the trace. Then, each subsequent line contains the activity name of one event. For a single-line event, escape a starting `$' by doubling it to `$'. For a multiline event, start with a line `$multiline', and end with a line `multiline$' To end any line end with `$', double it to `$$'. The sum of the probabilities of the traces in the language needs to be < 1. For instance:

finite stochastic language
# number of traces
3
# trace 0
# probability
1/5
# number of events
2
a
a
# trace 1
# probability
0.2
# number of events
2
a
b
# trace 2
# probability
3/5
# number of events
2
b
a

Finite stochastic partially ordered language (.spolang)

A finite stochastic partially ordered language file can serve as input to the following commands:

A finite stochastic partially ordered language file can be the output of the following commands:

Ebi sample partially-ordered-traces

File format specification: A finite stochastic partially ordered language is a line-based structure. Lines starting with a # are ignored. This first line is exactly `finite stochastic partially ordered language'. The second line is the number of traces in the language. Then, for each trace, the following items are next, each on their own line.\ First, the probability of the trace.\ Second, the number of events in the trace.\ Third, for each event: \begin{enumerate} \item The activity. For a single-line event, escape a starting `$' by doubling it to `$'. For a multiline event, start with a line `$multiline', and end with a line `multiline$' To end any line end with `$', double it to `$$'. \item The number of input edges, \item For each input edge, on its own line, the index of the source event of the edge. \end{enumerate} For instance:

finite stochastic partially ordered language
# number of traces
10
# trace 0
#	probability
1/10
#	number of events
3
#	event 0
$multiline
Register claim
(2min)
multiline$
#		number of predecessors
0
#		predecessors
#	event 1
$multiline
Check easy claim
(5 min)
multiline$
#		number of predecessors
1
#		predecessors
0
#	event 2
$multiline
Check difficult claim
(10 min)
multiline$
#		number of predecessors
1
#		predecessors
1
# trace 1
#	probability
1/10
#	number of events
3
#	event 0
$multiline
Register claim
(2min)
multiline$
#		number of predecessors
0
#		predecessors
#	event 1
$multiline
Check easy claim
(5 min)
multiline$
#		number of predecessors
1
#		predecessors
0
#	event 2
$multiline
Check difficult claim
(10 min)
multiline$
#		number of predecessors
1
#		predecessors
1
# trace 2
#	probability
1/10
#	number of events
3
#	event 0
$multiline
Register claim
(2min)
multiline$
#		number of predecessors
0
#		predecessors
#	event 1
$multiline
Check easy claim
(5 min)
multiline$
#		number of predecessors
1
#		predecessors
0
#	event 2
$multiline
Check difficult claim
(10 min)
multiline$
#		number of predecessors
1
#		predecessors
1
# trace 3
#	probability
1/10
#	number of events
3
#	event 0
$multiline
Register claim
(2min)
multiline$
#		number of predecessors
0
#		predecessors
#	event 1
$multiline
Check easy claim
(5 min)
multiline$
#		number of predecessors
1
#		predecessors
0
#	event 2
$multiline
Check difficult claim
(10 min)
multiline$
#		number of predecessors
1
#		predecessors
1
# trace 4
#	probability
1/10
#	number of events
2
#	event 0
$multiline
Register claim
(2min)
multiline$
#		number of predecessors
0
#		predecessors
#	event 1
$multiline
Check easy claim
(5 min)
multiline$
#		number of predecessors
1
#		predecessors
0
# trace 5
#	probability
1/10
#	number of events
2
#	event 0
$multiline
Register claim
(2min)
multiline$
#		number of predecessors
0
#		predecessors
#	event 1
$multiline
Check difficult claim
(10 min)
multiline$
#		number of predecessors
1
#		predecessors
0
# trace 6
#	probability
1/10
#	number of events
2
#	event 0
$multiline
Register claim
(2min)
multiline$
#		number of predecessors
0
#		predecessors
#	event 1
$multiline
Check easy claim
(5 min)
multiline$
#		number of predecessors
1
#		predecessors
0
# trace 7
#	probability
1/10
#	number of events
2
#	event 0
$multiline
Register claim
(2min)
multiline$
#		number of predecessors
0
#		predecessors
#	event 1
$multiline
Check easy claim
(5 min)
multiline$
#		number of predecessors
1
#		predecessors
0
# trace 8
#	probability
1/10
#	number of events
3
#	event 0
$multiline
Register claim
(2min)
multiline$
#		number of predecessors
0
#		predecessors
#	event 1
$multiline
Check easy claim
(5 min)
multiline$
#		number of predecessors
1
#		predecessors
0
#	event 2
$multiline
Check difficult claim
(10 min)
multiline$
#		number of predecessors
1
#		predecessors
1
# trace 9
#	probability
1/10
#	number of events
2
#	event 0
$multiline
Register claim
(2min)
multiline$
#		number of predecessors
0
#		predecessors
#	event 1
$multiline
Check difficult claim
(10 min)
multiline$
#		number of predecessors
1
#		predecessors
0

Labelled petri net (.lpn)

A labelled Petri net file can serve as input to the following commands:

A labelled Petri net file can be the output of the following commands:

File format specification: A labelled Petri net is a line-based structure. Lines starting with a # are ignored. This first line is exactly `labelled Petri net'. If the second is line is exactly `empty language', then the model is considered to have an empty language and parsing stops. Otherwise, the second line is the number of places in the net. The lines thereafter contain the initial marking: each place has its own line with the number of tokens on that place in the initial marking. The next line is the number of transitions in the net. Then, for each transition, the following lines are next: (i) the word `silent' or the word `label ' directly followed by the activity label, or a line with `multiline label' followed by the label, terminated with a line `multiline$' (a `$' at each line end can be escaped with `$$'); (ii) the number of input places, followed by a line for each input place with the index of the place; (iii) the number of output places, followed by a line for each output place with the index of the place. For instance:

labelled Petri net
# number of places
3
# initial marking
1
0
0
# number of transitions
5
# transition 0
label a
# number of input places
1
0
# number of output places
1
1
# transition 1
label b
# number of input places
1
0
# number of output places
1
2
# transition 2
label a
# number of input places
1
1
# number of output places
0
# transition 3
label b
# number of input places
1
1
# number of output places
0
# transition 4
label a
# number of input places
1
2
# number of output places
0

Language of alignments (.ali)

A language of alignments file can serve as input to the following commands:

A language of alignments file can be the output of the following commands:

File format specification: A language of alignments is a line-based structure. Lines starting with a # are ignored. This first line is exactly `language of alignments'. The second line is the number of alignments in the language. For each alignment, the first line contains the number of moves in the alignment. Then, each move is given as either

`synchronous move', followed by a line with the word `label' followed by a space and the activity label, which is followed with a line with the index of the involved transition.
`silent move', followed by a line with the index of the silent transition.
`log move', followed by a line with the word `label', then a space, and then the activity label.
`model move', followed by a line with the word `label' followed by a space and the activity label, which is followed with a line with the index of the involved ransition.

Note that the Semantics trait of Ebi, which is what most alignment computations use, requires that every final marking is a deadlock. Consequently, an implicit silent transition may be added by the Semantics trait that is not in the model. For instance:

language of alignments
# number of alignments
3
# alignment 0
# number of moves
4
# move 0
synchronous move
label a
0
# move 1
model move
label b
1
# move 2
silent move
2
# move 3
log move
label a
# alignment 1
# number of moves
3
# move 0
synchronous move
label a
0
# move 1
synchronous move
label b
1
# move 2
silent move
2
# alignment 2
# number of moves
4
# move 0
model move
label a
0
# move 1
synchronous move
label b
1
# move 2
silent move
2
# move 3
log move
label a

Lo la petri net (.lola)

A LoLa Petri net file can serve as input to the following commands:

A LoLa Petri net file can be the output of the following commands:

File format specification: A LoLA Petri net language file adheres to the grammar described in. Note that Ebi does not support place bounds or fairness, and that LoLA nets do not support silent transitions, and has some restrictions on labeling. For instance:

PLACE
    idle.0, request.0, critical.0,
    idle.1, request.1, critical.1,
    sem;

MARKING
    idle.0: 1, idle.1: 2,
    sem;

TRANSITION g0.0
    CONSUME idle.0: 1;
    PRODUCE idle.0: 1;

TRANSITION g1.0
    CONSUME idle.0: 1;
    PRODUCE request.0: 1;

TRANSITION g2.0
    CONSUME request.0: 1, sem: 1;
    PRODUCE critical.0: 1;

TRANSITION g3.0
    CONSUME critical.0: 1;
    PRODUCE idle.0: 1, sem: 1;

TRANSITION g0.1
    CONSUME idle.1: 1;
    PRODUCE idle.1: 1;

TRANSITION g1.1
    CONSUME idle.1: 1;
    PRODUCE request.1: 1;

TRANSITION g2.1
    CONSUME request.1: 1, sem: 1;
    PRODUCE critical.1: 1;

TRANSITION g3.1
    CONSUME critical.1: 1;
    PRODUCE idle.1: 1, sem: 1;

Object centric event log (.ocel)

An object-centric event log file can serve as input to the following commands:

An object-centric event log file cannot be the output of any command.

On importing .ocel files, the following optional importer parameters may be given, where X is the rank of the input in the command:

--inputX_ocel_case_object_type	The object type that defines what a trace is. May be given as the name of the object type (which takes preference) or as the index of the object-type in the order of declaration. The default value is `0'.
--inputX_ocel_resource_object_type	The object type that defines what a resource is. May be given as the name of the object type (which takes preference) or as the index of the object-type in the order of declaration. The default value is `1'.
--inputX_ocel_time_attribute	The attribute that denotes the timestamp of an event. The default value is `time'.

File format specification: An object-centric event log file follows the Ocel 2.0 format. Parsing is performed by the Rust4PM crate. Note that if a case-centric process is abstracted using a single object type, then events are assumed to be ordered. That is, timestamps are not taken into account. For instance:

<?xml version="1.0" encoding="UTF-8"?>
<log>
  <object-types>
    <object-type name="Invoice">
      <attributes/>
    </object-type>
    <object-type name="Payment">
      <attributes/>
    </object-type>
  </object-types>
  <event-types>
    <event-type name="Create Purchase Requisition">
      <attributes/>
    </event-type>
    <event-type name="Approve Purchase Requisition">
      <attributes/>
    </event-type>
  </event-types>
  <objects>
    <object id="I1" type="Invoice">
      <attributes/>
      <objects/>
    </object>
    <object id="P1" type="Payment">
      <attributes/>
      <objects/>
    </object>
  </objects>
  <events>
    <event id="e1" type="Create Purchase Requisition" time="2022-01-09T15:00:00Z">
      <attributes/>
      <objects>
        <relationship object-id="I1" qualifier="Regular placement of PR"/>
        <relationship object-id="P1" qualifier="Regular placement of PR"/>
      </objects>
    </event>
    <event id="e2" type="Approve Purchase Requisition" time="2022-01-09T16:30:00Z">
      <attributes/>
      <objects>
        <relationship object-id="I1" qualifier="Regular approval of PR"/>
      </objects>
    </event>
  </events>
</log>

Partially ordered workflow language (.powl)

A partially ordered workflow language file can serve as input to the following commands:

A partially ordered workflow language file can be the output of the following commands:

File format specification: A partially ordered workflow language is a JSON structure. For instance:

{
  "format": "powl-json",
  "format_version": "1.0",
  "model": {
  	"type": "choice_graph",
  	"nodes": [
	  {
		    "id": "a",
		    "type": "activity",
		    "repeatable": false,
		    "skippable": false,
		    "label": "a"
	  },
	  {
		    "id": "b",
		    "type": "activity",
		    "repeatable": false,
		    "skippable": false,
		    "label": "b"
	  }
  	],
  	"edges": [
  		{ "source": "@start", "target": "a" },
  		{ "source": "@start", "target": "b" },
  		{ "source": "a", "target": "@end" },
  		{ "source": "b", "target": "@end" }
  	]
  }
}

Petri net markup language (.pnml)

A Petri net markup language file can serve as input to the following commands:

A Petri net markup language file can be the output of the following commands:

File format specification: A Petri net markup language file follows the ISO 15909-2:2011 format. Please note that Ebi ignores any final markings. Instead, every deadlock is considered a final marking. For instance:

<pnml>
 <net id="Rust PetriNet Export" type="http://www.pnml.org/version-2009/grammar/pnmlcoremodel">
  <page id="n0">
   <place id="00d13d78-0e36-432e-9130-2a44b853a740">
    <initialMarking>
     <text>1</text>
    </initialMarking>
   </place>
   <transition id="40aab7a5-f227-405d-8389-fdb38c7c8ee6">
    <name>
     <text>a</text>
    </name>
   </transition>

   <arc 
     id="00d13d78-0e36-432e-9130-2a44b853a74040aab7a5-f227-405d-8389-fdb38c7c8ee6"
     source="00d13d78-0e36-432e-9130-2a44b853a740" 
     target="40aab7a5-f227-405d-8389-fdb38c7c8ee6">
    <inscription>
     <text>1</text>
    </inscription>
   </arc>
  </page>
 </net>
</pnml>

Portable document format (.pdf)

A portable document format file cannot serve as input to any command.

A portable document format file can be the output of the following commands:

File format specification: Ebi does not support importing PDF files.

Portable network graphics (.png)

A portable network graphics file cannot serve as input to any command.

A portable network graphics file can be the output of the following commands:

File format specification: Ebi does not support importing PNG files.

Process tree (.ptree)

A process tree file can serve as input to the following commands:

A process tree file can be the output of the following commands:

File format specification: A process tree is a line-based structure. Lines starting with a # are ignored. This first line is exactly `process tree'. The subsequent lines contain the nodes: Each node is either:

A line with the word `activity' followed on the same line by a space and the label of the activity leaf;
The word `tau';
The name of an operator (`sequence', `xor', `concurrent', `loop', `interleaved', or `or') on its own line. The line thereafter contains the number of children of the node, after which the nodes are given. An operator node must have at least one child.

Indentation of nodes is allowed, but not mandatory. For instance:

process tree
xor
2
	sequence
	2
		activity a0
		activity b1
	concurrent
	4
		activity c2
		loop
		2
			activity d3
			activity e4
		interleaved
		2
			activity f5
			sequence
			2
				tau
				activity g7
		or
		2
			activity h8
			activity i9

Process tree markup language (.ptml)

A process tree markup language file can serve as input to the following commands:

A process tree markup language file can be the output of the following commands:

File format specification: A process tree markup language file. For instance:

<?xml version="1.0" encoding="ISO-8859-1"?>
<ptml>
  <processTree root="n1">
    <xor id="n1"/>
      <sequence id="n2"/>
        <manualTask id="n3" name="b"/>
        <manualTask id="n4" name="a"/>
      <sequence id="n5"/>
        <manualTask id="n6" name="a"/>
        <xor id="n7"/>
          <manualTask id="n8" name="a"/>
          <manualTask id="n9" name="b"/>
      
    <parentsNode sourceId="n1" targetId="n2"/>
    <parentsNode sourceId="n2" targetId="n3"/>
    <parentsNode sourceId="n2" targetId="n4"/>
    <parentsNode sourceId="n1" targetId="n5"/>
    <parentsNode sourceId="n5" targetId="n6"/>
    <parentsNode sourceId="n5" targetId="n7"/>
    <parentsNode sourceId="n7" targetId="n8"/>
    <parentsNode sourceId="n7" targetId="n9"/>

  </processTree>
  <ptml>
    <and />
  </ptml>
</ptml>

Python event log (.pel)

A Python event log file can serve as input to the following commands:

A Python event log file can be the output of the following commands:

File format specification: A Pm4py log can be imported by Ebi from Python. Ensure to set return_legacy_log_object=True at importing.

Scalable vector graphics (.svg)

A scalable vector graphics file cannot serve as input to any command.

A scalable vector graphics file can be the output of the following commands:

File format specification: Ebi does not support importing of SVG files.

Stochastic business process model and notation (.sbpmn)

A stochastic business process model and notation file can serve as input to the following commands:

A stochastic business process model and notation file can be the output of the following commands:

File format specification: A stochastic Business Process Model and Notation (BPMN) model follows the OMG 2.0.2 standard. In addition, certain sequence flows must have tags in the namespace https://www.ebitools.org/sbpmn/20260305. Currently, a sub-set of elements is supported.

Stochastic deterministic finite automaton (.sdfa)

A stochastic deterministic finite automaton file can serve as input to the following commands:

A stochastic deterministic finite automaton file can be the output of the following commands:

File format specification: A stochastic deterministic finite automaton is a JSON structure with the top level being an object. This object contains the following key-value pairs:

initialState being the index of the initial state. This field is optional: if omitted, the SDFA has an empty stochastic language.
transitions being a list of transitions. Each transition is an object with from being the source state index of the transition, to being the target state index of the transition, label being the activity of the transition, and prob being the probability of the transition (may be given as a fraction in a string or a float value. Must be $\leq 1$). Silent transitions are not supported. The file format supports deadlocks and livelocks. The probability that a trace terminates in a state is 1 - the sum probability of the outgoing transitions of the state.

For instance:

{
	"initialState": 0,
	"transitions": [
		{"from": 0, "to": 1, "label": "a", "prob": "2/5"},
		{"from": 0, "to": 4, "label": "b", "prob": "3/5"},
		{"from": 1, "to": 2, "label": "a", "prob": 0.5},
		{"from": 1, "to": 3, "label": "b", "prob": "1/2"},
		{"from": 4, "to": 5, "label": "a", "prob": "1"}
	]
}

The following table gives an overview of several directly follows-based file types and their features:

File type	stochastic	multiple nodes with the same label	silent transitions	file syntax
directly follows model (.dfm)	no	yes	no	line-based
directly follows graph (.dfg)	weights	no	no	JSON
stochastic directly follows model (.sdfm)	yes	yes	no	line-based
stochastic deterministic finite automaton (.sdfa)	yes	yes	no	line-based
stochastic non-deterministic finite automaton (.snfa)	yes	yes	yes	line-based

Stochastic directly follows model (.sdfm)

A stochastic directly follows model file can serve as input to the following commands:

A stochastic directly follows model file can be the output of the following commands:

File format specification: A stochastic directly follows model is a line-based structure. Lines starting with a # are ignored. This first line is exactly `directly follows model'.\ The second line is a boolean indicating whether the model supports empty traces.\ The third line is the number of activities in the model.\ The following lines each contain an activity. For a single-line activity, escape a starting `$' by doubling it to `$'. For a multiline activity, start with a line `$multiline', and end with a line `multiline$' To end any line end with `$', double it to `$$'.\ The next line contains the number of start activities, followed by, for each start activity, a line with the index of the start activity, followed by a `w` and the weight of the start activity.\ The next line contains the number of end activities, followed by, for each end activity, a line with the index of the end activity, followed by a `w` and the weight of the end activity.\ The next line contains the number of edges, followed by, for each edge, a line with first the index of the source activity, then the `>` symbol, then the index of the target activity, then a `w`, and then the weight of the transition. For instance:

stochastic directly follows model
# empty traces weight
0
# number of nodes
2
#node 0
a
#node 1
b
# number of start nodes
2
0w2/5
1w3/5
# number of end nodes
2
0w4/5
1w1/5
# number of edges
3
# edges
0>0w1/5
0>1w1/5
1>0w3/5

The following table gives an overview of several directly follows-based file types and their features:

File type	stochastic	multiple nodes with the same label	silent transitions	file syntax
directly follows model (.dfm)	no	yes	no	line-based
directly follows graph (.dfg)	weights	no	no	JSON
stochastic directly follows model (.sdfm)	yes	yes	no	line-based
stochastic deterministic finite automaton (.sdfa)	yes	yes	no	line-based
stochastic non-deterministic finite automaton (.snfa)	yes	yes	yes	line-based

Stochastic labelled petri net (.slpn)

A stochastic labelled Petri net file can serve as input to the following commands:

A stochastic labelled Petri net file can be the output of the following commands:

File format specification: A stochastic labelled Petri net is a line-based structure. Lines starting with a # are ignored. This first line is exactly `stochastic labelled Petri net'. If the second is line is exactly `empty language', then the model is considered to have an empty language and parsing stops. Otherwise, the second line is the number of places in the net. The lines thereafter contain the initial marking: each place has its own line with the number of tokens on that place in the initial marking. The next line is the number of transitions in the net. Then, for each transition, the following lines are next: (i) the word `silent' or the word `label ' directly followed by the activity label, or a line with `multiline label' followed by the label, terminated with a line `multiline$' (a `$' at each line end can be escaped with `$$'); (ii) the weight of the transition, which may be any fraction or decimal number, even 0 or negative; (iii) the number of input places, followed by a line for each input place with the index of the place; (iiii) the number of output places, followed by a line for each output place with the index of the place. For instance:

stochastic labelled Petri net
# number of places
3
# initial marking
1
0
0
# number of transitions
5
# transition 0
label a
# weight
0
# number of input places
1
0
# number of output places
1
1
# transition 1
label b
# weight
1
# number of input places
1
0
# number of output places
1
2
# transition 2
label a
# weight
0
# number of input places
1
1
# number of output places
0
# transition 3
label b
# weight
0
# number of input places
1
1
# number of output places
0
# transition 4
label a
# weight
1
# number of input places
1
2
# number of output places
0

Stochastic language of alignments (.sali)

A stochastic language of alignments file can serve as input to the following commands:

A stochastic language of alignments file can be the output of the following commands:

Ebi conformance-non-stochastic alignments

File format specification: A stochastic language of alignments is a line-based structure. Lines starting with a # are ignored. This first line is exactly `stochastic language of alignments'. The second line is the number of alignments in the language. For each alignment, the first line contains the probability of the alignment in the language, which is either a positive fraction or a decimal value. The second line contains the number of moves in the alignment. Then, each move is given as either

`synchronous move', followed by a line with the word `label' followed by a space and the activity label, which is followed with a line with the index of the involved transition.
`silent move', followed by a line with the index of the silent transition.
`log move', followed by a line with the word `label', then a space, and then the activity label.
`model move', followed by a line with the word `label' followed by a space and the activity label, which is followed with a line with the index of the involved ransition.

For instance:

stochastic language of alignments
# number of alignments
3
# alignment 0
# weight
1/5
# number of moves
3
# move 0
synchronous move
label a
0
# move 1
synchronous move
label b
1
# move 2
silent move
2
# alignment 1
# weight
3/5
# number of moves
4
# move 0
model move
label a
0
# move 1
synchronous move
label b
1
# move 2
silent move
2
# move 3
log move
label a
# alignment 2
# weight
1/5
# number of moves
4
# move 0
synchronous move
label a
0
# move 1
model move
label b
1
# move 2
silent move
2
# move 3
log move
label a

Stochastic non deterministic finite automaton (.snfa)

A stochastic non-deterministic finite automaton file can serve as input to the following commands:

A stochastic non-deterministic finite automaton file can be the output of the following commands:

File format specification: A stochastic non-deterministic finite automaton is a line-based structure. Lines starting with a # are ignored. This first line is exactly `stochastic non-deterministic finite automaton'. The second line is the initial state of the SNFA, or the word `None'. The third line is the number of states in the SNFA. The fourth line is the number of transitions in the SNFA. Then, for each transition, the following lines are next: (i) the source state of the transition; (ii) the target state of the transition; (iii) the probability of the transition; (iv) the word `silent' or the word `label ' directly followed by the activity label, or a line with `multiline label' followed by the label, terminated with a line `multiline$' (a `$' at each line end can be escaped with `$$'). A stochastic non-deterministic finite automaton will have one probability for each (source, activity, target). For instance:

stochastic non-deterministic finite automaton
# initial state
0
# number of states
5
# number of transitions
6
# transition 0
# source
0
# target
1
# probability
1/2
# activity
label a
# transition 1
# source
1
# target
4
# probability
1
# activity
label a
# transition 2
# source
0
# target
2
# probability
1/3
# activity
label a
# transition 3
# source
2
# target
4
# probability
1
# activity
label b
# transition 4
# source
0
# target
3
# probability
1/6
# activity
label b
# transition 5
# source
3
# target
4
# probability
1
# activity
label a

The following table gives an overview of several directly follows-based file types and their features:

File type	stochastic	multiple nodes with the same label	silent transitions	file syntax
directly follows model (.dfm)	no	yes	no	line-based
directly follows graph (.dfg)	weights	no	no	JSON
stochastic directly follows model (.sdfm)	yes	yes	no	line-based
stochastic deterministic finite automaton (.sdfa)	yes	yes	no	line-based
stochastic non-deterministic finite automaton (.snfa)	yes	yes	yes	line-based

Stochastic process tree (.sptree)

A stochastic process tree file can serve as input to the following commands:

A stochastic process tree file can be the output of the following commands:

File format specification: A stochastic process tree is a line-based structure. Lines starting with a # are ignored. This first line is exactly `stochastic process tree'. The subsequent lines contain the nodes: Each node is either:

A line with the word `activity' followed on the same line by a space and the label of the activity leaf. The next line contains the weight of the activity;
The word `tau', followed on the next line by the weight of the leaf;
The name of an operator (`sequence', `xor', `concurrent', `loop', `interleaved', or `or') on its own line. The line thereafter contains the number of children of the node, after which the nodes are given. An operator node must have at least one child.

Indentation of nodes is allowed, but not mandatory.\ The last line of the file contains the weight of termination. For instance:

stochastic process tree
xor
# number of children
2
	sequence
	# number of children
	2
		activity a0
		# weight node 2
		1
		activity b1
		# weight node 3
		2
	concurrent
	# number of children
	4
		activity c2
		# weight node 5
		3
		loop
		# number of children
		2
			activity d3
			# weight node 7
			4
			activity e4
			# weight node 8
			5
		interleaved
		# number of children
		2
			activity f5
			# weight node 10
			6
			sequence
			# number of children
			2
				tau
				# weight node 12
				7
				activity g7
				# weight node 13
				8
		or
		# number of children
		2
			activity h8
			# weight node 15
			9
			activity i9
			# weight node 16
			10
# termination weight
5