W3C home > Mailing lists > Public > public-wot-ig@w3.org > June 2016

AW: Thing Description for existing data sources

From: Kovatsch, Matthias <matthias.kovatsch@siemens.com>
Date: Fri, 10 Jun 2016 17:45:19 +0000
To: Dave Raggett <dsr@w3.org>, "Charpenay, Victor" <victor.charpenay@siemens.com>
CC: "public-web-of-things@w3.org" <public-web-of-things@w3.org>, "Public Web of Things IG" <public-wot-ig@w3.org>
Message-ID: <4EBB3DDD0FBF694CA2A87838DF129B3C017D16C7@DEFTHW99EL4MSX.ww902.siemens.net>
When you say a URI, what does that mean?  In a data model, it presumably just means an RDF URI, or are you thinking in protocol terms?  If each measurement has its own URI, I presume this involves a time stamp or sequence number. What kinds of streams are there in the BIG-IoT project?  For contrast, I am working on a demo with 250 measurements per second with a 6 axis accelerometer.  I don’t yet see a need for a URI for each measurement, so perhaps your environment requires additional assumptions, if so could you please explain what they are?

This is exactly the event vs state change discussion. It is probably not useful to ensure persistence of every single reading. When your network becomes congested, you might even want to drop some samples to adapt the data rate. Also, you do not care if samples are lost sporadically. Thus, you are describing something that is closer to the state change kind of notification.

If each measurement is a seismic event, you probably do not want to lose it. It might contain a lot of data and you probably might want to access it on several occasions. This something should be a event notification that may not be lost, and hence queued until it was successfully transferred to the subscriber(s).

This is why I propose to have a type system that is independent of the schema language.

We need all together: types, schema, and semantic annotations.

Another dimension to the discussion is whether to stick to existing approaches, even when they are awkward for the use cases in hand, or to come up with new leaner approaches. This will depend on the community you are targeting.

All this explains why I feed we need to explore a range of approaches and to analyse their strengths and weaknesses from a technical perspective and from a social perspective for specific developer communities.

I think we need something completely new. It would help to properly collect the requirements, identify the closest matches and elaborate from there.

Received on Friday, 10 June 2016 17:45:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:27:04 UTC