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>
> 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
>>
>