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

Hi,

I think a lot of what we see is an artifact of the protocol binding, where an instance of a TD contains explicit references in the context of the target protocol. These show up in base and dataSchema, as well as within the "form" construct.

Specifics in-line below:

> On Apr 5, 2018, at 1:18 PM, Martynas Jusevičius <martynas@atomgraph.com> wrote:
> 
> 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
> https://www.w3.org/TR/wot-thing-description/#classes <https://www.w3.org/TR/wot-thing-description/#classes>
> 
> "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).
> 
base URI is probably best thought of as a default in the protocol binding, that is a property of the target protocol being mapped to which enables short and relative URIs to be used in the form element. 
> 
> 5.2.3 Property
> https://www.w3.org/TR/wot-thing-description/#interactionpattern <https://www.w3.org/TR/wot-thing-description/#interactionpattern>
> 
> 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:
> https://tools.ietf.org/html/rfc7231#section-4.3.7 <https://tools.ietf.org/html/rfc7231#section-4.3.7>
> 
I rather agree with this. We intend to say the inverse of "read-only" which is to say that variables that are not read-only are (potentially) writeable. I think it is better to say "read-only", but better still to use the options header. Unfortunately, only http has an options header, so we do this as a sort of convenience for the client (IMO) to help with other protocols. Some folks also like to make read-only part of the data definition or schema language and carry this through. I am somewhat ambivalent to this approach, which seems to be more of a carry-over from programming languages and not necessarily something we want to build into web architecture. 
> 
> 5.2.6 DataSchema
> https://www.w3.org/TR/wot-thing-description/#dataschema <https://www.w3.org/TR/wot-thing-description/#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/ <https://www.w3.org/TR/shacl/>
> 
> JSON is only one of the syntaxes -- RDF is the model, and constraints should be based on it.

Here is another exposure of the protocol binding. We considered shape constraints some time ago, (and also considered xsd number types, and schema.org <http://schema.org/> PropertyValueConstraint...), and I believe selected the json-schema-like approach seemed to offer the best compromise in terms of simplicity and also sensible number type constraints. Add to that the common JSON and CBOR payloads it is currently being used for in RAML and OpenAPI, as well as general map+array descriptive capability. It seems good to aligh the payload constraint language with the common payloads. To tie it all together, we build an RDF model of the schema language so the TD itself can be a single graph in a triplestore.

I would like to continue to look at shape constraints as a better long term solution, particularly around how we can build some next generation tools for domain experts to use that can ease the learning curve.
> 
> 
> Martynas Jusevicius
> atomgraph.com <http://atomgraph.com/>
>