- From: Dave Raggett <dsr@w3.org>
- Date: Wed, 27 Sep 2017 16:33:45 +0100
- To: Maxime Lefrançois <maxime.lefrancois@emse.fr>
- Cc: "public-wot-wg@w3.org" <public-wot-wg@w3.org>
- Message-Id: <576C62A4-56CA-4493-A245-114B928658E5@w3.org>
Thanks for working this through, but to my eyes it looks hugely more complicated than is necessary, reminding me of how WebServices gave way to simple use of JSON over HTTP. If we persist with this level of complexity, a similar fate is likely for the Web of things.
I am happy to work with you directly on how a simpler approach can account for the use case if you can provide me with the details for the use case. I am considering the scenario where there is an application server that acts as a gateway for devices that support the GreenButton or Haystack profiles. An application would hide the details of these profiles and expose a simpler abstraction as a thing for consumption by other applications. The thing description now only needs to describe the thing properties and not how they are implemented behind the scenes via the GreenButton or Haystack profiles.
Applications could be written to directly interface to the GreenButton or Haystack profiles, just as you can write apps that directly communicate with devices over Bluetooth or Zigbee. However, the Web of Things offers the promise of simplifying application development and making it much easier to create applications that combine different IoT devices and other sources of information. This is analogous to the ease of writing simple web apps in HTML and JavaScript versus native Windows applications in C++.
Best regards,
Dave
> On 27 Sep 2017, at 15:56, Maxime Lefrançois <maxime.lefrancois@emse.fr> wrote:
>
> Dear all,
>
> Thank you for your detailed answers and sorry for the late reply.
> Before creating a github issue, please find below some more details, and answers to some of your comments/questions
>
> The way the TD ontology is currently modeled, an interaction pattern can be linked to zero or more Links (specifying a URI and a mediatype), some input DataSchema and some output DataSchema.
>
> As I understand from your replies, one may define multiple links for accessing the same td:Property, each link having one or more mediatype associated to it.
>
> I like Victor's proposal and Sebastian's second proposal. In terms of triples, this would look like:
>
> [] a wot:Property ;
> wot:link [ td:isAccessibleThrough <http://192.168.0.10/property <http://192.168.0.10/property>> ; ## is it td:href (spec) or td:isAccessibleThrough (jsonld context) ??
> td:hasMediaType "application/json" , "application/xml" ] , ## is it td:mediaType (spec) or td:hasMediaType (jsonld context) ??
> [ td:isAccessibleThrough <http://192.168.0.10/property.json <http://192.168.0.10/property.json>> ;
> td:hasMediaType "application/json" ] ,
> [ td:isAccessibleThrough <http://192.168.0.10/property.xml <http://192.168.0.10/property.xml>> ;
> td:hasMediaType "application/xml" ] .
>
> Then from Dave, I understand that it is assumed there exists only one DataModel for the output:
> > 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.
>
> Here I must admit I thought that there would be two different DataModels, describing the output in JSON (a JSON Schema), and in XML (a XML Schema).
>
> 1. If there exists only one DataModel for every media type, does it mean we are to define mappings from a "WoT DataModel spec" to every possible data validation formalism, including JSON Schema, XML Schema, ShEx, SHACL, SPARQL ASK queries, etc. ? I see limitations in that:
> - the WoT DataModel spec will never fit all the expressivity of the union of these formalisms. We may want to be agnostic of the formalism that is used
> - legacy devices may not be able to be made compatible with this WoT DataModel, because they have their own data syntax already implemented, and potentially different ways to represent a dummy integer.
> - we cannot define mappings for those validation formalisms that do not exist yet.
>
> For point 1, I would rather encourage us to use a simple URI for the DataModel, and say: The User Agent must look up this URI and it should retrieve a representation of the DataModel (a JSON Schema, a XML Schema, or whatever)
>
> 2. We may want to account for cases where the output of an interaction is available in a different format as the input. --> the media type should be associated with the input/output instead of the Link.
>
> 3. An "input" for an interaction pattern is a typed octet stream the user agent sends to the device. This octet stream may be typed with a media type, but not only. It may also be typed with a Language, an Encoding, a Charset, or even an application profile as will be defined by the W3C Dataset Exchange Working Group [1]. --> I would recommend to have a more general concept td:OctetStreamType or something, that itself is linked to a media type (property td:hasMediaType), and potentially a language (property td:hasLanguage), a Charset (property td:hasCharset), an Encoding (property td:hasEncoding), an application profile (property td:hasApplicationProfile).
>
> I don't think that the DataModel of an interaction pattern input can be considered unique if we take into account device that are able to manage different application profiles.
>
>
> As a conclusion, I would like to see if we can agree on the following statements:
>
>
> 1. A Thing offers one or more Interaction, described by patterns. (no change)
> 2. An Interaction Pattern is accessible at one or more links (no change)
> 3. A Link has a href, this is where the User Agent can send a typed octet stream to trigger the interaction
> 4. A Link is linked by inputType to one or more OctetStreamType s that describe the possible types for the input
> 5. A Link is linked by outputType to one or more OctetStreamType s that describe the possible types for the output
> 6. An Interaction Pattern is linked by inputData to zero or more DataSchema defininitions,
> 7. An Interaction Pattern is linked by outputData to zero or more DataSchema defininitions,
> 8. A DataSchema is linked to one or more OctetStreamType s that describe the types of the input/output to which it applies
> 8. A DataSchema is linked to one or more OctetStreamType s that describe the type of the available representations of this DataSchema
> 9. A DataSchema is also linked to a href, that is where the User Agent can negotiate one of these representations of the DataSchema
>
>
> Below is an example of a Thing Description in JSON that could conform to the statements above, and describe a thing that exposes an electric consumption property in:
> - XML conforming to the GreenButton application profile,
> - JSON and CSV conforming to the Haystack application profile.
>
> {
> "@type": "Thing",
> "name": "MyThing",
> "base": "coap://mything.example.com:5683/ <http://mything.example.com:5683/>",
> "interaction": [
> {
> "@type": "Property",
> "link": [
> {
> "href": "myproperty",
> "outputType": [
> { "mediatype" : "application/xml" ,
> "profile": "http://www.greenbuttondata.org/#profile <http://www.greenbuttondata.org/#profile>" },
> { "mediatype" : "application/json" ,
> "profile": "http://project-haystack.org/# <http://project-haystack.org/#>" };
> { "mediatype" : "text/csv" ,
> "profile": "http://project-haystack.org/# <http://project-haystack.org/#>" }
> ]
> } ,
> { "href": "myproperty-gb.xml",
> "outputType": { "mediatype" : "application/xml" ,
> "profile": "http://www.greenbuttondata.org/#profile <http://www.greenbuttondata.org/#profile>" }
> } ,
> { "href": "myproperty-haystack.json",
> "outputType": { "mediatype" : "application/json" ,
> "profile": "http://project-haystack.org/# <http://project-haystack.org/#>" };
> } ,
> { "href": "myproperty-haystack.csv",
> "outputType": { "mediatype" : "text/csv" ,
> "profile": "http://project-haystack.org/# <http://project-haystack.org/#>" };
> }
> ],
> "outputData": [
> { "href": "https://raw.githubusercontent.com/energyos/OpenESPI-Common-java/master/etc/espiDerived.xsd <https://raw.githubusercontent.com/energyos/OpenESPI-Common-java/master/etc/espiDerived.xsd>",
> "type": "application/xml",
> "forType": { "mediatype" : "application/xml" ,
> "profile": "http://www.greenbuttondata.org/#profile <http://www.greenbuttondata.org/#profile>" }
> },
> { "href": "http://example.org/mydataschema.json <http://example.org/mydataschema.json>",
> "type": [ "text/csv-schema", "application/schema+json" ],
> "forType": { "mediatype" : [ "application/xml", "application/json" ] ,
> "profile": "http://project-haystack.org/# <http://project-haystack.org/#>" }
> }
> ]
> }
> ]
> }
>
> Best,
> Maxime
>
> [1] https://www.w3.org/2017/dxwg/charter <https://www.w3.org/2017/dxwg/charter>
>
>
>
> Le lun. 25 sept. 2017 à 17:03, Kaebisch, Sebastian <sebastian.kaebisch@siemens.com <mailto:sebastian.kaebisch@siemens.com>> a écrit :
> I’m guessing your are pointing to the duplicated resources definition within the link container of the TD, isn't it?
>
>
>
> In my view there is no contradiction since the TD provides only the latest metadata information which media types is supported behind servient’s resources (=this is actually one of the jobs of the TD). As I mention the representation is maybe not that perfect and I think, Victor’s proposal is a good alternative. Another proposal can be:
>
>
>
> { “href”: “http://192.168.0.10/property <http://192.168.0.10/property>”, “mediaType”: [“application/xml”, “application/json”] }
>
> Here, the resource would occurs only once for the Property definition. However, for this we have to redefine the mediaType vocabulary as an array.
>
>
>
> Do you see some other ideas?
>
>
>
> @Maxime: I think, it’s time to setup a github issue and continue the discussion there. Can you initiate one?
>
>
>
>
>
> <>
> Von: Martynas Jusevičius [mailto:martynas@atomgraph.com <mailto:martynas@atomgraph.com>]
> Gesendet: Montag, 25. September 2017 15:24
> An: Kaebisch, Sebastian (CT RDA NEC WOS-DE)
> Cc: Charpenay, Victor (CT RDA NEC WOS-DE); Dave Raggett; Maxime Lefrançois; public-wot-wg@w3.org <mailto:public-wot-wg@w3.org>
> Betreff: Re: Decoupling between Link and its mediatype, and inputData/outputData
>
>
>
> This makes no sense from the WWW architecture point of view.
>
>
>
> https://www.w3.org/TR/webarch/#frag-coneg <https://www.w3.org/TR/webarch/#frag-coneg>
>
>
> On Mon, Sep 25, 2017 at 3:12 PM, Kaebisch, Sebastian <sebastian.kaebisch@siemens.com <mailto:sebastian.kaebisch@siemens.com>> wrote:
>
> 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 <http://192.168.0.10/property>”, “mediaType”: “application/xml” },
>
> { “href”: “http://192.168.0.10/property <http://192.168.0.10/property>”, “mediaType”: “application/json” },
>
> { “href”: “http://192.168.0.10/property.xml <http://192.168.0.10/property.xml>”, “mediaType”: “application/xml” },
>
> { “href”: “http://192.168.0.10/property <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 <https://www.w3.org/TR/wot-thing-description/#structured-data>
> [2] https://www.w3.org/TR/wot-thing-description/#mapping-to-xml-schema <https://www.w3.org/TR/wot-thing-description/#mapping-to-xml-schema>
>
>
>
>
> Von: Charpenay, Victor [mailto:victor.charpenay@siemens.com <mailto:victor.charpenay@siemens.com>]
> Gesendet: Montag, 25. September 2017 10:38
> An: Dave Raggett; Maxime Lefrançois
> Cc: public-wot-wg@w3.org <mailto: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 <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 <http://192.168.0.10/property.xml>”, “mediaType”: “application/xml” },
>
> { “href”: “http://192.168.0.10/property.json <http://192.168.0.10/property.json>”, “mediaType”: “application/json” }
>
> ]
>
> }
>
> ]
>
> …
>
> }
>
> {
>
> “interaction”: [
>
> {
>
> “@type”: “Property”,
>
> “link”: [
>
> { “href”: “http://192.168.0.10/property <http://192.168.0.10/property>”, “mediaType”: “application/*” }
>
> ]
>
> }
>
> ]
>
> …
>
> }
>
>
>
> Regards,
>
> Victor
>
>
>
> From: Dave Raggett [mailto:dsr@w3.org <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 <http://192.168.0.10/property>
> - the xml version has a canonical URL http://192.168.0.10/property.xml <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 <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 <http://www.w3.org/People/Raggett>
> W3C champion for the Web of things & W3C Data Activity Lead
>
>
>
>
>
>
>
>
>
>
>
Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
W3C champion for the Web of things & W3C Data Activity Lead
Received on Wednesday, 27 September 2017 15:33:53 UTC