Subject: Re: [T2TRG] Reminder: WISHI Semantic Interoperability Test Event planning call

From: Michael Koster <[email-masked]>
Date: Sun, 11 Mar 2018 22:39:00 -0700

Here are some slides about design patterns for semantic annotation.

There is a strawman example using CoRE Link-Format and RD for semantic annotation of a LWM2M instance.

Best regards,

Michael

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 12 Mar 2018 17:47:54 +0100

> On Mar 12, 2018, at 06:39, Michael Koster <[email-masked]> wrote:
> 
> <semantic-patterns.pdf>

Here is what I was trying to say when we ran out of time:

You say:

<http://iotschema.org/common>;rel=describedBy;uri- prefix=“iot";type="application/ld+json application/json",

in one link of the collection, so that you then can say:

</3311/0/>;st=“iot:Light iot:BinarySwitch iot:LevelControl”, 

in another link, instructing the client to piece together a URI that describes /3311/0 from “Light” and from “http://iotschema.org/common”.

That doesn’t really work if a query selection only happens to give you back the latter link, not the former (which is usually OK because RD/wk-c links are supposed to be standing on their own).

So how to fix this?

One idea was to define a local, semantics-only URI:

</sem/light>;rel=shortcutfor;anchor=http://iotschema.org/common/Light

You could then use

	st=“/sem/light”

on that link.

Or maybe even another link such as

</3311/0/>;anchor=“/sem/light”;rel=providessemanticsfor

which would be easier to find as a semantics link but harder to correlate with the other links describing resources.

(Please excuse the not-so-bright link relation names I invented here.)

Grüße, Carsten

---

From: Klaus Hartke <[email-masked]>
Date: Wed, 14 Mar 2018 11:01:12 +0100

> There is a strawman example using CoRE Link-Format and RD for semantic annotation of a LWM2M instance.

I'm always interested in seeing how things might look like in CoRAL.
So I've tried to CoRALify the example on slide 11, which looks like
this:

    <http://iotschema.org/common>;rel=describedBy;uriprefix="iot";
    type="application/ld+json application/json",
    </3311>;con=coaps://[2001:DB8::1]:5684;type=vnd.oma.lwm2m+cbor,
    </3311/0/>;st="iot:Light iot:BinarySwitch iot:LevelControl",
    </3311/0/>;anchor="iot:LivingRoom";rel="iot:LocationContains",
    </3311/0/5850>;st="iot:SwitchState iot:StateData",
    </3311/0/5851>;st="iot:CurrentLevel iot:LevelData",
    </3311/1/>;st="iot:Light iot:BinarySwitch iot:LevelControl",
    </3311/1/>;anchor="iot:Kitchen";rel="iot:LocationContains",
    </3311/1/5850>;st="iot:SwitchState iot:StateData",
    </3311/1/5851>;st="iot:CurrentLevel iot:LevelData",

(CoRE Link Format is obviously not designed for prefixes and
namespaces, which tripped up Carsten during the call. But this can be
fixed, even though that might be a bit stressful without extending the
Link Format grammar. I think namespacing facilities are truly needed
if we don't want to continue shipping an RFC for every link relation
type that we come up with or tacking a new link attribute onto Link
Format to circumvent that process.)

Before diving into CoRAL, here's how I guess the example would look
like in Turtle/RDF:

    @prefix iot: <http://iotschema.org/common#> .
    @base <coaps://[2001:DB8::1]:5684/> .

    </3311/0/>
        a iot:Light ;
        a iot:BinarySwitch ;
        a iot:LevelControl .

    iot:LivingRoom
        iot:LocationContains </3311/0/> .

    </3311/0/5850>
        a iot:SwitchState ;
        a iot:StateData .

    </3311/0/5851>
        a iot:CurrentLevel ;
        a iot:LevelData .

    </3311/1/>
        a iot:Light ;
        a iot:BinarySwitch ;
        a iot:LevelControl .

    iot:Kitchen
        iot:LocationContains </3311/1/> .

    </3311/1/5850>
        a iot:SwitchState ;
        a iot:StateData .

    </3311/1/5851>
        a iot:CurrentLevel ;
        a iot:LevelData .

(Michael: Does that look right? It's a bit odd that there is globally
only one Kitchen resource that literally contains all light switches
on the planet.)

