Skip to content

X GSN Use

Jump to bottom
mdii edited this page Sep 16, 2014 · 26 revisions

System requirements

X-GSN requires Java JDK 1.6 to run. If you have a higher version of Java, there is no problem as the binary version of X-GSN is already compiled against the right version.

Running GSN

X-GSN can be controlled from the command line with the commands provided hereafter:

gsn-start	Starts the X-GSN server
gsn-stop	Stops the X-GSN server
lsm-register	Registers sensor metadata to LSM

The X-GSN web server will be running and listening on default port 22001. You can see it running by browsing the page at: http://localhost:22001

Semantic annotation of sensor data

Configuring GSN for integration with LSM

In order to connect GSN with LSM, you need to edit the file conf/lsm_config.properties. There, you need to specify user credentials and LSM schema to use. See following sample:

metaGraph=http://lsm.deri.ie/OpenIoT/demo/sensormeta#
dataGraph=http://lsm.deri.ie/OpenIoT/demo/sensordata#
lsm.server=http://localhost:8080/lsm-light.server/

Creating virtual sensor metadata

In order to associate metadata with a virtual sensor, you need to create a metadata file that will be associated with the virtual sensor. The metadata file has to be located in the same folder as the virtual sensor and needs to have the same name as the virtual sensor name but with the extension (.metadata). For example, a virtual sensor named sensor1.xml will have an associated metadata file named sensor1.metadata. Sample virtual sensors with associated metadata can be found in (virtual-sensors/samples/LSM).

Sample metadata file

sensorName=opensense_1
source="http://planetdata.epfl.ch:22002/gsn?REQUEST=113&name=opensense_1"
author=opensense
sensorType=lausanne
sourceType=lausanne
information=Air Quality Sensors from Lausanne station 1
sensorID="http://lsm.deri.ie/resource/1150805994572850"
feature="http://lsm.deri.ie/OpenIoT/opensensefeature"
fields="humidity,temperature"
field.humidity.propertyName="http://lsm.deri.ie/OpenIoT/Humidity"
field.humidity.unit=Percent
field.temperature.propertyName="http://lsm.deri.ie/OpenIoT/Temperature"
field.temperature.unit=C

The metadata file contains metadata about the virtual sensor. We describe some of the main fields:

sensorName: name of the virtual sensor

fields: comma separated list of fields of this sensor

field.FIELD_NAME.propertyName: URI of the FIELD_NAME property, e.g. if field si humidity, http://lsm.deri.ie/OpenIoT/Humidity

field.FIELD_NAME.unit; Unit of the FIELD_NAME, e.g. Celsius

feature: Feature of interest URI: e.g. "http://lsm.deri.ie/OpenIoT/opensensefeature"

Notice that urls and strings with special characters must be double quoted.

Registering sensors to LSM

Sensors can be registered to LSM by calling the script lsm-register.sh (from Linux/Mac) or lsm-register.bat (from windows). This script takes as argument the name of metadata file.

Syntax:

./lsm-register.sh <metadata_filename>  
lsm-register.bat <metadata_filename>

Example:

./lsm-register.sh virtual-sensors/opensense1.metadata
lsm-register.bat virtual-sensors\opensense1.metadata

Make sure the data and metadata graphs defined in the metadata file exist in LSM.

To verify if the sensor has been registered in LSM, go to the Virtuoso SPARQL console: http://localhost:8890/conductor/

GO to the SPARQL tab and issue the query

select * where {?s ?p ?o}

With the corresponding metadata graph (e.g.):

http://lsm.deri.ie/OpenIoT/sensormeta#

Registering Sensor Data through an RDF file

