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

Christian Amsüss <christian@amsuess.com> Sat, 10 November 2018 09:16 UTC

Return-Path: <christian@amsuess.com>
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 2E9B0130E11 for <core@ietfa.amsl.com>; Sat, 10 Nov 2018 01:16:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 mPDwnkLX6viw for <core@ietfa.amsl.com>; Sat, 10 Nov 2018 01:16:14 -0800 (PST)
Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A055C130DE4 for <core@ietf.org>; Sat, 10 Nov 2018 01:16:14 -0800 (PST)
Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id EEF1E41F8C; Sat, 10 Nov 2018 10:16:10 +0100 (CET)
Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 7706139; Sat, 10 Nov 2018 10:16:09 +0100 (CET)
Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::71b]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 286332E; Sat, 10 Nov 2018 10:16:09 +0100 (CET)
Received: (nullmailer pid 15787 invoked by uid 1000); Sat, 10 Nov 2018 09:16:08 -0000
Date: Sat, 10 Nov 2018 10:16:08 +0100
From: Christian Amsüss <christian@amsuess.com>
To: Klaus Hartke <hartke@projectcool.de>
Cc: "core@ietf.org WG" <core@ietf.org>
Message-ID: <20181110091607.GA5913@hephaistos.amsuess.com>
References: <CAAzbHvYk9dUvGmYsX1U=0qcU7330bYO6YjGAa51gFKMGGoy-Dg@mail.gmail.com> <20181105123604.GA9680@hephaistos.amsuess.com> <CAAzbHvaizPq03RJe4CybEamkoRVcM5pbs+cvK3eM04r1KLvsbg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="wac7ysb48OaltWcw"
Content-Disposition: inline
In-Reply-To: <CAAzbHvaizPq03RJe4CybEamkoRVcM5pbs+cvK3eM04r1KLvsbg@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/TfvmHs7szvwH6DXuZurGuVpqPhY>
Subject: Re: [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: Sat, 10 Nov 2018 09:16:17 -0000

On Sat, Nov 10, 2018 at 10:00:59AM +0100, Klaus Hartke wrote:
> Literals as link targets indeed seem to need some fine-tuning. Besides
> language tags, I can also imagine other kinds of information attached
> to a literal, such as a unit:

RDF has data types, of which many AFAICT could be mapped to non-string
literals (making their normalization issues go away like CIRIs do away
with IRI normalization issues).

Units I'd prefer to keep per-resource, but we can probably come up with
a way to make them into data types for RDF conversion too if we want.

> This may be read to imply that there is a resource identified by the
> integer 21, which has the unit degree Celsius and contradictorily also
> the unit kilogram...

The mind set to lead us out of this is to treat literals more like blank
nodes with a value -- two blank nodes are only identical if they are the
same null thing in the syntax tree, and literal nodes don't become
identical just by virtue of having the same literal value. (RDF might
treat them as identical if their value *and* all their attributes like
language tag and data type are).

CIRI references are not identical either if they have the same array
representation, but are identical if they resolve to the same full
CIRI (and as with RDF, some applications might introduce additional
equivalencies, eg. from protocol-negotiation).


But yes, this does need thinking over, and probably some text explains
why it's justified.

Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom