- From: Maxime Lefrançois <maxime.lefrancois@emse.fr>
- Date: Wed, 27 Sep 2017 14:56:40 +0000
- To: "public-wot-wg@w3.org" <public-wot-wg@w3.org>
- Message-ID: <CALsPASVMsrK7mWWFwhQMQuD88XcgsCOPnSZ6NRNxwjPavb+B-w@mail.gmail.com>
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
>
>
>
>
>
>
>
>
>
>
>
Received on Wednesday, 27 September 2017 14:57:21 UTC