Guide for Experimenters

1 Experiment Management

1.1 Experiment DSL (FEDSpec)

FIESTA-IoT experiment management is facilitated by the usage of a descriptive language (DSL) that is capable of hosting all the experiments of a specific User. This language is called FIESTA-IoT Experiment Model Object (FEDSpec) and is depicted in 1st Figure.

FEDSpec, as shown in the figure, can host all the defined experiments of an Experimenter by including multiple FIESTA-IoT Experiment Model Objects (FEMO). FEMO is responsible of holding the description of a single experiment and consists of:

  • The description: (Optional) where a short textual description of the experiment can be added. 
  • The Experiment Design Metadata (EDM): (Optional) where the graphical metadata of the experiment editor can be stored (i.e. node-red) that facilitate the conversion of a FEMO to a graphical representation of the experiment to an Editor (these metadata are editor specific).
  • The domain of interest: where we can have the list of domains of interest of the experiment, which can be used for discovery purposes, based on the M3-lite taxonomy.
  • The FIESTA Service Model Object (FISMO): which is the main and most important experiment descriptive entity, one or many of which can be included in a FEMO object and thus create a complete experiment. 

FISMO, as shown in 2nd Figure above, consists of the following entities:

  • The description: (Optional) where a short textual description of the experiment's Service can be added.
  • The discoverable: (Optional) here a Boolean defines if the experiment is discoverable or not.
  • The service: (Optional) here the URL for accessing the “iot-lite:Service” can be hosted for providing access to the semantic datasets.
  • The experiment control: which controls how the Service should be processed; in particular, it specifies the conditions under which the service should be invoked (e.g., specifying a periodic schedule, defining specific visualizations, etc.). This control is facilitated by the following entities (shown in 3rd Figure below):
    • Scheduling: (Optional) which may be defined to specify a periodic schedule for query execution for a specific subscription. The schedule of the Service could be defined, if required, by identifying:
      • Start time: (Optional) the time that the service should be started.
      • Periodicity: (Optional) how often the service will be executed.
      • Stop time: (Optional) when the service should be stopped.
    • Trigger: (Optional) the URL that should be invoked in order to trigger the execution of the Service if required
    • Report if empty: (Optional) If true, a Result Set is always sent to the subscriber when the query is executed. If false, a Result Set instance is sent to the subscriber only when the results are non-empty.

  • The experiment output: (shown in 4th Figure below) which defines the required information for the instantiation of the output of an experiment. The output could be provided in various ways i.e. visualization (widget) at a webpage or as a file. The output configuration is facilitated by the following entities:
    • The location: which hosts the URI where the output should be sent.
    • The file: (Optional) where the file type of the output can be identified. The current valid list of files types that are supported are

-      "text/plain",

-      "text/tab-separated-values",

-      "text/csv",

-      "application/sparql-results+json",

-      "application/sparql-results+xml",

-      "application/sparql-results+thrift",

-      "application/json",

-      "text/xml" and

-      "application/xml"

    • The widget: (Optional) which defines the required information for the instantiation of the presentation GUI as defined at the initial user request at the experiment definition time. For example, the widget that is going to be used for representing the data like a speedometer, a spreadsheet, a map or a diagram.

  • The query control: is responsible to host the description of the required query that should be executed in order to provide the results/data from this experiment Service. Along with the query itself it holds additional entities that enable the discovery and dynamic configuration of the query. The query control configuration is facilitated by the following entities (shown in 5th Figure below):
    • Quantity kind: (optional) a list of quantity kind URIs, based on the m3-lite taxonomy, to identify the type of measurements involved in this query.
    • Static location: (optional) the geo-coordinates of the experiment/query that will facilitate the experiment discovery.
    • Query interval: (optional) provides the time interval that the query should collect data from by explicitly specifying the start/stop date/time (fromDateTime - toDateTime). Alternatively it can hold the duration in seconds from the present to the past in order to dynamically calculate the start/stop date/time. The latter is used if the experiment wants to get at each execution the values of the last X hours, X days etc.
    • Query request: this entity is the most important entity of the FISMO object and holds the W3C query data (SPARQL) that should be executed in order to retrieve the results of the experiment Service.
    • Dynamic attributes: (optional) this entity provides the ability to dynamically update attributes of the query at the runtime of an experiment (i.e. in a mobile application to provide the CO2 level of the current location the experiment geo-coordinates should be updated in each experiment execution). Dynamic attributes provides predefined attributes (the predefined dynamic attributes) and experimenter defined attributes (list of dynamic attribute) shown below:
      • Predefined dynamic attributes: (optional) it provides a list of dynamic attributes with a predefined name and a user defined initial value. These attributes currently include the:
              • dynamic query interval which further contains:
                • fromDateTime,
                • toDateTime and
                • intervalNowToPast which is defined as milliseconds from now to past. If this is set then fromDateTime and toDateTime are not used.
              • dynamic geo-location: This contains latitude and longitude information in the string format.
      • Dynamic attribute: (optional) it provides a list of dynamic attributes with a user defined name and a user defined initial value.
  • The rule: (optional) which hosts a rule that should be applied on top of the service results. The rule configuration is facilitated with the help of the following entities (shown in 6th Figure below):
    • The name: a textual representation of the applied rule name
    • The rule definition: a textual representation of the applied rule code which can be a Jena rule or a SPARQL CONSTRUCT.
    • Domain Knowledge: the URI stating the domain knowledge of the rule
    • Quantity kind: a list of quantity kind URIs based on the m3-lite taxonomy.