AW: Some comments on editor's drafts

Hi Kjetil,

Thanks for your feedback and good luck for building your own smart house ;-)

My personal opinion w.r.t. to

> 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.

is as follows.

The plan is to create a dedicated specification for 'Web of Things (WoT) Thing Description' [1].

Having said that, I think it makes perfect sense to keep the afore mentioned specification crisp while the Current Practices document [2] may contain lots of examples (similar to what people often call a Primer).

The challenge is to keep both documents in sync though!

Does that make sense to everybody?

Thanks,

--Daniel

[1] https://github.com/w3c/wot-thing-description
[2] http://w3c.github.io/wot/current-practices/wot-practices.html







________________________________
Von: Kjetil Kjernsmo [kjetil@kjernsmo.net]
Gesendet: Montag, 13. März 2017 15:09
An: public-wot-wg@w3.org
Betreff: Some comments on editor's drafts


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