Alternatively to a .properties file, you can provide an RDF metadata description for your virtual sensor. Currently we support an RDF in standard Turtle format (http://www.w3.org/TR/turtle/). For example the following RDF metadata:

@prefix : <http://sensordb.csiro.au/id/> .
@prefix rdf:  <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix DUL:  <http://www.loa-cnr.it/ontologies/DUL.owl#> .
@prefix rr:   <http://www.w3.org/ns/r2rml#> .
@prefix ssn:  <http://purl.oclc.org/NET/ssnx/ssn#> .
@prefix qu:   <http://purl.oclc.org/NET/ssnx/qu/qu#> .
@prefix unit: <http://purl.oclc.org/NET/ssnx/qu/unit#> .
@prefix aws:  <http://purl.oclc.org/NET/ssnx/meteo/aws#> .
@prefix cf-property:<http://purl.oclc.org/NET/ssnx/cf/cf-property#> .
@prefix cf-feature: <http://purl.oclc.org/NET/ssnx/cf/cf-feature#> .
@prefix prov: <http://purl.org/net/provenance/ns#> .
@prefix phenonet: <http://sensordb.csiro.au/ontology/phenonet#> .
@prefix wgs84: <http://www.w3.org/2003/01/geo/wgs84_pos#> .
@prefix lgd: <http://linkedgeodata.org/property/> .
@prefix lsm: <http://lsm.deri.ie/ont/lsm.owl#> .
@base <http://sensordb.csiro.au/id/> .

<sensor/5010> rdf:type aws:CapacitiveBead,ssn:Sensor;
              rdfs:label "Sensor 5010";
              ssn:observes aws:air_temperature ;
              phenonet:hasSerialNumber <sensor/5010/serial/serial2> ;
              ssn:onPlatform <site/narrabri/Pweather> ;
              ssn:ofFeature <site/narrabri/sf/sf_narrabri> ;
              ssn:hasMeasurementProperty <sensor/5010/accuracy/acc_1> ;
              prov:PerformedBy "SensorSource";
              DUL:hasLocation <place/location1>;
              lsm:hasSensorType <sensorType1>;
              lsm:hasSourceType "SourceType".              	
<sensorType1> rdfs:label "TypeName".
<place/location1> rdf:type DUL:Place;
                  wgs84:lat 52.3;
                  wgs84:long 98.2;
                  lsm:is_in_city <city1>;
                  lgd:is_in_province <prov1>;
                  lgd:is_in_country <country1>;
                  lgd:is_in_continent <conti>.
<site/narrabri/Pweather>  rdf:type ssn:Platform ;
                          ssn:inDeployment <site/narrabri/deployment/2013> .
<site/narrabri/sf/sf_narrabri> rdf:type phenonet:SamplingFeature; 
                               ssn:ofFeature cf-feature:atmosphere_air .
aws:air_temperature qu:unit phenonet:degreeCelsius;
                    rr:columnName "temperature" .
<city1> rdfs:label  "cityname".
<prov1> rdfs:label "province".
<country1> rdfs:label "country".
<conti> rdfs:label "conti".

In this case to execute the sensor registration you may proceed as follows (adding the -rdf parameter):

./lsm-register.sh virtual-sensors/opensense1.ttl -rdf

Registering sensor data through a REST Service

Instead of using the ``lsm_register` command line tool, you can register the sensor metadata with the following POST request, passing the file contents as vody of the request:

http://GSNSERVER:22001/vs/vsensor/VSENSOR_NAME/register

You can use any REST or HTTP library to execute this request in your favorite programming language. Or if you want to test it using the curl client:

 curl -v http://localhost:22001/vs/vsensor/sens123/register -X POST --data-binary @virtual-sensors/LSM/opensense_1.metadata

There is also a service to post RDF data:

 http://GSNSERVER:22001/vs/vsensor/VSENSOR_NAME/registerRdf

And a service to create a GSN virtual sensor (the typical GSN xml file that has the wrapper information):

 http://GSNSERVER:22001/vs/vsensor/VSENSOR_NAME/create

This allows to remotely install a virtual sensor in XGSN, and register the metadata to LSM.

Pushing data to LSM

In order to push data to LSM, the LSMExporter processing class needs to be used. This class can be found in package (org/openiot/gsn/vsensor). LSMExporter loads metadata from the metadata file and uses it to push annotated data to LSM whenever new data arrives from connected wrappers.

Security Configuration

Service

In order for the XGSN to be able to publish data on LSM, a REST service must be created for it. When the OpenIoT graph is initialized, a REST service is created for the XGSN with the following key and secret as defined in the openiot.properties:

  • security.initialize.xgsn.key=xgsn
  • security.initialize.xgsn.secret=xgsn.secret

The key and secret of the service must correspond to the key and secret specified in the configuration file conf/rest-client.ini.

Roles

The role "xgsn-role" is created upon initialization of the OpenIoT graph for the XGSN service on the LSM service. The permission "lsm-light.server:all" is assigned to this role.

User

Upon initialization of the OpenIoT graph, a default user is created for the XGSN as defined in the openiot.properties:

  • security.initialize.xgsn.username=gsnuser
  • security.initialize.xgsn.password=gsnpass

The username and password of the user assigned to the XGSN module is configured in application.conf file using the username and password properties.

Configuration File

The security configuration is read from conf/rest-client.ini with the following default content:

[main]

casOauthClient=org.openiot.security.client.rest.CasOAuthWrapperClientRest
casOauthClient.casOAuthUrl=https://localhost:8443/openiot-cas/oauth2.0
casOauthClient.casOAuthRestUrl=https://localhost:8443/openiot-cas/openiot1/tickets
casOauthClient.key=xgsn
casOauthClient.secret=xgsn.secret

# Sets the callbackUrl for each client in the list
clients = org.pac4j.core.client.Clients
clients.callbackUrl = http://localhost:8080/sth/callback
clients.clientsList = $casOauthClient

clientsRealm = org.openiot.security.client.rest.CasOAuthClientRealmRest
clientsRealm.permissionsURL = https://localhost:8443/openiot-cas/oauth2.0/permissions
clientsRealm.defaultRoles = ROLE_USER
clientsRealm.clients = $clients

Specify the location of the openiot-cas server where needed (e.g. https://localhost:8443/openiot-cas).

footer
Clone this wiki locally