- From: Peter Waher <Peter.Waher@clayster.com>
- Date: Wed, 27 Feb 2013 14:07:47 +0000
- To: "Simon.Cox@csiro.au" <Simon.Cox@csiro.au>, "michaeljohnkoster@gmail.com" <michaeljohnkoster@gmail.com>
- CC: "F.Haferkorn@RST-Automation.de" <F.Haferkorn@RST-Automation.de>, "public-ssn-cg@w3.org" <public-ssn-cg@w3.org>
- Message-ID: <1693EFE1FD641C42A0D542FCBC732DE698E4BF54@EX3.YODA.UTOPIA.LOCAL>
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] Sent: den 27 februari 2013 03:56 To: michaeljohnkoster@gmail.com; Peter Waher Cc: F.Haferkorn@RST-Automation.de; 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 ----------------------------------------------------------------------------
Received on Wednesday, 27 February 2013 14:08:26 UTC