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

A look at WoT specs from Linked Data and AWWW perspective

From: Martynas Jusevičius <martynas@atomgraph.com>
Date: Thu, 5 Apr 2018 22:18:45 +0200
Message-ID: <CAE35Vmy0+8Ho-dvK=ff=Tux2QHrVNAN0NZPXRpM+e5hOhqo1Jw@mail.gmail.com>
To: public-wot-wg@w3.org
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

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

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 Thursday, 5 April 2018 20:19:19 UTC

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