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

On the SDW mailing list there is a conversation on the use of (application) profiles on the WoT and it’s possible that the WoT WG will provide one or more use cases for that (and I hope they will). So this is just an advance notice to the DXWG that there is a new stakeholder at the horizon…

Best,

Lars

From: Maxime Lefrançois [mailto:maxime.lefrancois@emse.fr]
Sent: Wednesday, September 27, 2017 2:37 PM
To: Rob Atkinson; SDW WG Public List
Subject: Re: Decoupling between Link and its mediatype, and inputData/outputData

Hi Rob,

Sorry for the late reply,

Actually my previous mail was intended to be sent to the WoT WG mailing list, my mistake.
Anyways, I was unaware of the Data Exchange WG. It looks very interesting and its partly overlaps what I was hoping to push forward in the WoT WG, I will try to get involved soon.

The starting point for my question is the current Things Description ontology that is designed in the WoT group to model properties/events/actions interaction patterns that things can offer; at what URI such interactions can be requested by user agents; the kind of input the user agent has to send; the kind of output it will receive (or it will be able to fetch afterwards).

My answers to you comments inline:


Note that he Data Exchange WG is currently gathering Use Case and Requirements for description and mechanisms of content negotiation by 'profile" and finer grained semantics of data descriptions (e.g. - but not limited to - schemas).

I will encourage the WoT WG to propose some UC with respect to this

So what is your Use Case for actually modelling this, vs the information resource URLs being discovered at run-time via content-negotiation and redirects?

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.

I am uncomfortable with the way the Links and the DataSchema descriptions are decoupled, as (for example):
 - there may be multiple representations (say: profile) of the same input resource and output resource, potentially having different media types for the same application profile, or the same media type but different application profiles.
 - the request may need to be sent at a different URI than where the output will be located (e.g., HTTP return code 201 created with header Location: xxx),

do you have multiple schema objects or really one schema and a parallel content-negotiation problem - i.e. get me the schema using JSON vs get me the XSD?

Thats's the big question, here are the two main options I see:

Option 1. a td:InteractionPattern is linked to at most one DataSchema for the input.
 - The DataSchema is a resource (abstract) that has one or more representations (JSON Schema, ShEx expression, SHACL shape), each having a specific type. The type potentially includes a media-type (application/json, text/turtle, text/turtle), a language, a character encoding, a "profile".
 - An "input" for this interaction pattern is a typed octet stream the user agent sends to the device. This typed octet stream must validate against one of the representations of the DataSchema, meaning.:
   1. its type must be compatible with that of the specific DataSchema representation
   2. it validates against the DataSchema representation (a JSON doc against a JSON Schema; a Turtle doc against a ShEx or SHACL definition, etc.)

Option 2: a td:InteractionPattern is linked to one or more possible DataSchema for the input.
Each instance of a DataSchema has a certain type (as above), and only one representation (JSON Schema, ShEx, SHACL),
 - A valid 'input" for this interaction pattern is a typed octet stream that validates against one of the DataSchemas, as defined in option 1.

And how do you handle, for example, the device providing lightweight information and more detailed graphs - with for example a calibration history?

Isn't that a perfect use case for profiles ?

In DXWG we are interested in how you might define an "interoperability profile" of a RDFS schema that might constrain/require for example that json and XML are available. You can express this with dct:hasFormat possibly - using SHACL to require that these formats are in fact present in a desciption?

I am following this looking at how the OGC might support publication of interoperability profiles of its standards in a consistent way.

I see. Also, I would like to encourage to include a reference to some RDF Lifting mechanism along with the dct:hasFormat, allowing users to generate some RDF from the raw typed octet  stream. (there may be multiple RDF Lifting mechanisms depending on the intended profile).

Best,
Maxime


Rob Atkinson



On Fri, 22 Sep 2017 at 17:26 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 do you suggest to manage this ?

Best,
Maxime Lefrançois