Revising the 'form' vocabulary?

[mkovatsc]

w3c/wot-thing-description#88 raised questions about the terms in our vocabulary and raised one issue:

• href takes the target URI. Usually it is used for (hyper-)references. In HTML, the target resource of a form goes into the action attribute.

  • action could be used.
  • This aligns with the HTML vocabulary, but is not very expressive. Also, I see the conflict with Actions; going back to read-only Properties and write through an Action is one option; actually doing something new and catering for writeable and observable Properties another.

• mediaType takes the media type for the serialization. It assumes the same media type for requests and responses. In HTML, the field for the request payload media type is enctype (with a small enum for values). accept was deferred down to the input element (for file uploads together with enctype multipart/form-data) and is now deprecated for HTML forms. For WoT, accept is a proposed option for the request payload schema.

  • encType could be used for request payload media type.
  • mediaType (as type is overloaded) for resonse/notification/event payload media type (use case would be an Action that consumes a different media type than it returns, e.g., to convert payloads for a constrained Thing.
  • This aligns with the HTML vocabulary, but is not very expressive :/

• *:method is binding-specific.

  • method could be an overarching term that can accept values from different vocabularies such as http:method or coap:methodCode
  • @vcharpeneay Would this work for the ontology behind?

• rel semantically identifies the form. This is not supported in the human-centric HTML forms. The closest match would be name.

  • rel for forms would be an actual improvement needed for a Web of Things, so that machines can understand their meaning.

[mkovatsc]

Another change could be to change the name of form to binding to make the extension point clear. (It also avoids the argument if forms are forms or complex links.)

[mkovatsc]

@vcharpenay Could you comment how far a common method term is possible?

[vcharpenay]

• *:method is binding-specific.
  • method could be an overarching term that can accept values from different vocabularies such as http:method or coap:methodCode

A CoAP method code is a byte while an HTTP method is a string token, so they must be individually defined, with proper range. However, it should be possible to define something like:

{
  ?prop td:form ?httpBinding ; td:form ?coapBinding .
  ?httpBinding http:method "GET"^^xsd:string
}
=>
{
  ?coapBinding coap:methodCode "001"^^xsd:byte
}

to avoid redundant definitions. It would roughly correspond to translating RFC8075 into RDF.

But, to me, it is better to always explicitly state that an interaction supports two bindings (HTTP and CoAP), which here corresponds to ?prop td:form ?httpBinding ; td:form ?coapBinding. There would then be no need for a generic method property.

[mkovatsc]

Some update after Prage:

• href: We also need forms for Properties (as they als might need metadata for custom headers/options etc.), so href will stay href for the target URI
• mediaType: Is used for the media types served by the target. We still need another term for defining the supported request body media type(s), when they differ from the response body media types.
• *:method: Okay, I am happy with @vcharpenay 's answer. Yet we need to look into "well-known" prefixes, which is also a topic for domain-specific vocabulary.
• rel: Let's use rel for form relation types.

[mkovatsc]

Consensus for the remaining terms hangs on w3c/wot-thing-description#179
A new issue came up around media type, which is not expressive enough, as no parameters can be defined. Opening new issue to introduce contenttype.
Closing this.