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: Mccool, Michael <michael.mccool@intel.com>
Date: Fri, 6 Apr 2018 03:54:17 +0000
To: "martynas@atomgraph.com" <martynas@atomgraph.com>, "public-wot-wg@w3.org" <public-wot-wg@w3.org>
Message-ID: <94B1DC03AB76B54E8C86625B98F8506A497D8C43@PGSMSX111.gar.corp.intel.com>
All good points.  I’ll leave the others for others to debate, but your second point is interesting to me also.  I’ve been working on an enhanced security metadata proposal that would allow different security constraints to be applied to different resources, but as you point out, in theory ACLs could make some resources (properties) writable by some users and not by others.

However, two points:

1.       The general idea of metadata is that you can find out how to access a device without having to probe it.   This is useful when developing code in advance and/or when an active device is not available.

2.       My understanding of the “writable” flag is that if it were false it would indicate that a property is not writable by anyone, *regardless* of access rights.  This will typically indicate a physical constraint: a temperature sensor is read-only, for instance.  Writing to it is meaningless.

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.   It’s still possible that an ACL could restrict writing to only some users, but might allow reads to another set.  However, if the property is not writable at all (eg if it is actually a physical sensor, or otherwise inherently read-only) then the flag should be set to false.

Michael McCool

From: Martynas Jusevičius [mailto:martynas@atomgraph.com]
Sent: Friday, April 6, 2018 05:19
To: public-wot-wg@w3.org
Subject: A look at WoT specs from Linked Data and AWWW perspective

Hi all,

I can start by admitting that WoT is not my domain. But as a potential implementor of WoT data management systems, I have an interest in the W3C spec.

Coming from the RDF/Linked Data world, I think there is a number of things that should be improved. Below is what I observed during the first reading.

5.2.1 Thing

"base" is not a domain vocabulary property, it is a feature of media types that support relative URIs, such as Turtle, JSON-LD etc., where @base is the syntax for it.

The concept of "base URI" does not belong in the WoT domain nor its vocabulary, it is a matter of orthogonal specification(s).

5.2.3 Property

I wonder how can "writability" of any property on the web be a predefined constant? What happens if agents with different access rights are interacting with it -- is it not feasible that the writability should depend on the ACL, meaning it can change over time and depending on the request?

Again, it looks like the WoT spec is trying to incorporate bits of orthogonal specifications, in case HTTP and probably W3C ACL.

A property, like any Web resource, can be considered writable if an agent can perform PUT or DELETE on its URI and succeed (200 OK). Otherwise, 401 or 403 should be returned. If the writability needs to be probed before making the actual request, HTTP OPTIONS can be used:

5.2.6 DataSchema

JSON Schema is referenced here, yet it is not a W3C standard, nor any kind of standard, as far as I know. Why is it considered safe to be used for formal definitions? Why not use an actual W3C standard such as SHACL or SPARQL? https://www.w3.org/TR/shacl/

JSON is only one of the syntaxes -- RDF is the model, and constraints should be based on it.

Martynas Jusevicius

Received on Friday, 6 April 2018 03:54:50 UTC

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