Print bookPrint book

Guide for Experimenters

This guide help you in questions related to the Experiment management tool and IoT-Registry API for advanced experimenters. 

Site: FIESTA-IoT Training Platform
Course: Guide for 3rd Parties
Book: Guide for Experimenters
Printed by: Guest user
Date: Friday, 23 June 2017, 9:01 PM

1 Experiment management

This guide explores three important areas to help the new Experimenters in FIESTA-IoT. You can find relevant information about:

  1. Experiment Management
  2. Experiment Registry Management (ERM) API, and
  3. IoT-Registry API.

1.1 Experiment DSL (FEDSpec)

FIESTA-IoT experiment management is facilitated by the usage of a descriptive language (DSL) which 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.

  • 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 (i.e. CSV, XLS, XML, etc.)
      • 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 and
          • dynamic geo-location
        • 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.

    You can find the FEDSpec .xml template here.

    1.2 Define an experiment through Domain Specification Language (DSL)

    Currently EEE or the Experiment Execution Engine does not support all the attributes available within DSL. Within FISMO, we only support name, description, discoverable, scheduling, experiment output, and query attribute. Experimenters should consider replacing “#*#” with experiment requirements. For simplicity we provide a template of FISMO that is supported by the EEE. 

    <fed:FISMO name="#NAME#">

    <fed:description>#DESCRIPTION#</fed:description>

    <fed:discoverable>#DISCOVERABLE#</fed:discoverable>

    <fed:experimentControl><fed:scheduling>

    <fed:startTime>#STARTTIME#</fed:startTime>

    <fed:Periodicity>#PERIODICITY#</fed:Periodicity>

    <fed:stopTime>#STOPTIME#</fed:stopTime>

    </fed:scheduling></fed:experimentControl>

    <fed:experimentOutput location="#URLLOCATION#"></fed:experimentOutput>

    <fed:queryControl><prt:query-request><query><![CDATA[

        #[1/1] visualization type: 'Gauge' and sensors

    #QUERY#

    ]]</query></prt:query-request></fed:queryControl>

    </fed:Fismo>



    To further explain,

    • #NAME#: should be the name of the FISMO that experimenter want to have. For example:

    <fed:FISMO name="2ndUseCase">

     

    • #DESCRIPTION#: should be the description of the FISMO to understand what is the FISMO is about. For example:

    <fed:description>Over time all noise observations for a given location</fed:description>

     

    • #DISCOVERABLE#: should be either “true” or “false”. As explained before this attribute is used by the EEE to know whether the FISMO can be shown in the “Other Available FISMO IDs for subscriptions” tab in the Experiment Management Console. Using this other experimenters could reuse the query and scheduling information (subscribers should giving a new location that would send the results to them). For example:

    <fed:discoverable>true</fed:discoverable>

     

    • #STARTTIME#: it is the time when the scheduling should start. In case, the #STARTTIME# in the past, the current time will be used and in case #STARTTIME# is in future, the given time will be used by the EEE to schedule the FISMO. The #STARTTIME# should be in DATETIME format.

    <fed:startTime>2016-11-08T18:50:00.0Z</fed:startTime>

     

    • #PERIODICITY#: it is the period after which the EEE should re-trigger the execution of the FISMO. It is in INTEGER format and denotes the Seconds. For example:

    <fed:Periodicity>250</fed:Periodicity>

     

    • #STOPTIME#: it is the time when the EEE should stop executing the FISMO. In case, the #STARTTIME# in the past, and is less than #STARTTIME# an error is raised by the EEE. Thus it is advisable that the #STOPTIME# is in future and is greater than #STARTTIME# The #STOPTIME# should be in DATETIME format. For example:

    <fed:stopTime>2017-11-08T18:49:59.0Z</fed:stopTime>

     

    • #URLLOCATION#: it should be the location where the results of the query should be returned. This is usually a valid url location. For example:

    <fed:experimentOutput location="http://ExperimentServer/store/"></fed:experimentOutput>

     

    • #QUERY#: is the actual SPARQL query that should be executed by the EEE on the Meta-Cloud.  For best results we advice not to provide following query and be specific to the needs.

     select * where {?s ?p ?o.}

     

    The above query would hinder the performance of the EEE. A valid query would look like:

    Prefix ssn: <http://purl.oclc.org/NET/ssnx/ssn#>

    Prefix iotlite: <http://purl.oclc.org/NET/UNIS/fiware/iot-lite#>

    Prefix dul: <http://www.loa.istc.cnr.it/ontologies/DUL.owl#>

    Prefix geo: <http://www.w3.org/2003/01/geo/wgs84_pos#>

    Prefix time: <http://www.w3.org/2006/time#>

    Prefix m3-lite: <http://purl.org/iot/vocab/m3-lite#>

    Prefix xsd: <http://www.w3.org/2001/XMLSchema#>

    select ?s ?tim ?val

          where {

    ?o a ssn:Observation.

    ?o ssn:observedBy ?s.  

    ?o ssn:observedProperty ?qkr.

    ?qkr a ?qk.

    Values ?qk {m3-lite:Sound m3-lite:SoundPressureLevelAmbient}

    o ssn:observationSamplingTime ?t.

    ?o geo:location ?point.

    ?point geo:lat "4.346104E1"^^xsd:double.

    ?point geo:long "-3.80649E0"^^xsd:double.

    ?t time:inXSDDateTime ?ti.

    ?o ssn:observationResult ?or.

    ?or  ssn:hasValue ?v.

    ?v dul:hasDataValue ?val. 

    } group by (?s) ?tim ?val

    Note that the #QUERY# should be between “<![CDATA[#[1/1] visualization type: 'Gauge' and sensors” and “]]”.



    On top of the FISMO there is a FEMO object. Currently EEE support the following FEMO template.

    <fed:FEMO name="#FEMONAME#">

    <fed:description>#FEMODESCRIPTION#</fed:description>

    <fed:domainOfInterest>#DOMAINOFINTERESTLIST#</fed:domainOfInterest>

           <fed:FISMO name="#NAME#">

    </fed:FISMO>

    </fed:FEMO>



    Here:

    • #FEMONAME#: should be the name of the FEMO that experimenter want to have. For example:

    <fed:FEMO name="MySecondExperiment">

     

    • #FEMODESCRIPTION#: should be the description of the FEMO to understand what is the FEMO is about. For example:

    <fed:description>LargeScale crowdsensing experiment </fed:description>

     

    • #DOMAINOFINTERESTLIST#:  this is the list of the domain of interests that experiment supports. For multiple domain of interests values should be blank space separated. For example.

    <fed:domainOfInterest>http://purl.org/iot/vocab/m3-lite#Transportation http://purl.org/iot/vocab/m3-lite#Pollution http://purl.org/iot/vocab/m3-lite#City http://purl.org/iot/vocab/m3-lite#Health</fed:domainOfInterest>

     

    Further on the top of the FEMO object, there exists a FEDSpec object.

     

    <fed:FEDSpec xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

    xmlns:fed="http://www.fiesta-iot.eu/fedspec"

    xmlns:prt="http://www.w3.org/2007/SPARQL/protocol-types#"

    xmlns:vbr="http://www.w3.org/2007/SPARQL/results#"

    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

    xsi:schemaLocation="FILELOCATION" 

    userID="#USERID#">

    <fed:FEMO name="#FEMONAME#">

    </fed:FEMO>

    </fed:FEDSpec>

    One important thing to note here is the #USERID#. Please use your #USERID#. Do not use any other #USERID# in case you use it, you will not be able to view or perform any operations on the services you need.

    For complete valid sample please consult the following table:

    Experiment Instance (FEDSpec Example)

    <?xml version="1.0" encoding="UTF-8"?>

    <fed:FEDSpec

      xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

      xmlns:fed="http://www.fiesta-iot.eu/fedspec"

      xmlns:prt="http://www.w3.org/2007/SPARQL/protocol-types#"

      xmlns:vbr="http://www.w3.org/2007/SPARQL/results#"

      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

      xsi:schemaLocation="http://www.fiesta-iot.eu/fedspec file:/C:/Ext_SSD/AIT/FIESTA/FIESTA-SVN/WP4/Task%204.1/Objects/XSD/FEDSpec.xsd" userID="YOURSERID"

      <fed:FEMO name="MySecondExperiment">

        <fed:description>LargeScale crowdsensing experiment</fed:description>

        <fed:domainOfInterest>http://purl.org/iot/vocab/m3-lite#Transportation

          http://purl.org/iot/vocab/m3-lite#Pollution

          http://purl.org/iot/vocab/m3-lite#City

          http://purl.org/iot/vocab/m3-lite#Health

        </fed:domainOfInterest>

        <fed:FISMO name="2ndUseCase">

          <fed:description>Over time all noise observations

                            for a given location</fed:description>

          <fed:discoverable>true</fed:discoverable>

          <fed:experimentControl>

            <fed:scheduling>

              <fed:startTime>2016-11-08T18:50:00.0Z</fed:startTime>

              <fed:Periodicity>250</fed:Periodicity>

              <fed:stopTime>2017-11-08T18:49:59.0Z</fed:stopTime>

            </fed:scheduling>

          </fed:experimentControl>

          <fed:experimentOutput

            location="http://ExperimentServer.org/store/"

          ></fed:experimentOutput>

          <fed:queryControl>

            <prt:query-request>

              <query><![CDATA[

                            # [1 / 1] visualization type: 'Gauge' and sensors

                            Prefix ssn: <http://purl.oclc.org/NET/ssnx/ssn#>

                            Prefix iotlite: <http://purl.oclc.org/NET/UNIS/fiware/

                                               iot-lite#>

                            Prefix dul:

                                 <http://www.loa.istc.cnr.it/ontologies/DUL.owl#>

                            Prefix geo: <http://www.w3.org/2003/01/geo/wgs84_pos#>

                            Prefix time: <http://www.w3.org/2006/time#>

                            Prefix m3-lite: <http://purl.org/iot/vocab/m3-lite#>

                            Prefix xsd: <http://www.w3.org/2001/XMLSchema#>

                            select ?s ?tim ?val

                            where {

                                ?o a ssn:Observation.

                                ?o ssn:observedBy ?s.  

                                ?o ssn:observedProperty ?qkr.

                                ?qkr a ?qk.

                                Values ?qk {m3-lite:Sound

                                           m3-lite:SoundPressureLevelAmbient}

                                ?o ssn:observationSamplingTime ?t.

                                ?o geo:location ?point.

                                ?point geo:lat "4.346104E1"^^xsd:double.

                                ?point geo:long "-3.80649E0"^^xsd:double.

                                ?t time:inXSDDateTime ?ti.

                                ?o ssn:observationResult ?or.

                                ?or  ssn:hasValue ?v.

                                ?v dul:hasDataValue ?val. 

                            } group by (?s) ?tim ?val

                        ]]></query>

            </prt:query-request>

          </fed:queryControl>

        </fed:FISMO>

        <fed:FISMO name="3rdUseCase">

          <fed:description>Over time noise observations for a

                     given bounding box (time period in scheduling)</fed:description>

          <fed:discoverable>true</fed:discoverable>

          <fed:experimentControl>

            <fed:scheduling>

              <fed:startTime>2016-11-08T18:50:00.0Z</fed:startTime>

              <fed:Periodicity>250</fed:Periodicity>

              <fed:stopTime>2017-11-08T18:49:59.0Z</fed:stopTime>

            </fed:scheduling>

          </fed:experimentControl>

          <fed:experimentOutput

            location="http://ExperimentServer.org/store/"

          ></fed:experimentOutput>

          <fed:queryControl>

            <prt:query-request>

              <query><![CDATA[

                            # [1 / 1] visualization type: 'Gauge' and sensors

                            Prefix ssn: <http://purl.oclc.org/NET/ssnx/ssn#>

                            Prefix iotlite:

                              <http://purl.oclc.org/NET/UNIS/fiware/iot-lite#>

                            Prefix dul:

                              <http://www.loa.istc.cnr.it/ontologies/DUL.owl#>

                            Prefix geo: <http://www.w3.org/2003/01/geo/wgs84_pos#>

                            Prefix time: <http://www.w3.org/2006/time#>

                            Prefix m3-lite: <http://purl.org/iot/vocab/m3-lite#>

                            Prefix xsd: <http://www.w3.org/2001/XMLSchema#>

                            select ?s (max(?ti) as ?tim) ?val ?lat ?long

                            where {

                                ?o a ssn:Observation.

                                ?o ssn:observedBy ?s.  

                                ?o ssn:observedProperty ?qkr.

                                ?qkr aqk.

                                Values ?qk {m3-lite:

                                      Sound m3-lite:SoundPressureLevelAmbient}

                                ?o ssn:observationSamplingTime ?t.

                                ?o geo:location ?point.

                                ?point geo:lat ?lat.

                                ?point geo:long ?long.

                                ?t time:inXSDDateTime ?ti.

                                ?o ssn:observationResult ?or.

                                ?or  ssn:hasValue ?v.

                                ?v dul:hasDataValue ?val.

                                {

                                    select  (max(?dt)as ?ti) ?s        

                                    where {

                                        ?o a ssn:Observation.

                                        ?o ssn:observedBy ?s.  

                                        ?o ssn:observedProperty ?qkr.

                                        ?qkr a ?qk.

                                        Values ?qk {m3-lite:Sound

                                            m3-lite:SoundPressureLevelAmbient}

                                        ?o ssn:observationSamplingTime ?t.

                                        ?t time:inXSDDateTime ?dt.

                                    }group by (?s)

                                }

                                FILTER (

                                   (xsd:double(?lat) >= "-90"^^xsd:double)

                                && (xsd:double(?lat) <= "90"^^xsd:double)

                                && ( xsd:double(?long) >= "-180"^^xsd:double) 

                                && ( xsd:double(?long) <= "180"^^xsd:double)

                                ) 

                            } group by (?s) ?tim ?val ?lat ?long

                        ]]></query>

            </prt:query-request>

          </fed:queryControl>

        </fed:FISMO>

        <fed:FISMO name="4thUseCase">

          <fed:description>3rd usecase with noise more than x dB(A)</fed:description>

          <fed:discoverable>true</fed:discoverable>

          <fed:experimentControl>

            <fed:scheduling>

              <fed:startTime>2016-11-08T18:50:00.0Z</fed:startTime>

              <fed:Periodicity>250</fed:Periodicity>

              <fed:stopTime>2017-11-08T18:49:59.0Z</fed:stopTime>

            </fed:scheduling>

          </fed:experimentControl>

          <fed:experimentOutput

            location="http://ExperimentServer.org/store/"

          ></fed:experimentOutput>

          <fed:queryControl>

            <prt:query-request>

              <query><![CDATA[

                            # [1 / 1] visualization type: 'Gauge' and sensors

                            Prefix ssn: <http://purl.oclc.org/NET/ssnx/ssn#>

                            Prefix iotlite:

                                <http://purl.oclc.org/NET/UNIS/fiware/iot-lite#>

                            Prefix dul:

                              <http://www.loa.istc.cnr.it/ontologies/DUL.owl#>

                            Prefix geo: <http://www.w3.org/2003/01/geo/wgs84_pos#>

                            Prefix time: <http://www.w3.org/2006/time#>

                            Prefix m3-lite: <http://purl.org/iot/vocab/m3-lite#>

                            Prefix xsd: <http://www.w3.org/2001/XMLSchema#>

                            select ?s (max(?ti) as ?tim) ?val ?lat ?long

                            where {

                                ?o a ssn:Observation.

                                ?o ssn:observedBy ?s.  

                                ?o ssn:observedProperty ?qkr.

                                ?qkr a ?qk.

                                Values ?qk {m3-lite:Sound m3-lite:SoundPressureLevelAmbient}

                                ?o ssn:observationSamplingTime ?t.

                                ?o geo:location ?point.

                                ?point geo:lat ?lat.

                                ?point geo:long ?long.

                                ?t time:inXSDDateTime ?ti.

                                ?o ssn:observationResult ?or.

                                ?or  ssn:hasValue ?v.

                                ?v dul:hasDataValue ?val.

                                {

                                    select  (max(?dt)as ?ti) ?s        

                                    where {

                                        ?o a ssn:Observation.

                                        ?o ssn:observedBy ?s.  

                                        ?o ssn:observedProperty ?qk.

                                        ?qkr a ?qk.

                                        Values ?qk {m3-lite:Sound

                                             m3-lite:SoundPressureLevelAmbient}

                                        ?o ssn:observationSamplingTime ?t.

                                        ?t time:inXSDDateTime ?dt.

                                    }group by (?s)

                                }

                                FILTER (

                                   (xsd:double(?lat) >= "-90"^^xsd:double)

                                && (xsd:double(?lat) <= "90"^^xsd:double)

                                && ( xsd:double(?long) >= "-180"^^xsd:double) 

                                && ( xsd:double(?long) <= "180"^^xsd:double)

                                )  

                                FILTER(?val>="75"^^xsd:double)

                            } group by (?s) ?tim ?val ?lat ?long

                        ]]></query>

            </prt:query-request>

          </fed:queryControl>

        </fed:FISMO>

        <fed:FISMO name="5thUseCase">

          <fed:description>3rd usecase with noise less than x dB(A)</fed:description>

          <fed:discoverable>true</fed:discoverable>

          <fed:experimentControl>

            <fed:scheduling>

              <fed:startTime>2016-11-08T18:50:00.0Z</fed:startTime>

              <fed:Periodicity>250</fed:Periodicity>

              <fed:stopTime>2017-11-08T18:49:59.0Z</fed:stopTime>

            </fed:scheduling>

          </fed:experimentControl>

          <fed:experimentOutput

            location="http://ExperimentServer.org/store/"

          ></fed:experimentOutput>

          <fed:queryControl>

            <prt:query-request>

              <query><![CDATA[

                            # [1 / 1] visualization type: 'Gauge' and sensors

                            Prefix ssn: <http://purl.oclc.org/NET/ssnx/ssn#>

                            Prefix iotlite:

                                <http://purl.oclc.org/NET/UNIS/fiware/iot-lite#>

                            Prefix dul:

                                 <http://www.loa.istc.cnr.it/ontologies/DUL.owl#>

                            Prefix geo: <http://www.w3.org/2003/01/geo/wgs84_pos#>

                            Prefix time: <http://www.w3.org/2006/time#>

                            Prefix m3-lite: <http://purl.org/iot/vocab/m3-lite#>

                            Prefix xsd: <http://www.w3.org/2001/XMLSchema#>

                            select ?s (max(?ti) as ?tim) ?val ?lat ?long

                            where {

                                ?o a ssn:Observation.

                                ?o ssn:observedBy ?s.  

                                ?o ssn:observedProperty ?qkr.

                                ?qkr a ?qk.

                                Values ?qk {m3-lite:Sound

                                       m3-lite:SoundPressureLevelAmbient}

                                ?o ssn:observationSamplingTime ?t.

                                ?o geo:location ?point.

                                ?point geo:lat ?lat.

                                ?point geo:long ?long.

                                ?t time:inXSDDateTime ?ti.

                                ?o ssn:observationResult ?or.

                                ?or  ssn:hasValue ?v.

                                ?v dul:hasDataValue ?val.

                                {

                                    select  (max(?dt)as ?ti) ?s        

                                    where {

                                        ?o a ssn:Observation.

                                        ?o ssn:observedBy ?s.  

                                        ?o ssn:observedProperty ?qkr.

                                        ?qkr a ?qk.

                                        Values ?qk {m3-lite:Sound

                                             m3-lite:SoundPressureLevelAmbient}

                                        ?o ssn:observationSamplingTime ?t.

                                        ?t time:inXSDDateTime ?dt.

                                    }group by (?s)

                                }

                                FILTER (

                                   (xsd:double(?lat) >= "-90"^^xsd:double)

                                && (xsd:double(?lat) <= "90"^^xsd:double)

                                && ( xsd:double(?long) >= "-180"^^xsd:double) 

                                && ( xsd:double(?long) <= "180"^^xsd:double)

                                )  

                                FILTER(?val<="45"^^xsd:double)

                            } group by (?s) ?tim ?val ?lat ?long

                        ]]></query>

            </prt:query-request>

          </fed:queryControl>

        </fed:FISMO>

      </fed:FEMO>

    </fed:FEDSpec>

    1.3 Register a new experiment

    FIESTA-IoT is currently offering a simple interface in order to Store, Update and delete experiments called Experiment Register Client. The Experiment Register Client can be found at the Experimenter menu of the FIESTA-IoT portal (see 1st Figure below).

    The Experiment Register Client provides the ability to store an experiment at the FIESTA-IoT platform in the form of a FEDSpec. The defined FEDSpec could be as simple as a single service (FISMO) or as complex as multiple experiments (FEMOs). To upload a FEDSpec first one should identify the location of it by hitting the “Open FEDSpec” (see 2nd Figure below) and then by hitting the “Save FEDSpec” button. As soon as the FEDSpec is saved the included FEMOS appears in the available experiments list (FEMOS) as shown in 2nd Figure below. When uploading a FEDSpec the FEMO/FISMO IDs should be empty, as they will be automatically assigned by the system. 

    By choosing, a FEMO from the User is capable to have a quick overview of it as shown in 3rd Figure below.

    The tools provides also the ability to export a FEMO by hitting the “Export FEDSPEC” button after choosing the FEMO of interest from the provided list. The FEDSpec that will be exported will now contain the FEMO/FISMO IDs assigned from the FIESTA-IoT platform. This will give the Experimenter the ability to update the exported FEMO/FISMO by updating the XML file and saving it again to the Experiment Repository following the same process described above.

    1.4 Run/Execute an experiment

    Experiment execution is handled by a component called “Experiment execution Engine” or EEE. This module uses and supports the experiment description written by an experimenter in the domain specific language (DSL) format specified by FIESTA-IoT.

    Amongst the available features in the DSL, in the current version, EEE supports only a few.  These include starting an experiment service (FISMO), pausing a FISMO, restarting a FISMO, subscribing to already existing and discoverable FISMOs, unsubscribing from subscribed FISMOs, and polling a FISMO (executing one time a FISMO on the FIESTA-IoT platform).

    The EEE specific APIs are available here for developers or experimenters for testing and more in-depth knowledge about specific APIs. Nevertheless, experimenters can also use Experiment Management Console and perform actions on the FISMO.

    In order to execute an experiment using Experiment Management Console that is described by its FISMOs, the Experimenter first need to go to: https://platform.fiesta-iot.eu/experimentConsole/experimentConsole.jsp.

    Upon successful authentication list of experiments associated with the experimenter or the user is retrieved as shown in following figure.



    From this view, experimenters can then select whichever experiment they want to work on from the list using the “SELECT” button next to each experiment.  Once a particular experiment is selected, this would open another UI (as shown in 2nd Figure to 4th Figure, the entire UI is divided into 3 panes: Experiment Details, Associated FISMOs, and Subscription Pane) where experiment name, experiment description, a list of experiment Domain of Interest along with Associated FISMOs and available FISMOs for subscription is shown.

    An experimenter can choose to update the metadata of the experiment that he/she has created using “OPEN EXPERIMENT EDITOR”. This will open the UI where experimenter can resubmit their updated Experiments. Upon these resubmissions, a service in EEE is triggered that changes only the scheduling interval. If the scheduling interval is not changed nothing is updated on the EEE.

    The “Associated FISMOs” pane shows the “meta” information about the FISMOs that are associated to a particular experiment. The “meta” information includes: if the FISMO was Owned or Subscribed within the frame of an experiment, the status of the FISMO (either NOT YET SCHEDULLED, NORMAL, PAUSED, etc.), past execution history and polling option. In order to check for the description of the FISMO, experimenter can click on the name. This will open a snackbar in the bottom of the page and will show the description of the selected FISMO.

    Initially, all the FISMOs have the NOT YET SCHEDULLED status. If the experimenter wants to start the FISMO, they can switch the toggle button. Upon first toggle, the FISMO will be scheduled by the EEE with the NORMAL status. Another toggle would PAUSE the FISMO execution. Yet another toggle would restart the PAUSED FISMO. In order to successfully schedule the FISMO execution, the current version of the EEE only supports:



    • <fed:scheduling> within <experimentControl> attribute of FISMO,
    • <query> under <prt:query-request> under <fed:queryControl> and
    • <fed:experimentOutput> to identify scheduling attributes and where to send the results of the FISMO execution. 



    A sample of <fed:scheduling> is provided below:

    <fed:scheduling>

           <fed:startTime>2016-11-08T18:13:51.0Z</fed:startTime>

          <fed:Periodicity>600</fed:Periodicity>

          <fed:stopTime>2017-11-08T18:13:50.0Z</fed:stopTime>

    </fed:scheduling>



    The <fed:scheduling> would provide the EEE with the start date, end date and the periodicity of the FISMO execution. Thus making these attributes essential in the FISMO description. Once the schedule is set in the EEE, EEE provides a JOB ID that is used for internal purposes. This JOB ID is then provided with the status NORMAL. Upon the schedule, the <query> is read by the EEE from the FISMO description and is sent to FIESTA-IoT Meta-Cloud.

    The Meta-Cloud executes the query and sends back the results to the EEE. The EEE stores the result internally and pings the location specified in the location specified by the <fed:experimentOutput> (<fed:experimentOutput location=“location”/>).  Upon success, the results are sent to the specified location and deleted from the internal repository. Currently, EEE assumes that the “location” here is a URL, where the specified credentials are granted to the EEE to write the results in a file . For reference and ease, a sample code that experimenters can execute on their server is available here.

    It is thus noteworthy to state that currently EEE only supports one mechanism right now to send the information to the experimenter. Given the above, it is thus essential to specify <fed:scheduling> <experimentControl> attribute of FISMO, <query> under <prt:query-request> under <fed:queryControl> and <fed:experimentOutput  location=“location”>.

    If the experimenter wants to just execute the FISMO and not wait for the EEE to trigger the execution of the FISMO, the experimenter can use POLL NOW. The POLL NOW will execute the <query> defined within the FISMO and would return the results to the same URL that is specified (i.e. the URL where results of scheduled execution are being sent).

    Nonetheless, apart from the above functionality, an experimenter can also subscribe to an already existing FISMO (If there were no FISMOs available for subscription this part would be disabled). In case there are many FISMOs available, an experimenter can choose a particular FISMO from the dropdown list and provide the URL information (see 4th Figure). Note that as EEE only support URL, experimenters must specify a valid endpoint. Only after validating the experimenter’s URL the “SUBSCRIBE” button will be unlocked. The experimenter can currently only choose one FISMO at a time.

    Once successfully subscribed, the list of Associated FISMOs is updated to show the subscriptions. Each new subscription would provide a new JOB ID where the status of the JOB would be NORMAL to the subscribed FISMO and its execution would begin as the schedule specified in the description of that particular subscribed FISMO (see 5th Figure).

    Moreover the URL specified in the FISMO will not be used. Instead the URL specified by the subscriber would be used to forward the results. An experimenter, if wishes, can unsubscribe the subscribed FISMO by clicking “UNSUBSCRIBE”. This will delete the JOB associated from the EEE. Note that in 5th Figure, the Name of 2 FISMOs is same. This can occur due to the fact that another Experimenter has named one of his FISMO exactly the same.

    An experimenter is also given a capability to see the details of past executions of the “Associated FISMOs”. The details are provides in the form of a graph and contains information like how much time did it take to execute the FISMO and how much data was obtained from the Meta-Cloud. This graph however not show how much time did it take to execute the FISMO and how much data was obtained from the Meta-Cloud when the FISMO is polled.

    In order to delete the experiment it is advised that experimenters first stop the execution of any related FISMO objects on the EEE using the Experiment Management Console. Once this is done they are advised to remove the experiment from the Experiment Registry Client. We acknowledge this workflow because this will give experimenters a view of what all services are running and if it is really required to remove them at all.

     

    2 ERM API for Advanced Experimenters

    Experiment Registry Management (ERM) component exposes an API that facilitates the experiment storage, retrieval and discovery. This is achieved by manipulating objects that comply with the FEDSpec schema and its various defined entities.

    2.1 API Definition

    The 1st Table below illustrates the main API primitives that support the Experiment Registry Management functionalities, while 2nd Table below provides more details about each one of the functions that comprise the API.

    List of primitives comprising the Experiment Registry Management API

    <<interface>>

    ExperimentRegistryManagementInterface

    ---

    POST:saveUserExperiments(fedSpec:FEDSpec):String

    POST:deleteUserExperiments (userID:String):String

    POST:saveUserExperiment(femo:FEMO, userID:String):String

    POST:deleteUserExperiment (femoID:String):String

    POST:saveExperimentServiceModelObject (fismo:FISMO, femoID:String):String

    POST:deleteExperimentServiceModelObject (fismoID:String):String

    GET: getALLUserExperiments (userID:String):FEDSpec

    GET:getAllUserExperimentsDescreptions (userID:String):ExpDescriptiveIDs

    GET: getExperimentDescreption (femoID:String):FemoDescriptiveID

    GET:getExperimentModelObject (femoID:String):FEMO

    GET:getExperimentServiceModelObject (fismoID:String):FISMO

               



    The FIESTA-IoT implements the methods of the Experiment Registry Management API as specified in the 2nd Table below:

    Experiment Registry Management API definition

    Service Name

    Input

    Output

    Info

    saveUserExperiments

    FEDSpec fedSpec

    String

    Used to submit the constructed experiment to the cloud. Requires as input the FIESTA Experiment Description Specification (FEDSpec) which includes all the User’s preferences regarding the Experiment, request lifecycle and visualization preferences. It returns the constructed Experiment ID.

    deleteUserExperiments

    String userID

    String

    Used to delete all User experiments. Returns a success message.

    saveUserExperiment

    FEMO femo,

    String userID

    String

    Used to save/update (if the Experiment does not contain a registered ID) a user experiment. Returns a success message.

    deleteUserExperiment

    String femoID

    String

    Used to delete a registered Experiment. Requires as input the Experiment ID. Returns a success message.

    saveExperimentService ModelObject

    FISMO fismo,  String femoID

    String

    Used to Save/update (if the service model object does not contain a registered ID). Returns a success message.

    deleteExperimentServiceModelObject

    String fismoID

    String

    Used to delete an Experiment Service. Returns a success message.

    getALLUserExperiments

    String userID

    FEDSpec

    Used to retrieve All the Experiments defined by a user. It returns an FIESTA Experiment Description Specification. Requires as input a User ID.

    getAllUserExperiments Descreptions

    String userID

    Exp Descriptive IDs

    Used to retrieve the available experiments (a list of experimentID/ServiceName/ServiceDescription triplet) already registered by a specific user. Requires as input a User ID.

    getExperiment Descreption

    String femoID

    Femo Descriptive ID

    Used to retrieve the available services (a list of serviceID/ServiceName/ServiceDescription triplet) already registered by a specific user. Requires as input the Service ID.

    getExperimentModel Object

    String femoID

    FEMO

    Used to retrieve the description (FEMO) of an available Experiment. Requires as input the Experiment ID

    getExperimentService ModelObject

    String fismoID

    FISMO

    Used to retrieve the description (FISMO) of an available service. Requires as input a Service ID.

    2.2 Object Definition

    The FEDSpec XSD, which was described in detail in section 1.1 above, can be found in the following notes more specifically in 1st Table below. In the 1st Figure below we can see the ExpDescriptiveIDs schema graph (the XSD is provided in the notes below too and more specifically in the 2nd Table) which consists of:

    • A list of FEMO Descriptive ID: which is capable of providing a high level deception of an experiment and It includes:
      • The ID of the experiment
      • The description of the experiment
      • The name of the experiment and
      • A list of FISMO Descriptive ID: which is capable of providing a high level deception of a Service Model Object and It includes:
        • The FISMO ID
        • The FISMO description and
        • The FISMO name

    Notes: 

    Experiment Schemata

     

     

    FEDSpec Schema

    <?xml version="1.0" encoding="UTF-8"?>

    <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

     elementFormDefault="qualified" targetNamespace="http://www.fiesta-iot.eu/fedspec"

     xmlns:fed="http://www.fiesta-iot.eu/fedspec" xmlns:prt="http://www.w3.org/2007/SPARQL/protocol-types#">

     

     <xs:import namespace="http://www.w3.org/2007/SPARQL/protocol-types#"

      schemaLocation="sparql/protocol-types.xsd" />

     

     <xs:element name="FEDSpec">

      <xs:annotation>

       <xs:documentation>FIESTA Experiment Description Specification

       </xs:documentation>

      </xs:annotation>

      <xs:complexType>

       <xs:sequence>

        <xs:element maxOccurs="unbounded" ref="fed:FEMO" />

       </xs:sequence>

       <xs:attribute name="userID" use="required" type="xs:anyURI" />

      </xs:complexType>

     </xs:element>

     

     <xs:element name="FEMO">

      <xs:annotation>

       <xs:documentation>FIESTA Experiment Model Object

       </xs:documentation>

      </xs:annotation>

      <xs:complexType>

       <xs:sequence>

        <xs:element minOccurs="0" maxOccurs="1" ref="fed:description" />

        <xs:element minOccurs="0" maxOccurs="1" ref="fed:EDM" />

        <xs:element ref="fed:domainOfInterest" />

        <xs:element maxOccurs="unbounded" ref="fed:FISMO" />

       </xs:sequence>

       <xs:attribute name="id" use="optional" type="xs:anyURI" />

       <xs:attribute name="name" type="xs:NCName" use="required" />

      </xs:complexType>

     </xs:element>

     

     <xs:element name="description" type="xs:string" />

     

     <xs:element name="EDM" type="xs:string">

      <xs:annotation>

       <xs:documentation>Experiment design metadata.</xs:documentation>

      </xs:annotation>

     </xs:element>

     

     <xs:element name="FISMO">

      <xs:annotation>

       <xs:documentation>FIESTA Service Model Object</xs:documentation>

      </xs:annotation>

      <xs:complexType>

       <xs:sequence>

        <xs:element minOccurs="0" maxOccurs="1" ref="fed:description" />

        <xs:element minOccurs="0" name="discoverable" type="xs:boolean"

         default="false" />

        <xs:element ref="fed:experimentControl" />

        <xs:element ref="fed:experimentOutput" />

        <xs:element ref="fed:queryControl" minOccurs="0" />

        <xs:element name="service" nillable="false" type="xs:anyURI"

         minOccurs="0" />

        <xs:element ref="fed:rule" minOccurs="0" />

       </xs:sequence>

       <xs:attribute name="id" use="optional" type="xs:anyURI" />

       <xs:attribute name="name" type="xs:NCName" use="required" />

      </xs:complexType>

     </xs:element>

     

     <xs:element name="queryControl">

      <xs:complexType>

       <xs:sequence>

        <xs:element ref="fed:quantityKind" minOccurs="0" />

        <xs:element ref="fed:staticLocation" minOccurs="0" />

        <xs:element ref="fed:queryInterval" minOccurs="0" />

        <xs:element ref="prt:query-request" maxOccurs="1"

         minOccurs="1" />

        <xs:element maxOccurs="1" minOccurs="0" ref="fed:dynamicAttrs" />

       </xs:sequence>

      </xs:complexType>

     </xs:element>

     

     <xs:element name="domainKnowledge" type="xs:anyURI" />

     

     <xs:element name="staticLocation">

      <xs:complexType>

       <xs:sequence>

        <xs:element name="latitude" type="xs:string" />

        <xs:element name="longitude" type="xs:string" />

       </xs:sequence>

      </xs:complexType>

     </xs:element>

     

     <xs:element name="queryInterval">

      <xs:complexType>

       <xs:sequence>

        <xs:element minOccurs="0" name="fromDateTime" type="xs:dateTime" />

        <xs:element minOccurs="0" name="toDateTime" type="xs:dateTime" />

        <xs:element minOccurs="0" name="intervalNowToPast" type="xs:int" />

       </xs:sequence>

      </xs:complexType>

     </xs:element>

     

     <xs:element name="experimentControl">

      <xs:complexType>

       <xs:sequence>

        <xs:element minOccurs="0" ref="fed:scheduling" maxOccurs="1" />

        <xs:element name="trigger" type="xs:anyURI" minOccurs="0" />

        <xs:element name="reportIfEmpty" type="xs:boolean"

         minOccurs="0" default="true" />

       </xs:sequence>

      </xs:complexType>

     </xs:element>

     

     <xs:element name="rule">

      <xs:complexType>

       <xs:sequence>

        <xs:element ref="fed:ruleDefinition" />

        <xs:element ref="fed:domainKnowledge" />

        <xs:element ref="fed:quantityKind" />

       </xs:sequence>

       <xs:attribute name="name" type="xs:string" />

      </xs:complexType>

     </xs:element>

     

     <xs:element name="ruleDefinition" type="xs:string">

      <xs:annotation>

       <xs:documentation>i.e. Jena rule or SPARQL construct

       </xs:documentation>

      </xs:annotation>

     </xs:element>

     

     <xs:element name="domainOfInterest">

      <xs:annotation>

       <xs:documentation>List of URLs linking with M3-lite taxonomy.

       </xs:documentation>

      </xs:annotation>

      <xs:simpleType>

       <xs:list itemType="xs:anyURI" />

      </xs:simpleType>

     </xs:element>

     

     <xs:element name="quantityKind">

      <xs:annotation>

       <xs:documentation>List of URLs linking with M3-lite taxonomy.

       </xs:documentation>

      </xs:annotation>

      <xs:simpleType>

       <xs:annotation>

        <xs:documentation>URL linking with M3-lite taxonomy.

        </xs:documentation>

       </xs:annotation>

       <xs:list itemType="xs:anyURI" />

      </xs:simpleType>

     </xs:element>

     

     <xs:element name="scheduling">

      <xs:complexType>

       <xs:all>

        <xs:element form="qualified" name="startTime" type="xs:dateTime"

         minOccurs="0" />

        <xs:element name="Periodicity" minOccurs="0" maxOccurs="1"

         type="xs:int" />

        <xs:element minOccurs="0" name="stopTime" type="xs:dateTime" />

       </xs:all>

      </xs:complexType>

     </xs:element>

     

     <xs:element name="experimentOutput">

      <xs:complexType>

       <xs:sequence maxOccurs="1" minOccurs="1">

        <xs:element minOccurs="0" ref="fed:file" maxOccurs="unbounded" />

        <xs:element maxOccurs="unbounded" ref="fed:widget"

         minOccurs="0" />

       </xs:sequence>

       <xs:attribute name="location" type="xs:anyURI" />

      </xs:complexType>

     </xs:element>

     

     <xs:element name="file">

      <xs:complexType>

       <xs:sequence>

        <xs:element name="type" type="xs:string" />

       </xs:sequence>

      </xs:complexType>

     </xs:element>

     

     <xs:element name="widget">

      <xs:complexType>

       <xs:sequence>

        <xs:element maxOccurs="unbounded" ref="fed:presentationAttr" />

       </xs:sequence>

       <xs:attribute name="widgetID" use="required" type="xs:anyURI" />

      </xs:complexType>

     </xs:element>

     

     <xs:element name="presentationAttr">

      <xs:complexType>

       <xs:attribute name="name" use="required" type="xs:string" />

       <xs:attribute name="value" use="required" type="xs:string" />

      </xs:complexType>

     </xs:element>

     

     <xs:element name="dynamicAttrs">

      <xs:annotation>

       <xs:documentation>Definition of the query dynamic attributes and

        their default values

       </xs:documentation>

      </xs:annotation>

      <xs:complexType>

       <xs:sequence>

        <xs:element name="predefinedDynamicAttr" minOccurs="0">

         <xs:complexType>

          <xs:sequence>

           <xs:element ref="fed:dynamicQueryInterval" minOccurs="0" />

           <xs:element ref="fed:dynamicGeoLocation" minOccurs="0" />

          </xs:sequence>

         </xs:complexType>

        </xs:element>

        <xs:element name="dynamicAttr" maxOccurs="unbounded"

         minOccurs="0">

         <xs:complexType>

          <xs:attribute name="name" type="xs:string" />

          <xs:attribute name="value" type="xs:string" />

         </xs:complexType>

        </xs:element>

       </xs:sequence>

      </xs:complexType>

     </xs:element>

     

     <xs:element name="dynamicQueryInterval">

      <xs:complexType>

       <xs:sequence>

        <xs:element minOccurs="0" name="fromDateTime" type="xs:dateTime" />

        <xs:element minOccurs="0" name="toDateTime" type="xs:dateTime" />

        <xs:element minOccurs="0" name="intervalNowToPast" type="xs:int" />

       </xs:sequence>

      </xs:complexType>

     </xs:element>

     

     <xs:element name="dynamicGeoLocation">

      <xs:complexType>

       <xs:sequence>

        <xs:element name="latitude" type="xs:string" />

        <xs:element name="longitude" type="xs:string" />

       </xs:sequence>

      </xs:complexType>

     </xs:element>

     

    </xs:schema>



    Descriptive IDs Schema

    <?xml version="1.0" encoding="UTF-8"?>

     

    <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

     elementFormDefault="qualified" targetNamespace="urn:fiestaiot:experiment:descriptiveids:xsd:1"

     xmlns:edid="urn:fiestaiot:experiment:descriptiveids:xsd:1">

     

     <xs:element name="ExpDescriptiveIDs">

      <xs:complexType>

       <xs:sequence>

        <xs:element ref="edid:FemoDescriptiveID" maxOccurs="unbounded" />

       </xs:sequence>

      </xs:complexType>

     </xs:element>

     

     <xs:element name="description" type="xs:string" />

     <xs:element name="name" type="xs:string" />

     

     <xs:element name="FismoDescriptiveID">

      <xs:complexType>

       <xs:sequence>

        <xs:element minOccurs="0" ref="edid:description" />

        <xs:element minOccurs="0" ref="edid:name" />

       </xs:sequence>

       <xs:attribute name="id" type="xs:anyURI" />

      </xs:complexType>

     </xs:element>

     

     <xs:element name="FemoDescriptiveID">

      <xs:complexType>

       <xs:sequence>

        <xs:element maxOccurs="1" minOccurs="0" ref="edid:description" />

        <xs:element minOccurs="0" ref="edid:name" />

        <xs:element ref="edid:FismoDescriptiveID" />

       </xs:sequence>

       <xs:attribute name="id" type="xs:anyURI" />

      </xs:complexType>

     </xs:element>

    </xs:schema>

     

     

    2.3 API Usage

    The different exposed services described in the ERM API above are exposed at the following URLs:

    http://[HOST]:[PORT]/experiment.erm/rest/experimentservices/saveUserExperiments

    http://[HOST]:[PORT]/experiment.erm/rest/experimentservices/deleteUserExperiments

    http://[HOST]:[PORT]/experiment.erm/rest/experimentservices/saveUserExperiment

    http://[HOST]:[PORT]/experiment.erm/rest/experimentservices/deleteUserExperiment

    http://[HOST]:[PORT]/experiment.erm/rest/experimentservices/saveExperimentServiceModelObject

    http://[HOST]:[PORT]/experiment.erm/rest/experimentservices/deleteExperimentServiceModelObject

    http://[HOST]:[PORT]/experiment.erm/rest/experimentservices/getALLUserExperiments

    http://[HOST]:[PORT]/experiment.erm/rest/experimentservices/getAllUserExperimentsDescreptions

    http://[HOST]:[PORT]/experiment.erm/rest/experimentservices/getExperimentDescreption

    http://[HOST]:[PORT]/experiment.erm/rest/experimentservices/getExperimentModelObject

    http://[HOST]:[PORT]/experiment.erm/rest/experimentservices/getExperimentServiceModelObject 

    3 IoT-Registry API for advanced experimenters

    In the previous section, we have showed the most straightforward way to define an experiment or application. It goes without saying that novel or non-technical users will feel comfortable with it. Nonetheless, there is another option for advanced experimenters, who will be able to interact directly with the FIESTA-IoT registry.

    his Meta-Directory, heart of the FIESTA-IoT platform, is in charge of managing, storing and serving all the resource descriptions and observations (i.e. data streams) coming from the subjacent testbeds. In order to open it outwards, we have defined a REST-based API, called IoT-Registry, which provides the set of interfaces that enables the access to the information held by the FIESTA-IoT federation of testbeds.

    During the implementation of the IoT-Registry we have tried to follow the CRUD (Create, Read, Update and Delete) approach as much as possible, but in order to provide a more user-friendly interface, some of the functionalities are not fulfilling this philosophy. The REST web-service implemented is accepting and returning RDF documents in various formats, like JSON-LD, N3, RDF/XML, CSV, plain text, n-quads, etc.

    An interactive documentation of this IoT-Registry API can be found in the following link: https://platform.fiesta-iot.eu/iot-registry/docs/api.html

    3.1 Resources

    Resources-related IoT Service Endpoint:

    https://platform.fiesta-iot.eu/iot-registry/api/resources?original_id=boolean&class=string

    original_id: Flag to set whether to provide original or testbed agnostic identifier
    class: Class IRI of the returned entities (filtering)

    Method

    Description

    Request Body

    GET

    List all available entities in the resources triple-store

     

    /resources/{id}

    Method

    Description

    Request Body

    GET

    Retrieve a specific resource description as an RDF document

     

    /resources/{id}/original_id

    original_id: Flag to set whether to include original or testbed agnostic identifier

    Method

    Description

    Request Body

    GET

    Retrieve the resource original identifier assigned by the testbed it belongs to

     

    3.2 Observations

    Observations-relater IoT-Registry:

    https://platform.fiesta-iot.eu/iot-registry/api/observations

    original_id: Flag to set whether to provide original or testbed agnostic identifier
    class: Class IRI of the returned entities (filtering)

    Method

    Description

    Request Body

    GET

    List all available entities in the observations triple-store

     

    https://platform.fiesta-iot.eu/iot-registry/api/observations/{id}

    Method

    Description

    Request Body

    GET

    Retrieve a specific observation as an RDF document

     

    https://platform.fiesta-iot.eu/iot-registry/api/observations/{id}/original_id

    original_id: Flag to set whether to include original or testbed agnostic identifier

    Method

    Description

    Request Body

    GET

    Retrieve the resource original identifier assigned by the testbed it belongs to.

     

    3.3 Endpoints

    One of the advantages behind the usage of a semantic model like the one proposed by the FIESTA-IoT ontology is that everything is connected, thus shaping a huge but single graph. For this, we include, as part of the resource descriptions, an IoT-service endpoint that expose the last observations gathered by a particular “sensing device”.

    Endpoints IoT Registry Endpoint:

    https://platform.fiesta-iot.eu/iot-registry/api/endpoints/{id}

    Method

    Description

    Request Body

    GET

    Get the original endpoint URL

     

    https://platform.fiesta-iot.eu/iot-registry/api/observations/{id}

    Method

    Description

    Request Body

    GET

    Retrieve a specific observation as an RDF document

     

    https://platform.fiesta-iot.eu/iot-registry/api/endpoints/{id}/value

    Method

    Description

    Request Body

    GET

    Get the information from the endpoint

     

    3.4 Queries

    Whereas in the first four points we have covered various features to get data in a more guided way, with the use of SPARQL-based queries we offer the freedom to tailor the request as much as the experimenter wants.

    • Store. This works as a kind of catalogue through which we can offer a number of preconfigured queries to others. At the very same time, everyone is welcome to bring new SPARQL queries to the “store”, by just registering them (through a POST message). This way, non-skilled users could have illustrative examples of how to extract data from the meta-directory and find inspiration to create their own ones.
    • Execute. On the other hand, you can directly execute a query through these endpoints.

    Queries IoT Registry Endpoint:

    https://platform.fiesta-iot.eu/iot-registry/api/queries/store

    Method

    Description

    Request Body

    GET

    List all the queries stored

     

    GET

    Create a new query

    Query document, including SPARQL, name, description, etc. More information in 

    https://platform.fiesta-iot.eu/iot-registry/api/queries/store/{id}

    Method

    Description

    Request Body

    GET

    Retrieve an stored query

     

    PUT

    Update a query

    The new query document, including SPARQL, name, description, etc.

    DELETE

    Delete a stored query

     

    https://platform.fiesta-iot.eu/iot-registry/api/queries/execute/{resources/observations/global}

    Method

    Description

    Request Body

    POST

    Execute a SPARQL query on a specific graph or triple-store.

    (resources for Resource descriptions; observations for measurements; global for the whole meta-repository)

     The SPARQL query.

    /queries/execute/{resources/observations/global}/id

    Method

    Description

    Request Body

    GET

    Execute a stored SPARQL query on a specific graph or triple-store.

    (resources for Resource descriptions; observations for measurements; global for the whole meta-repository)