AW: Decoupling between Link and its mediatype, and inputData/outputData

Dear all,

in my point of view we need 4 resources to fulfill Maxime’s use case:

{
  “interaction”: [
    {
      “@type”: “Property”,
      “link”: [
        { “href”: “http://192.168.0.10/property”, “mediaType”: “application/xml” },
        { “href”: “http://192.168.0.10/property”, “mediaType”: “application/json” },
        { “href”: “http://192.168.0.10/property.xml”, “mediaType”: “application/xml” },
        { “href”: “http://192.168.0.10/property.json”, “mediaType”: “application/json” }
      ]
    }
  ]
  …
}

Since a duplicated resource is provided with different media types the Accept field has to be used at runtime. The question is whether this is practical and can we be more compact.

@Maxime: I’m not sure if I understand the point correctly why you need two dataShema definitions for the same data content of the Property. Actually,  you need only one for defining XML- and JSON- based payload. Also see [1] and [2].

Best regards
Seb

[1] https://www.w3.org/TR/wot-thing-description/#structured-data

[2] https://www.w3.org/TR/wot-thing-description/#mapping-to-xml-schema



Von: Charpenay, Victor [mailto:victor.charpenay@siemens.com]
Gesendet: Montag, 25. September 2017 10:38
An: Dave Raggett; Maxime Lefrançois
Cc: public-wot-wg@w3.org
Betreff: RE: Decoupling between Link and its mediatype, and inputData/outputData

Hi Maxime,

in the situation you are describing, aren’t the three URIs a bit redundant? To access the content of your Property, I assume that a client has to understand HTTP semantics (specificed in RFC 7231, which defines e.g. how to interpret Content-Location). This means that it should be able to perform both a simple GET on the XML or JSON resources (without content negotiation) and a GET with content negotiation on the generic resource. In this sense, declaring all resources would require that your TD redefines the semantics of HTTP content negotiation, somehow.

In my opinion,  you should choose one of the two options (with or without content negotiation), as presented below. Your choice might depend on how likely it is that your servient will support new content types in the future. With the first option, you will have to update your TD every time it occurs.

That said, I also met the case where I wanted to declare required custom HTTP header fields in a TD. I finally decided to use the HTTP RDF vocabulary (http://www.w3.org/2011/http). With respect to content negotiation, if you want to give clients a hint on the media types your servient supports in the TD, you could also use this vocabulary. What do you think?

(By the way, Dave, the first choice you presented has the drawback that non-standard extensions, such as custom HTTP header fields, could not be declared in a TD.)

________________________________
{
  “interaction”: [
    {
      “@type”: “Property”,
      “link”: [
        { “href”: “http://192.168.0.10/property.xml”, “mediaType”: “application/xml” },
        { “href”: “http://192.168.0.10/property.json”, “mediaType”: “application/json” }
      ]
    }
  ]
  …
}
________________________________
{
  “interaction”: [
    {
      “@type”: “Property”,
      “link”: [
        { “href”: “http://192.168.0.10/property”, “mediaType”: “application/*” }
      ]
    }
  ]
  …
}
________________________________

Regards,
Victor

From: Dave Raggett [mailto:dsr@w3.org]
Sent: Freitag, 22. September 2017 19:12
To: Maxime Lefrançois
Cc: public-wot-wg@w3.org<mailto:public-wot-wg@w3.org>
Subject: Re: Decoupling between Link and its mediatype, and inputData/outputData


On 22 Sep 2017, at 14:11, Maxime Lefrançois <maxime.lefrancois@emse.fr<mailto:maxime.lefrancois@emse.fr>> wrote:

Dear all,

The decoupling between Link and its mediatype, and inputData/outputData, makes me having some trouble trying to model the following situation:

Suppose a device exposes the same information in xml or json, using content-negotiation, at http://192.168.0.10/property

- the xml version has a canonical URL http://192.168.0.10/property.xml (see also Content-Location)
- the json version has a canonical URL http://192.168.0.10/property.json


I'd like to model this situation with a single device, a single td:Property, three td:Link, and only two td:DataSchema objects.

How would you suggest to manage this ?

I don’t full understand the question.

The object model for the property should be the same regardless of whether the interaction model is described in JSON, JSON-LD or RDF/XML, e.g. the property could be a integer.

Perhaps you are talking about the case where the messaging protocol for property updates supports multiple data formats. The communications metadata needs to clarify which protocols and data formats can be used.

I see two broad choices:

1. The communications metadata references a standard and provides any additional parameters as needed for using that standard. This assumes drivers that embed knowledge about these standards, e.g. a driver for Apple HomeKit, a driver for Bluetooth, or a driver for OCF.

2. The communications metadata provides a declarative means to express a broad range of possible approaches using well known protocols.  This results in much more complicated thing descriptions, but the premise is that a complex generic driver is worth the extra complexity compared to needing drivers specialised to particular standards. Given the wide variety of possible ways of laying standards on top of core protocols, we are unlikely to provide a fully general solution.

Making our assumptions explicit would increase our chances of success.

Dave Raggett <dsr@w3.org<mailto:dsr@w3.org>> http://www.w3.org/People/Raggett

W3C champion for the Web of things & W3C Data Activity Lead