RE: I am interested in Semantics and Sensors.

Hello Frank

We support (1) and (2) directly, depending on type of sensor and underlying architecture. However, we don't have a triple store. We generate triples (or RDF) on demand.

Triggering is done through other means (web 2.0 APIs or other mechanisms).

Sincerely,
Peter Waher


From: Frank Haferkorn [mailto:F.Haferkorn@RST-Automation.de]
Sent: den 27 februari 2013 11:30
To: Peter Waher; Simon.Cox@csiro.au; michaeljohnkoster@gmail.com
Cc: public-ssn-cg@w3.org; Michael.Compton@csiro.au
Subject: AW: I am interested in Semantics and Sensors.

Dear Peter Waher,
Dear Simon Cox,
Dear Michael Koster,
Dear Michael Compton,

Peter wrote:
>It's clear from these, that the Accept header should control the desired output to the client.


What I am interested in, is the design of the solution.
I am not keen on the format of the dataflow.
Indeed I want to learn how the data flow is triggered/pushed or polled:


1.)    Does each sensor change it's semantic representation (in a Triplestore)
In case a new sensor value is available by its "own initiative".                               (pushing)

2.)    Or do you have a central SW-entity reading the data actively (each minute/quarter of an hour)
And alters the semantic representation centrally                                                      (polling)

3.)    Or are is Semantic Web information altered each time

a request to that sensor is started.                                                                               (triggering)

Sincerely,
Frank Haferkorn


-----------------------------------------------------------------------------
RST Industrie Automation GmbH * Carl-Zeiss-Str. 51, D-85521 Ottobrunn
Tel. +49-89-9616018-20 * Fax +49-89-9616018-10 * http://www.rst-automation.de

Geschäftsführer: Dipl.-Ing.(FH) Robert Schachner
Amtsgericht München: HRB 103 626 * ID-Nr. DE 811 466 035
----------------------------------------------------------------------------

Von: Peter Waher [mailto:Peter.Waher@clayster.com]
Gesendet: Mittwoch, 27. Februar 2013 15:08
An: Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au>; michaeljohnkoster@gmail.com<mailto:michaeljohnkoster@gmail.com>
Cc: Frank Haferkorn; public-ssn-cg@w3.org<mailto:public-ssn-cg@w3.org>
Betreff: RE: I am interested in Semantics and Sensors.

Hello

We follow the w3c recommendations on this topic. It's clear from these, that the Accept header should control the desired output to the client. There are various formats recommended by W3C. From semantic resources the most common might be RDF/XML or Turtle (even though text and HTML representations might be useful if a human user is investigating the resource). For SPARQL endpoints there are more options, also depending on the query. It's up to implementers to follow these recommendations. The formats you mention are not in these recommendations.

Sincerely,
Peter Waher

From: Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au> [mailto:Simon.Cox@csiro.au]
Sent: den 27 februari 2013 03:56
To: michaeljohnkoster@gmail.com<mailto:michaeljohnkoster@gmail.com>; Peter Waher
Cc: F.Haferkorn@RST-Automation.de<mailto:F.Haferkorn@RST-Automation.de>; public-ssn-cg@w3.org<mailto:public-ssn-cg@w3.org>
Subject: RE: I am interested in Semantics and Sensors.

Or a netCDF file, or a SQLite file, or GeoTIFF or PNG or ...
Keep it in RDF if you need to or plan to do RDF operations on the data (primarily inferencing).
But if not, then RDF is probably a clumsy and expensive way to handle 'raw' data.

Simon Cox | Research Scientist
CSIRO Land and Water
PO Box 56, Highett Vic 3190, Australia
Tel +61 3 9252 6342<tel:%2B61%203%209252%206342> | Mob +61 403 302 672<tel:%2B61%20403%20302%20672>
simon.cox@csiro.au<mailto:simon.cox@csiro.au> | http://csiro.au/people/Simon.Cox<http://www.csiro.au/people/Simon.Cox>

________________________________
From: Michael Koster [michaeljohnkoster@gmail.com]
Sent: Wednesday, 27 February 2013 2:29 AM
To: Peter Waher
Cc: Frank Haferkorn; public-ssn-cg@w3.org<mailto:public-ssn-cg@w3.org>
Subject: Re: I am interested in Semantics and Sensors.
Hello Peter,

Do you store the sensor data values in RDF or do you point to a JSON or XML object?

Thanks,

Michael

On Feb 26, 2013, at 6:55 AM, Peter Waher <Peter.Waher@clayster.com<mailto:Peter.Waher@clayster.com>> wrote:


Hello Frank

In our system (running on servers or plug computers, gateways, etc.), semantic data for all connected sensors is generated on the fly (on demand). It has a built in SPARQL engine which can process a variety of RDF triple sources. One such type of triple source is an on demand converter of sensor information to semantic information. As we control the SPARQL engine ourselves, we don't have the need to create a huge triple store for all semantic data necessary to describe the sensor network.

Sincerely,
Peter Waher

From: Frank Haferkorn [mailto:F.Haferkorn@RST-Automation.de<http://RST-Automation.de>]
Sent: den 26 februari 2013 07:16
To: public-ssn-cg@w3.org<mailto:public-ssn-cg@w3.org>
Cc: Peter Waher
Subject: AW: I am interested in Semantics and Sensors.

Dear SSN team,

I was able to browse

http://www.w3.org/2005/Incubator/ssn/ssnx/ssn

and got an impression of the SSN ontology.
I learned about the description of sensor data and other interesting items like observation etc. .

But I still have a big Question:
HOW IS THE REAL ACCESS of the Sensor's Data implemented.
In my Eyes there are only three possible ways:
*         Pushing - the sensor is updating the related semantics itself,
*         Polling - there is some software entity that is polling the and creating the semantic data from the sensor's output?
*         Triggering - The semantic data is generated on the fly at the moment of the request for the data.

Which option is used in real SSN systems?

Yours,
  Frank Haferkorn


-----------------------------------------------------------------------------
RST Industrie Automation GmbH * Carl-Zeiss-Str. 51, D-85521 Ottobrunn
Tel. +49-89-9616018-20 * Fax +49-89-9616018-10 * http://www.rst-automation.de

Geschäftsführer: Dipl.-Ing.(FH) Robert Schachner
Amtsgericht München: HRB 103 626 * ID-Nr. DE 811 466 035
----------------------------------------------------------------------------