W3C home > Mailing lists > Public > public-wot-wg@w3.org > April 2018

RE: A look at WoT specs from Linked Data and AWWW perspective

From: Kjetil Kjernsmo <kjetil@kjernsmo.net>
Date: Mon, 23 Apr 2018 22:43:30 +0200
To: public-wot-wg@w3.org
Message-ID: <4999336.JQoYLen2MO@owl>
Dear all,

I hope you don't mind me jumping in here a bit:

Michael McCool wrote:
> So, if a property is *potentially* writable, with the right access 
> rights, it should be marked as writable, and (with my proposed security 
> metadata) the metadata would indicate what authentication methods should 
> be used to access the resource. 

This is part of the braindump I've made at 

My idea was that any potentially writeable (information) resource would 
have a predicate that point towards a resource that would challenge the 
client to authenticate, check what the client is authorized to do, and then 
provide near natural language sentences in the form of triples that tells 
the details. 

Say, for example that you have a lamp, described as
</my/livingroom/lamp> rdfs:label "Lamps in my living room"@en .
</my/livingroom/lamp/data> rdfs:label "Data about them"@en ;
  hm:toEditGoTo </my/livingroom/lamp/controls> .

The hm:toEditGoTo predicate is what is there whenever there is a potential 
for a write. The agent will then dereference the resource at </my/
livingroom/lamp/controls>, be challenged to authenticate, and then have a 
triple e.g.
</my/livingroom/lamp/data> hm:canBe hm:replaced .

...meaning, the client has been authorized to replace the data about the 
lamp. Those are the primitives.

The next step would be to apply TD, SHACL, or similar to say that the 
client may only adjust the brightness, and then, that can be exposed to the 
client as a triple 
</my/livingroom/lamp/data> hm:canBe hma:brightnessAdjusted .
...instead of the hm:replaced. Not sure how that would work in practice, 
but that was the idea, that I thought I'd share in case someone finds it 


Received on Monday, 23 April 2018 20:44:11 UTC

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