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

Christian M. Amsüss <christian@amsuess.com> Tue, 13 November 2018 08:36 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 2673012D4E6 for <core@ietfa.amsl.com>; Tue, 13 Nov 2018 00:36:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.921
X-Spam-Level:
X-Spam-Status: No, score=-0.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979] 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 R-W-UuHl6XT7 for <core@ietfa.amsl.com>; Tue, 13 Nov 2018 00:36:33 -0800 (PST)
Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97C24130DDA for <core@ietf.org>; Tue, 13 Nov 2018 00:36:31 -0800 (PST)
Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id EE6DA415D3; Tue, 13 Nov 2018 09:36:28 +0100 (CET)
Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 0C7EE39; Tue, 13 Nov 2018 09:36:28 +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 AA9E319; Tue, 13 Nov 2018 09:36:27 +0100 (CET)
Received: (nullmailer pid 20963 invoked by uid 1000); Tue, 13 Nov 2018 08:36:26 -0000
Date: Tue, 13 Nov 2018 09:36:26 +0100
From: "Christian M. Amsüss" <christian@amsuess.com>
To: Jim Schaad <ietf@augustcellars.com>
Cc: 'Klaus Hartke' <hartke@projectcool.de>, core@ietf.org
Message-ID: <20181113083625.GA19660@hephaistos.amsuess.com>
References: <CAAzbHvYk9dUvGmYsX1U=0qcU7330bYO6YjGAa51gFKMGGoy-Dg@mail.gmail.com> <20181105123604.GA9680@hephaistos.amsuess.com> <CAAzbHvZ=4GaPH6FXj4ZuOzMLrQbWUo-Oc6CUmiA4O2b3PhK-rA@mail.gmail.com> <CAAzbHvaSDzc62-dY-ALQxW6bGKS7avCv795-DUMh0PVRF+yaqw@mail.gmail.com> <20181108113103.GB13498@hephaistos.amsuess.com> <000501d47b0f$007301d0$01590570$@augustcellars.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="a8Wt8u1KmwUX3Y2C"
Content-Disposition: inline
In-Reply-To: <000501d47b0f$007301d0$01590570$@augustcellars.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/3SVwOye-7FvgcNyCHhnw1LcU8II>
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: Tue, 13 Nov 2018 08:36:35 -0000

On Tue, Nov 13, 2018 at 02:09:02PM +0900, Jim Schaad wrote:
> > It's a trade-off, though: While making the resulting data
> > semantically > more palatable, it makes link filtering odder (a `GET
> > /.well- known/core?ol=coap://x/`  CoRAL response one'd need to think
> > `GET /.w- k/c?anchor=coap://x/&rel=attr:ol`). I still think it's
> > worth it (speaking > as someone who'll have to implement the
> > lookups).
> 
> Would a more interesting version of this end up being
> 
> GET /.well-known/core?ol=coap+tls://x/
> 
> Although I am completely unsure if that means the same thing as what you
> suggested.

Yes, that's the kind of lookups I'm thinking about.

The rel=attr:ol lookup above is not something I expect we'd ever send
over the wire, but should express the differeneces in models we are
facing: The CoRAL/RDF data model knows no attributes to look up aganist,
and could (especially with link-valued attributes) not even know from
the data alone whether something is a link or an attribute.

When implementing query filtering, one will first see

    ?ol=coap+tls://x/

then will recognize that ol is a link-valued target attribute, so the 
query is internally semantically equivalent to

    SELECT ?target WHERE { ?target attr:ol <coap+tls://x/> }

(which is a form of lookup one'd also have if a query were for
?anchor=coap+tls://x/&rel=something), and then look into the data again
to convert back.

I guess what I'm eventually saying here is that the way query filtering
is expressed is tightly bound to the web links (annotated targets)
information model, and running them against the CoRAL model (only links,
but also to literals; which I personally think is way more elegant) does
not come trivially.

It is possible, and well-defined once a mapping between the information
models, and can probably even be implemented efficiently, but not
immediately obvious when thinking in CoRAL and seeing a filter query.

Best regards
Christian

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