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

[Christian M. Amsüss <[e-mail]>]

On Thu, Nov 08, 2018 at 03:28:48PM +0100, Klaus Hartke wrote:
> I would assume that ?anchor=coap://x/&rel=attr:foobar selects all
> links with the link context <coap://x/> and link relation type
> <http://TBD2/foobar> (using attr = <http://TBD2/>).

Yes, that's what it means. It's just that once we consider expressing
URI-string-valued target attributes as CoRAL IRIs, as in

    hosts </sensor> {
      attr:sz "1024",
      attr:ol <coap+tcp://.../sensor>
    }

then the line between attributes and relations gets blurred (Is it a
link? Is it an attribute? Why was it not expressed as a link in the
first place?) to the point that it affects query filtering[1]. Two
reason why this still does not make me say "nah, let's have them as
string literals then" is that a) I'm an RDF afficionado, and b) whoever
does filtering already needs to know the semantics of the field, or
would fail to make ?rt=x match ;rt="x y".

> My idea would be to use CoRAL to express this:
> 
>     FETCH /.well-known/core

A CoRAL fetch format ... and I was afraid suggesting this would be way
over the top :-). I'm looking forward to this (hopefully in a shorter
time frame than SenML-adoption-to-SenmL-fetch), but right now it's
probably too early for it.

Christian


[1] I'm speaking of .well-known/core query filtering and not of RD
  lookup filtering because the latter is an extension of the former.

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