Re: [core] [T2TRG] Review of CoRAL

Klaus Hartke <> Thu, 31 January 2019 16:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 22F58130DEA; Thu, 31 Jan 2019 08:57:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kJfEg2ZN8wip; Thu, 31 Jan 2019 08:57:09 -0800 (PST)
Received: from ( [IPv6:2a01:488:42:1000:50ed:8597::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BD070130DC8; Thu, 31 Jan 2019 08:57:09 -0800 (PST)
Received: from ([]); authenticated by running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1gpFeD-0000i6-Sp; Thu, 31 Jan 2019 17:57:05 +0100
Received: by with SMTP id t33so4224236qtt.4; Thu, 31 Jan 2019 08:57:05 -0800 (PST)
X-Gm-Message-State: AJcUukda2qRV3Yh2tzo4CL5TPlm5q8cCH9tg7cq5zpIaT8YAJ5Pt78ip hO+6RtWr7D/yJLEAUQPXj5gUrkwFrAZjJAG0j5o=
X-Google-Smtp-Source: ALg8bN4VOMTWpv/GKGYv4Xgc1a6DitDbxGBuIBisDtSU+hlsQlA/0HT51LdT74qnFzKcFAghoegbqdu1zdYfI9OGf4A=
X-Received: by 2002:ac8:2eb8:: with SMTP id h53mr34400736qta.18.1548953824807; Thu, 31 Jan 2019 08:57:04 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Klaus Hartke <>
Date: Thu, 31 Jan 2019 17:56:29 +0100
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: =?UTF-8?Q?Christian_Ams=C3=BCss?= <>
Cc:,, " WG" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-bounce-key:;; 1548953829; e4ed9f90;
X-HE-SMSGID: 1gpFeD-0000i6-Sp
Archived-At: <>
Subject: Re: [core] [T2TRG] Review of CoRAL
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 31 Jan 2019 16:57:12 -0000

Hi Christian,

here's the final batch of replies to the original review. (I hope
nothing got lost.)

Christian Amsüss <> wrote:
> * "The CoRAL data and interaction model is a superset of the Web Linking
>   model" / "can describe simple resource metadata in a way similar to
>   the Resource Description Framework (RDF)":
>   From the examples in 2.1 (in particular, because the rel becomes a
>   full URI), it appears the othr way round: That the data model is a
>   superset of the RDF model, and that the document describes an
>   equivalence of a subset of RDF statements to typed links (as used in
>   link headers, link format and HTML).

Hmm... it's not really a superset of RDF, since RDF has features like
the ability to describe arbitrary graphs of connected resources, blank
nodes, etc. that CoRAL doesn't. Strictly speaking, it's also not a
superset of Web Linking, since Web Linking has features like target
attributes that CoRAL doesn't.

I think the important thing here is to put the reader of the document
into the right mindset: It's all about navigating between REST
resources, constructing request messages, etc. and not so much about
reasoning in a knowledge graph.

> * Browsing context: This growing history appears hard to do in a
>   constrained context. Can an agent still work with any given maximum
>   history length, in particular 1 or even 0?

I'd say the necessary history length depends entirely on the
application context. A history length of 1 or even 0 is probably
entirely sufficient in most cases. I'm de-emphasizing the session
history a bit in the next draft revision.

> * Forms: I haven't followed all the W3C & surroundings discussions on
>   forms, so I can't say much there as I don't yet understand how they
>   were to actually work. Examples that go beyond "POST to create" and
>   "DELETE to delete" would be helpful when they'd go beyond the
>   intuitive. -- But I assume that as this matures, any formative github
>   discussions will evolve into referrable documents.

Forms are certainly something where some real-world examples would be
very useful. The high-level idea is:

- With links it's easy to find out what resources are available at a
device at a granular level (as opposed to just knowing that the device
has certain resources available based on device type).

- With forms it becomes easy to find out what operations are available
on these resources at a granular level (as opposed to just knowing
that the resource has certain operations available based on resource

- With form data, it becomes easy to find out what parameters are
available on these operations at a granular level (as opposed to just
knowing that the operation has certain parameters available based on
operation type).

Of course, not every application will have a need for going into this
granular level of detail. But the idea is to provide this ability to
applications where a more granular evolution strategy is beneficial.

> * Representations: I think it would be helpful to state something in the
>   area of the second paragraph along the lines of "The producer of the
>   CoRAL document claims that the embedded representation is fresh at
>   least for as long as the CoRAL document is fresh", if so intended.
>   It's obvious that the "full, partial or inconsistent" part is
>   intentionally giving much leeway to the CoRAL producer. Could this
>   possibly be narrowed down for resources under the same authority? A
>   statement like "(under some condition), the presence of a
>   representation states that there exists a request to the target that
>   would result in a response with the given payload" could go into a
>   direction where an agent could populate its own cache with it and work
>   on from there.

Populating cache with representations is tricky, since a cache in CoAP
(and HTTP) stores responses, not representations. I see embedded
representations mostly on the same level as the hints provided by most
link target attributes -- as hints. But I'm open to discussing more
narrow interpretations.

> * Binary data format: When relations expressed as uint are first
>   mentioned (and possibly also with numeric form-field-name), a forward
>   reference to the topic of profiles would be helpful.

I'm restructuring things a bit in the next draft revision.

> * Textual format: I find this more confusing than helpful. The format is
>   too far from turtle to allow intuition to be taken from there
>   (especially as there are simple and qualified names, where turtle has
>   only qualified names but the qualifier may be empty), too far from the
>   binary representation to help understanding the binary format (eg.
>   someone only editing in text format would not see that naming a
>   resource linked as rel="index" <index> would be beneficial, but could
>   be misled to believe that application/octet-stream can be a compact
>   default or that representations can have more attributes -- plus
>   people were led to think that CoRAL is large on the wire).
>   My impression is that CoRAL would not be written by humans, let alone
>   stored or transported as that. I think the document would be better
>   off if no textual format were defined, but full turtle (or a slim
>   superset thereof that's still within N3) were used to express the
>   semantics of a document (which would need an RDF serialization of
>   forms and representations, but that's more of a benefit than a
>   downside IMO).

IMHO it's quite valuable to have a way for giving CoRAL examples with
precise semantics that don't drown in the syntactic overhead that
comes with expressing equivalent information in RDF (or some
XML/JSON/Link Format dialect). Examples are written by humans, who
also might want to store or transport them without losing the semantic
information of grouping, indentation, or comments.

I agree with some of the concerns related to intuition when coming
from Turtle or going to the binary format. If there are ideas how the
textual format could be improved, I'm very interested to include them.

> * Only occurred to me when writing the above
>   extended-diagnostic-notation example: Might it make sense to allow
>   profile defined URIs as well, like common licenses or (when looking a
>   the FoaF example) types? They'd need to be told apart from numeric
>   literals that could just as well show up in a link target, but the iri
>   rule could get an additional `?(profiled: 9, uint)` entry that could
>   only exist on its own and expands like a numeric rel.

Yes. My proposal would be to set up a dictionary of key-value entries,
with keys being unsigned integers and values being either an IRI, an
integer, a string, etc. These dictionary entries could be referenced
both at places where link relation types occur and where link targets
occur. I'm adding a proposal to the next draft revision.