W3C home > Mailing lists > Public > public-wot-wg@w3.org > March 2017

Some comments on editor's drafts

From: Kjetil Kjernsmo <kjetil@kjernsmo.net>
Date: Mon, 13 Mar 2017 15:09:20 +0100
To: public-wot-wg@w3.org
Message-ID: <2159788.sbvFQkGcEc@owl>
Hi all, 

I have just started reading through the editor's drafts, and I'm finding the direction you're taking very 
interesting! 

I have a few comments that I hope will be useful in this very early stage, but first, just to present myself 
very briefly: I'm a semwebber who has been around the community for a long time, working mainly on 
decentralisation, including SPARQL and hypermedia ideas. 

For now, my interest is the stuff I'm building for my own house. That is, I'm living the examples you provide 
:-) My use cases are as simple as that, right now, I'm connecting a long chain of temperature sensors to an 
Arduino Uno microcontroller, with the intention of logging the temperature outside, in every room and on 
several points in the heating system to some PC hardware that lives in my basement. Later, I hope to use 
that data to create a bayesian forecasting-based heating control system. Moreover, I have two Arduinos 
controlling LED lighting in my house. For broad developer adoption, I could be your guinea pig. :-)

So, these are my comments:
The documents now solicit comments to the members-only list. I would assume it is more common and 
more appropriate to use this list for that purpose?

The Thing Description document is heavy on examples (I like that), but has the side effect of making it 
harder to spot the normative content. I would think that makes it somewhat harder on implementators. 

And on the other hand, I can't make out the whole chain from my microcontroller and all the way to RDF 
data that I can work on. I suppose that is not necessarily something that belong in the normative 
specification of TD, but that points out a possible reorganisation, i.e. have a "primer" document. 

That could enable you to be terser on the examples in the normative document, and yet show how the 
specs belong in a bigger picture. 

So, for my Arduino example, say that I want to read the temperature off of a specific sensor. I would 
probably have a TD that lives on the PC hardware that does the data processing, and the client parses the 
TD, and so it knows what URI it should GET to find the temperature. Through JSON Schema, if I understand 
it correctly, it should also know how the returned data will look. But then, since I have semantic 
annotations, I want to go from there to an RDF graph, and that's not something I am able to read from the 
current spec... :-) I would think that should be spelled out somehow? The TD Semantic Annotations + data 
should be sufficient to create an RDF graph, shouldn't it? 

Now, the next thing that I might want to do is GET the readout from all temperature sensors on the 
Arduino. I suppose a list of Property interaction property types would be needed for that? Perhaps a 
Collection type?  

There's a discovery section in the TD spec, but I'm missing an explicit link. I'd like to see an RFC 5988 typed 
link, which I could send with every response from the Arduino. I could put that on the flash, and that would 
be almost as good as having the TD on the Arduino :-)

Cheers,

Kjetil
Received on Monday, 13 March 2017 14:10:32 UTC

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