Re: any chance of that?

Hi-

When it comes to streaming sensor data, the issue (at least as I see it) is
that the "stream" of sensor data needs to be interpretable without having
to have previously received some "set up" information. For example, many
data formats require that you receive header information first; this won't
work for streaming applications because a application might subscribe to
the data stream for a limited period of time and there is no guarantee that
the application would ever receive the header.

So in streaming mode, we need a mechanism to associate the values within
the _stream_ with the relevant metadata that enables those data values to
be interpreted.

This might be achieved in the same way that every `qb:Observation` in an
RDF Data Cube [1] explicitly states which `qb:DataSet` it belongs to. Every
value in a sensor data stream could assert membership of that stream -
either explicitly or through containment within the stream itself. Once you
have identified the stream, applications are able to subsequently find all
the necessary contextual information ...

HTH, apologies if it's a distraction.

Jeremy

[1]: http://www.w3.org/TR/vocab-data-cube/

On Tue, 2 Jun 2015 at 14:55 Alejandro Llaves <allaves@fi.upm.es> wrote:

> Hi Frans,
>
> IMO, the streamable data req. description is a bit vague: "Data should be
> streamable, a consumer should be able to do something meaningful before the
> end of the data message is received. This could be considered a general
> requirement for data on the Web, but it is recorded here because spatial
> data often consist of large chunks of data." - Specially, the part about "a
> consumer should be able to do something meaningful". Yet, I understand that
> this req. addresses the need of an efficient data consumption for big
> (spatial) data chunks. So it makes sense for the Best Practice deliverable.
>
> On the other hand, the dynamic sensor data req. is about representing
> *streaming* (better than *streamable*; I will change it) sensor data that
> may come in near real-time. In this case, the streaming feature is implicit
> in the sensor data, since sensor data is normally produced as a sequence of
> observations, i.e. time series. I don't see any added value of mentioning
> "near real-time", but it doesn't bother either. Bottom line: I would not
> merge both reqs.
>
> Cheers,
> Alejandro
>
>
>
> On 27 May 2015 at 09:32, Frans Knibbe <frans.knibbe@geodan.nl> wrote:
>
>> Hello Payam, Alejandro,
>>
>> Thank you Payam, the top 3 scenarios are much easier to digest than 101
>> use cases. Now we need to see how this use case relates to deliverables and
>> requirements.
>>
>> It seems to me the smart city use cases are mainly about best practices
>> and sensors.
>>
>> An important requirement seems to be linkability
>> <http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#Linkability>.
>> The first scenario even requires real time linkability. For (near) real
>> time sensor data there is the dynamic sensor data
>> <http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#DynamicSensorData>
>> requirement.
>>
>> Could there be requirements in this use case that we have not discovered
>> yet?
>>
>> @Alejandro: the dynamic sensor data
>> <http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#DynamicSensorData> requirement
>> seems to have two components: (near) real time data and streamable data.
>> The streamable part is covered by the streamable data
>> <http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#Streamable>
>> requirement. Shall we change the label to something like '(near) real time
>> data'? Of course, as ever we also need to ask ourselves if the requirements
>> are in scope. The streamable data requirement could be considered in scope
>> because spatial objects can have a high volume. But is there something
>> spatial about real time data access? If there is. I think we should make it
>> clear in the description of the requirement.
>>
>> Regards,
>> Frans
>>
>> 2015-05-27 1:06 GMT+02:00 Payam Barnaghi <payam.barnaghi@gmail.com>:
>>
>>> Hi Kerry, Alejandro and Frans,
>>>
>>> I updated the 101 use-cases and added narratives from the top 3 ranked
>>> scenarios. I can edit and add a few more narratives if you think this needs
>>> to be extended further.
>>>
>>> https://www.w3.org/2015/spatial/wiki/Working_Use_Cases#.22101.22_Smart_City_Use-cases
>>>
>>> Please let me know if you want me add any further information to this
>>> section.
>>>
>>> Thanks,
>>> Payam
>>>
>>>
>>>
>>> On Mon, May 25, 2015 at 12:48 PM, <Kerry.Taylor@csiro.au> wrote:
>>>
>>>>  Summary of 101 use cases before the Wednesday meeting? Otherwise it
>>>> will miss out on the “first public working draft” of the ucr document. If
>>>> you could put it on the wiki, and tell me and use case editors (cc’d) then
>>>>  I think we can use it.
>>>>
>>>> I am keen because I want to make sure that we have a clear IoT  target.
>>>>
>>>>
>>>>
>>>> Kerry
>>>>
>>>>
>>>>
>>>> *Dr Kerry Taylor*
>>>>
>>>> *Principal  Research Scientist*
>>>>
>>>> Digital Productivity, CSIRO
>>>>
>>>> Adjunct Professor, ANU; Principal Fellow, University of  Melbourne;
>>>> Visiting Reader, University of Surrey, UK
>>>>
>>>>  E: Kerry.Taylor@csiro.au or  Kerry.Taylor@acm.org  T: +61 2 6216 7038
>>>> S: kerryleataylor
>>>>
>>>> Post: CSIRO Digital Productivity Flagship, GPO Box 664, Canberra ACT
>>>> 2601, Australia
>>>>
>>>> Street:  Computer Science & Information Technology (Building 108),
>>>> Australian National University, North Road, Acton ACT, Australia
>>>>
>>>> www.csiro.au
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>> --
>> Frans Knibbe
>> Geodan
>> President Kennedylaan 1
>> 1079 MB Amsterdam (NL)
>>
>> T +31 (0)20 - 5711 347
>> E frans.knibbe@geodan.nl
>> www.geodan.nl
>> disclaimer <http://www.geodan.nl/disclaimer>
>>
>>
>
>
> --
> Alejandro Llaves
>
> Ontology Engineering Group (OEG)
>
> Artificial Intelligence Department
>
> Universidad Politécnica de Madrid
>
> Avda. Montepríncipe s/n
>
> Boadilla del Monte, 28660 Madrid, Spain
>
>
> http://www.oeg-upm.net/index.php/phd/325-allaves
>
>
> allaves@fi.upm.es
>