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 <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> http://www.w3.org/People/Raggett
W3C champion for the Web of things & W3C Data Activity Lead