[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, 05 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: "Christian M. Amsüss" <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
- [core] Link target attributes in CoRAL (was: Revi… Klaus Hartke
- Re: [core] Link target attributes in CoRAL (was: … Christian M. Amsüss
- Re: [core] Link target attributes in CoRAL (was: … Klaus Hartke
- Re: [core] Link target attributes in CoRAL (was: … Klaus Hartke
- Re: [core] Link target attributes in CoRAL (was: … Christian M. Amsüss
- Re: [core] Link target attributes in CoRAL (was: … Christian M. Amsüss
- Re: [core] Link target attributes in CoRAL (was: … Christian M. Amsüss
- Re: [core] Link target attributes in CoRAL (was: … Klaus Hartke
- Re: [core] Link target attributes in CoRAL (was: … Christian M. Amsüss
- Re: [core] Link target attributes in CoRAL (was: … Klaus Hartke
- Re: [core] Link target attributes in CoRAL (was: … Klaus Hartke
- Re: [core] Link target attributes in CoRAL (was: … Christian Amsüss
- Re: [core] Link target attributes in CoRAL (was: … Jim Schaad
- Re: [core] Link target attributes in CoRAL (was: … Christian M. Amsüss