- From: Maxime Lefrançois <maxime.lefrancois@emse.fr>
- Date: Thu, 28 Sep 2017 06:55:26 +0000
- To: Dave Raggett <dsr@w3.org>
- Cc: "public-wot-wg@w3.org" <public-wot-wg@w3.org>
- Message-ID: <CALsPASWN-Hu+NbHaKNQ6drJoE3xLyjS_HVvNPkFh1oX57237KQ@mail.gmail.com>
Dear Dave, all,
The use case I mention (greenbutton + haystack) is synthetic, no need to
solve it completely.
Thanks for enlightening me on your vision for this simple Web of Things
where all devices and application servers adopt a uniform and simple data
model for every vertical application, that, if I understand well, will be
required to be in the scope of the new generic schema definition we are
developing within this group [1]. This reminds me of a sentence in [2]:
> In a perfect world, language designers would invent languages that
perfectly met the requirements presented to them, the requirements would be
a perfect model of the world,
> they would never change over time, and all implementations would be
perfectly interoperable because the specifications would have no
variability.
The rest of this paragraph in [2] precises the "extensibility" design
principle as part of the Web Architechture principles.
When I am suggesting we just provide a URI for DataSchema and let the User
Agent look it up and see whether it can manage it and use it (depending on
its type), I was hoping to provide means to reach this extensibility
criteria.
Anyways, I understand my latest example seems complicated on first sight
and makes us reluctant to adding some complexity to the model.
So shall I understand the answers to the following questions is also yes?
1. there exists only one DataModel for every interaction pattern, and we
will define mappings from a "WoT DataModel spec" to those data validation
formalism capable of validating data in a format we allow servients to
exchange: JSON Schema for JSON and CBOR, XML Schema for XML and EXI, end of
story.
2. We do not want to account for cases where the output of an interaction
is available in a different format as the input. The media type associated
with the Link is that of the input and the output of the interaction. If
two media types are present, then both the input and the output may be
represented with these two media types.
3. We only account for media type variability. Not Language, nor Encoding,
nor Charset, nor Application Profile.
Best,
Maxime
[1] - https://w3c.github.io/wot-thing-description/#type-system
[2] - https://www.w3.org/TR/webarch/#ext-version
Le mer. 27 sept. 2017 à 17:33, Dave Raggett <dsr@w3.org> a écrit :
> 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> ; ##
> 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>
> ;
> td:hasMediaType "application/json" ] ,
> [ td:isAccessibleThrough <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/",
> "interaction": [
> {
> "@type": "Property",
> "link": [
> {
> "href": "myproperty",
> "outputType": [
> { "mediatype" : "application/xml" ,
> "profile": "http://www.greenbuttondata.org/#profile"
> },
> { "mediatype" : "application/json" ,
> "profile": "http://project-haystack.org/#" };
> { "mediatype" : "text/csv" ,
> "profile": "http://project-haystack.org/#" }
> ]
> } ,
> { "href": "myproperty-gb.xml",
> "outputType": { "mediatype" : "application/xml" ,
> "profile": "
> http://www.greenbuttondata.org/#profile" }
> } ,
> { "href": "myproperty-haystack.json",
> "outputType": { "mediatype" : "application/json" ,
> "profile": "http://project-haystack.org/#" };
> } ,
> { "href": "myproperty-haystack.csv",
> "outputType": { "mediatype" : "text/csv" ,
> "profile": "http://project-haystack.org/#" };
> }
> ],
> "outputData": [
> { "href": "
> 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"
> }
> },
> { "href": "http://example.org/mydataschema.json",
> "type": [ "text/csv-schema", "application/schema+json" ],
> "forType": { "mediatype" : [ "application/xml",
> "application/json" ] ,
> "profile": "http://project-haystack.org/#" }
> }
> ]
> }
> ]
> }
>
> Best,
> Maxime
>
> [1] https://www.w3.org/2017/dxwg/charter
>
>
>
> Le lun. 25 sept. 2017 à 17:03, Kaebisch, Sebastian <
> 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”, “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]
>> *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
>> *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
>>
>>
>>
>> On Mon, Sep 25, 2017 at 3:12 PM, Kaebisch, Sebastian <
>> 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”, “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 <dsr@w3.org>]
>> *Sent:* Freitag, 22. September 2017 19:12
>> *To:* Maxime Lefrançois
>> *Cc:* 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>
>> 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> 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 Thursday, 28 September 2017 06:56:05 UTC