Re: [tf-td] WoT metadata

Hi Drasko,

Forgive me if I am restating the obvious, but we may be talking about 2 different things here. JSON and CBOR are representation formats and RDF is a data model.

RDF is based on semantic hyperlinks and is similar to web linking. RDF can be represented in several different formats, including at least 3 in JSON.

CBOR is a binary mapping of JSON that is somewhat analogous to what EXI is to XML. CBOR has custom tag IDs registered with IANA to represent different data types. I haven’t thougth about whether JSON-LD would need or benefit from custom CBOR tags.
http://cbor.io/

JSON-LD is based on the RDF data model and uses the JSON representation format. There are other JSON representations of RDF but JSON-LD has the desired property of separating the context from the descriptors, allowing the developer to interact with a more JSON friendly key value model. But the context resolution still does need to be done in the application at some abstraction level. 

There is a link serialization format for constrained IoT devices from IETF, CoRE Link Format (RFC 6690) which is a compact serialization of web links and can represent at least a subset of RDF. There is a JSON serialization of this format that offers a key value model to developers.
https://tools.ietf.org/html/rfc6690
https://tools.ietf.org/html/draft-bormann-core-links-json-02

There is a compact JSON based data model called SenML that would be very useful but it doesn’t include hyperlinks.
https://tools.ietf.org/html/draft-jennings-senml-10

LWM2M already defines SenML as an optional object serialization format, which I have used in many of my hypermedia examples of IPSO object serializations. CBOR would be used to define a compact binary mapping structured like SenML but potentially using additional tags to expand the data types to the full set of LWM2M data types, e.g. float and integer instead of only numeric, plus a link type. CBOR could also represent the range of XSD types.

@Dave It might be good to have some focused discussion on the data model + representation topic as it relates to Thing Description. I would be interested in the alternatives you mention. How does it impact the data model as exposed to the scripting API the developer will see?

Best regards,

Michael


On Oct 2, 2015, at 12:21 AM, Drasko DRASKOVIC <drasko.draskovic@gmail.com> wrote:

> Hi Dave,
> 
> On Fri, Oct 2, 2015 at 9:02 AM, Anicic, Darko <darko.anicic@siemens.com> wrote:
>> Hi Dave,
>> 
>> 
>> 
>> Von: Dave Raggett [mailto:dsr@w3.org]
>> Gesendet: Donnerstag, 1. Oktober 2015 13:47
>> An: Bassbouss, Louay
>> Cc: Public Web of Things IG
>> Betreff: [tf-td] WoT metadata
>> When it comes to how to represent thing data models, it is no longer clear
>> to me that JSON-LD is a particularly good fit, as a result I am now looking
>> at alternatives. Some stakeholders are committed to XML, whilst Web
>> developers will prefer very lean JSON based representations.  RDF as the
>> formal underpinning is important for scalability, but this shouldn’t be a
>> burden on application developers, especially Web developers.
> 
> +1 for JSON.
> 
> oneM2M started with XML, but I think it is more cruft of telecom
> operators (more inertion). All modern IoT platforms I have seen so far
> use JSON for data serialization.
> 
> From perspective of embedded engineer, what we should look at is CBOR:
> http://cbor.io/, a standardized binary representation that you would
> prefer using on your constrained devices. Maybe Michael Koster tell us
> more, but I think that there are already big efforts in including CBOR
> in new version of LwM2M (which AFAIK does not even support XML).
> Probably oneM2M will follow.
> 
> Json2cbor mapping can be achieved relatively easy, which is one more
> reason of sticking to JSON.
> 
> BR,
> Drasko