In CoRAL, the example could look as follows. CoRAL is a bit more
constrained than RDF in what it can describe, since CoRAL is primarily
intended for describing resources that you can interact with using
CoAP or HTTP. A CoRAL document has only one subject and then describes
the resources related to that subject:

    // subject is <coaps://[2001:DB8::1]:5684/.well-known/core>
    #using <http://www.iana.org/assignments/relation/>
    #using iot = <http://iotschema.org/example#>

    hosts </3311/0/> {
        type iot:Light
        type iot:BinarySwitch
        type iot:LevelControl
        iot:Location iot:LivingRoom
    }

    hosts </3311/0/5850> {
        type iot:SwitchState
        type iot:StateData
    }

    hosts </3311/0/5851> {
        type iot:CurrentLevel
        type iot:LevelData
    }

    hosts </3311/1/> {
        type iot:Light
        type iot:BinarySwitch
        type iot:LevelControl
        iot:Location iot:Kitchen
    }

    hosts </3311/1/5850> {
        type iot:SwitchState
        type iot:StateData
    }

    hosts </3311/1/5851> {
        type iot:CurrentLevel
        type iot:LevelData
    }

(I had to reverse the iot:LocationContains relation, because the focus
of this description are the light switches, not the kitchen.)

This example is very protocol-centric in that it describes a CoAP
server and a flat list of its resources rather than the objects in the
smart home and how they relate to each other. So, here is another way
I imagine the home could be described; in a semantic top-down view:

    // subject is <coap://25greenwooddrive.myhome.example/>
    #using <http://TBD/>
    #using iot = <http://myhome.example/vocabulary#>

    item </rooms/room2> {
        type iot:LivingRoom

        item </3311/0/> {
            type iot:Light
            type iot:BinarySwitch
            type iot:LevelControl

            item <5850> {
                type iot:SwitchState
                type iot:StateData
            }

            item <5851> {
                type iot:CurrentLevel
                type iot:LevelData
            }
        }
    }

    item </rooms/room5> {
        type iot:Kitchen

        item </3311/1/> {
            type iot:Light
            type iot:BinarySwitch
            type iot:LevelControl

            item <5850> {
                type iot:SwitchState
                type iot:StateData
            }

            item <5851> {
                type iot:CurrentLevel
                type iot:LevelData
            }
        }
    }

(The link relation types 'item' and 'type' are defined in [1] and [2]
and essentially have the meaning of 'has-a' and 'is-a', respectively.)

Thoughts?

Klaus

[1] https://tools.ietf.org/html/rfc6573#section-2.1
[2] https://tools.ietf.org/html/rfc6903#section-6

---

From: Michael Richardson <[email-masked]>
Date: Thu, 15 Mar 2018 08:11:17 +0000

The more I learn about link/RDF format stuff, the more I wonder why isn't not
encoded in CBOR.  I don't want to parse that in my small device...

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Ivaylo Petrov <[email-masked]>
Date: Thu, 15 Mar 2018 11:57:33 +0100

Hi Michael,

Do you mean something like this
<https://datatracker.ietf.org/doc/html/draft-ietf-core-links-json>?

Cheers,

Ivaylo Petrov
Chief Architect
ivaylo at ackl.io

www.ackl.io

2 bis rue de la Châtaigneraie,
35510 Cesson Sévigné
FRANCE

Phone: +33 (0)2.99.12.24.14

2018-03-15 9:11 GMT+01:00 Michael Richardson <[email-masked]>:

> _______________________________________________
> T2TRG mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/t2trg
>
>

---

From: Klaus Hartke <[email-masked]>
Date: Thu, 15 Mar 2018 13:12:07 +0100

> encoded in CBOR.  I don't want to parse that in my small device...

That's CoRAL: a bit more than Link Format (namespaces, forms), a bit
less than RDF, packaged in a tiny CBOR format that can be easily
consumed on constrained devices.

https://tools.ietf.org/html/draft-hartke-t2trg-coral-04#section-4

(CBOR examples are just not very pleasant to look at. That's why there
is also a human-readable and -writable text format.)

Klaus

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 15 Mar 2018 13:13:42 +0100

Hi Michael,

We had a discussion about TD serialization in W3C WoT.

My slides are linked from there:
https://www.w3.org/2017/07/09-13-wot-minutes.html#july-11-item04

(There is also some [unpublished] code, which generated the numbers.)

I briefly reported in the CBOR meeting in July.

Grüße, Carsten

> On Mar 15, 2018, at 09:11, Michael Richardson <[email-masked]> wrote:
> 
>