[core] Link target attributes in CoRAL (was: Review of CoRAL)

Klaus Hartke <hartke@projectcool.de> Mon, 05 November 2018 11:57 UTC

Return-Path: <hartke@projectcool.de>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A429F1277CC; Mon, 5 Nov 2018 03:57:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_FAIL=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SxDTN8MOiGP; Mon, 5 Nov 2018 03:57:50 -0800 (PST)
Received: from wp382.webpack.hosteurope.de (wp382.webpack.hosteurope.de [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 ietfa.amsl.com (Postfix) with ESMTPS id 864E5128CFD; Mon, 5 Nov 2018 03:57:50 -0800 (PST)
Received: from mail-qk1-f178.google.com ([209.85.222.178]); authenticated by wp382.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1gJdVs-0000gJ-5n; Mon, 05 Nov 2018 12:57:48 +0100
Received: by mail-qk1-f178.google.com with SMTP id a132so14154007qkg.1; Mon, 05 Nov 2018 03:57:48 -0800 (PST)
X-Gm-Message-State: AGRZ1gKUOOb54Hxe58dmEJT7yaVjiHpKuMtGvF6OVWSdL0baMNc8kG7Z OMCc0ng9b9HRaTrhZ7bnad07ELdVqSgUJOOgoxI=
X-Google-Smtp-Source: AJdET5emxf9kl9+Yd6KiF/OkM9UeMrdxKfRM6rIhT/mJF4EE09ZVQdyoeUoWCUYXv50FTvV2yn14msgV90CSh9s7/ZI=
X-Received: by 2002:a37:324a:: with SMTP id y71mr6570038qky.291.1541419067000; Mon, 05 Nov 2018 03:57:47 -0800 (PST)
MIME-Version: 1.0
From: Klaus Hartke <hartke@projectcool.de>
Date: Mon, 5 Nov 2018 12:57:10 +0100
X-Gmail-Original-Message-ID: <CAAzbHvYk9dUvGmYsX1U=0qcU7330bYO6YjGAa51gFKMGGoy-Dg@mail.gmail.com>
Message-ID: <CAAzbHvYk9dUvGmYsX1U=0qcU7330bYO6YjGAa51gFKMGGoy-Dg@mail.gmail.com>
To: =?UTF-8?Q?Christian_M=2E_Ams=C3=BCss?= <christian@amsuess.com>
Cc: T2TRG@irtf.org, draft-hartke-t2trg-coral@ietf.org, "core@ietf.org WG" <core@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-bounce-key: webpack.hosteurope.de; hartke@projectcool.de; 1541419070; 7e5886f4;
X-HE-SMSGID: 1gJdVs-0000gJ-5n
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/CVNGkYNGg2RjO5MCzaMgrOXIQSc>
Subject: [core] Link target attributes in CoRAL (was: Review of CoRAL)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Nov 2018 11:57:53 -0000

On Wed, 31 Oct 2018 at 17:45, Christian Amsüss <christian@amsuess.com> wrote:
> * attrs: title and title* are described as target attributes in RFC8288
>   and can thus easily occur in CoRAL documents.

Good catch! For some reason I was convinced that "title" and "title*"
would describe the link itself, not the link target. I've changed the
text in my working copy accordingly.

> * ibd: Then, it can say something like "MUST NOT occur in a CoRAL
>   document as attributes, but are expressed as link relations, nested
>   links and link relations, respectively" to indicate that their
>   information is not lost in the transition.

This is true for "rel" and "anchor", but not for potential new
attributes defined in the future. I don't think CoRAL should try to
accommodate those, so I'd just forbid all of them (without giving a
mapping to CoRAL) as it is now.

> * What to do with language-tagged attributes (like title*)? The takeaway
>   from links-json is that they can be decoded easily but need to keep
>   their language information. That's easily expressed in RDF (turtle:
>   `<> :title "Überschrift"@de`). links-json went for
>   `{"title":{"de":"Überschrift"}}`, which seems a bit crude to me but
>   could work just as well for CoRAL, as could a tagged CBOR array or a
>   plain array if we stared using arrays with discriminators that are not
>   part of the IRI discriminators as something different than IRIs (a la
>   `[/link/ 2, /attr:title/ 42, [/language-tagged/ -1, "de",
>   "Überschrift"]]`).

Since in CoRAL it's possible to make statements about link targets
(here: the literal "Überschrift"), something like this would look
natural to me:

      #using iana = <http://www.iana.org/assignments/relation/>
      #using attr = <http://TBD2/>

      iana:terms-of-service </tos> {
         attr:title "Nutzungsbedingungen" { attr:hreflang "de" }
         attr:title "Terms of use"        { attr:hreflang "en" }
      }

   <=>

      </tos>; rel=terms-of-service;
         title*=UTF-8'de'Nutzungsbedingungen;
         title*=UTF-8'en'Terms%20of%20use

Another, related question is how to express link target attributes
containing multiple, white-space separated values.

Currently, the mapping of link target attributes to CoRAL links is
pretty unsophisticated: All attribute values simply become a text
string. So, multiple, white-space separated values are still
white-space separated, and numeric values (as for the content-format,
"ct", or representation size, "sz") are expressed as decimal string
representations. The reason for this is that it enables
"round-tripping" for potential new attributes defined in the future.

If there's a guarantee that there won't be any new link target
attributes in the future (for RFC 6690 link serializations), then we
could skip the whole mapping topic and just define a new, more natural
set of link relation types:

    #using rdf = <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
    #using iana = <http://www.iana.org/assignments/relation/>
    #using meta = <http://vocabulary.example.org/metadata#>

    iana:hosts </foo> {
        meta:content-format 110
        rdf:type <http://vocabulary.example.org/iot#temperature-sensor>
        rdf:type <http://vocabulary.example.org/iot#sensor>
        meta:size 1234
   }

<=>

    #using iana = <http://www.iana.org/assignments/relation/>
    #using attr = <http://TBD2/>

    iana:hosts </foo> {
        attr:ct "110"
        attr:rt "example.temperature-sensor example.sensor"
        attr:sz "1234"
    }

Speaking of the IANA-registered "type" link relation and the RDF "a" predicate:

> * FoaF example: Just for my understanding, would anything be wrong with
>   some application using <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
>   as the rel to foaf:Person here? (I figure that few RDF applications
>   treat rdf:type and iana:type as equivalent properties).
>
>   Later that's clarified a bit in A.1 where it says "same purpose", but
>   is rel:type in actual use anywhere? Otherwise, I suggest to go for
>   rdf:type right away, as that is in use. (It's more verbose when
>    expressed in non-CoRAL link formats, though.)

Good point. My assumption was that translators to RDF would convert
every iana:type to an rdf:type, but using rdf:type directly makes a
lot of sense. I've changed the text in my working copy accordingly.

Klaus