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

From: Klaus Hartke <[email-masked]>
Date: Mon, 5 Nov 2018 12:57:10 +0100

On Wed, 31 Oct 2018 at 17:45, Christian Amsüss <[email-masked]> 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

---

From: Christian M. Amsüss <[email-masked]>
Date: Mon, 5 Nov 2018 13:36:04 +0100

Hi,

> mapping to CoRAL) as it is now.

Non-target link attributes are something I'd discourage in general;
would you, when someone does define new non-target attributes, encourage
them to specify how they'd be expressed in CoRAL?

(RDF would typically do some form of reificiation there, or provide an
intermediate anonymous node).

>          title*=UTF-8'en'Terms%20of%20use

That's kind of neat and kind of scary. The scary comes from the
implications of

    hosts </present> {
        attr:title "Gift" { attr:hreflang "en" }
        attr:title "Geschenk" { attr:hreflang "de" }
    }
    hosts </posion> {
        attr:title "Poison" { attr:hreflang "en" }
        attr:title "Gift" { attr:hreflang "de" }
    }

which may be read to imply that there is a string "Gift" that is both
English and German and describes both resources.

I think it can still work b/c none of that would survive a naïve
round-trip to RDF, and a converter would need to make

    </present> attr:title "Gift"@en, "Geschenk"@de .
    </poison> attr:title "Poison"@en, "Gift"@de .

out of it because RDF statements can't have literals in their subject,
but that issue would need to be well-understood, and literals would need
to be described along the lines of "Two literals are only interchangable
if they have the same literal value *and* all their properties are
identical", where it is not possible to give a literal properties
outside of where it is defined (for that would create a different
literal).

> containing multiple, white-space separated values.

Yes; I have a similar proposal for that in micrurus[1], but it does not
go as far as converting to URIs or numerics yet.

[1]: https://gitlab.com/chrysn/micrurus/blob/master/README.rst#special-provisions-for-link-format-conversions

> set of link relation types:

I don't think we need a guarantee for that. We can, as they pop up, for
some funny-string-valued attributes define equivalent more semantic
attributes, each with their own mapping. So a general CoRAL processor
you could encounter both `attr: rt="x y"` or `split-attr:rt rt:x,
split-attr rt:y` and needs to know of the equivalence.

A profile like links-CoRAL could then say that types need to be
expressed using the split attributes.

I would, in general, discourage defining new white-space-separated
attributes, and in particular I already do so in RD, for the RD would
need to know that an attribute is such a one for usable lookup.

As for the prefix, attr:rt, attr:if and attr:ct have registries, so we
could treat non-URI bare values in analogy to link relation types.
(Those produce currently uncompressible URIs, leading to profile-defined
URIs in what will be another thread).

Best regards
Chrisian

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

---

From: Klaus Hartke <[email-masked]>
Date: Tue, 6 Nov 2018 09:06:11 +0100

> them to specify how they'd be expressed in CoRAL?

I think I don't care enough about Link Format that I'd encourage
maintaining any kind of mapping. The draft currently describes a
generic mapping that works for any target attribute but makes no
attempt to work for any non-target attribute. If I could get rid of
the mapping, I would do it.

> That's kind of neat and kind of scary.

Good point. I'm open to other ideas. But I think I don't want make
processing much more complex to accommodate language-tagged strings,
since it's unlikely that a constrained device will serve links
annotated with titles in 20 languages.

> split-attr rt:y` and needs to know of the equivalence.

This is exactly what I'd like to avoid.

IMO we should decide on either a generic mapping that can round-trip
any attributes or a new set of relations, but not both:
Implementations could never rely on that the other kind doesn't appear
and therefore would have to support both, which doesn't help with
keeping developers happy and implementation sizes small.

Klaus

---

From: Klaus Hartke <[email-masked]>
Date: Tue, 6 Nov 2018 09:21:36 +0100

> This is exactly what I'd like to avoid.

Of course, we could for new link target attributes, as they pop up,
define an equivalent more semantic link relation type. In Link Format
you would use the link target attribute; in CoRAL, the link relation
type. If a converter encounters a new, unknown attribute, it would fail.

Klaus

---

From: Christian M. Amsüss <[email-masked]>
Date: Tue, 6 Nov 2018 09:22:40 +0100

> processing much more complex to accommodate language-tagged [...]

I'm more and more confident that the scheme you proposed can work, and
the only thing that does need to be done is to be very clear about how
the RDF mapping works, and to say that only particular relations SHOULD
be used with literals. (And I can work out with RDF people what the
particular attribute for language tagging should be if you like).

Best regards
Christian

---

From: Christian M. Amsüss <[email-masked]>
Date: Tue, 6 Nov 2018 09:41:34 +0100

On Tue, Nov 06, 2018 at 09:21:36AM +0100, Klaus Hartke wrote:
> [later]

Only defining the mapping for known target attributes would neatly get
us rid of the issue of link attributes. Implementations could still be
as simple as possible (ie. not even have an enumeration of known
attributes) if they accept producing odd output on unspecified input,
and follow the most common rule (map to attr:${key} "${value}") on all
but the known whitespacers.

My expectation though is that processors that convert link-format to
CoRAL would be less constrained devices (C2 or larger), and that smaller
devices that still want to serve both would have something equivalent to
hard-copies of both representation in ROM instead -- is that a
reasonable one?

Best regards
Christian

---

From: Christian M. Amsüss <[email-masked]>
Date: Thu, 8 Nov 2018 12:31:03 +0100

> type. If a converter encounters a new, unknown attribute, it would fail.

It just occurred to me that there is another point to be made for
per-relation rules: There are target attributes that are URI-valued.
That's something I'd recommend to avoid in the first place, but still
does happen (eg. ol= in protocol-negotiation, or even base= in RD which
I can't really rip up now).

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).

Christian

---

From: Klaus Hartke <[email-masked]>
Date: Thu, 8 Nov 2018 15:28:48 +0100

> worth it (speaking as someone who'll have to implement the lookups).

The lookup interface is indeed an interesting topic.

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/>). But I think you
want to select all links where there is a nested link with the link
relation type <http://TBD2/foobar> and link target <coap://x/>.

My idea would be to use CoRAL to express this:

    FETCH /.well-known/core
    Content-Format: text/coral

    iana:hosts _ { attr:foobar <coap://x/> }

Klaus

---

From: Christian M. Amsüss <[email-masked]>
Date: Thu, 8 Nov 2018 15:55:19 +0100

On Thu, Nov 08, 2018 at 03:28:48PM +0100, Klaus Hartke wrote:
> <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:

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.

---

From: Klaus Hartke <[email-masked]>
Date: Sat, 10 Nov 2018 10:00:59 +0100

> English and German and describes both resources.

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:

    hosts </temperature> {
        example:value 21 {
            example:unit <http://unitsofmeasure.org/example/Cel>
        }
    }
    hosts </weight> {
        example:value 21 {
            example:unit <http://unitsofmeasure.org/example/kg>
        }
   }

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...

Klaus

---

From: Klaus Hartke <[email-masked]>
Date: Sat, 10 Nov 2018 10:04:05 +0100

> but the known whitespacers.

👍

> hard-copies of both representation in ROM instead -- is that a

As long as a constrained device understands all attributes in its
</.well-known/core>, I see not problem with a constrained device
generating a CoRAL representation from a Link Format representation on
the fly (or vice versa) (or both from a more efficient in-memory
representation). If that's not the case, then storing hard-copies of
both representations in ROM sounds reasonable to me.

Klaus

---

From: Christian Amsüss <[email-masked]>
Date: Sat, 10 Nov 2018 10:16:08 +0100

> 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.

> integer 21, which has the unit degree Celsius and contradictorily also

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

---

From: Jim Schaad <[email-masked]>
Date: Tue, 13 Nov 2018 14:09:02 +0900

> -----Original Message-----
> From: core <[email-masked]> On Behalf Of Christian M. Amsüss
> Sent: Thursday, November 8, 2018 8:31 PM
> To: Klaus Hartke <[email-masked]>
> Cc: [email-masked] WG <[email-masked]>
> Subject: Re: [core] Link target attributes in CoRAL (was: Review of CoRAL)
> 
per-relation
> rules: There are target attributes that are URI-valued.
> That's something I'd recommend to avoid in the first place, but still does
> happen (eg. ol= in protocol-negotiation, or even base= in RD which I can't
> really rip up now).
> 
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.

Jim

---

From: Christian M. Amsüss <[email-masked]>
Date: Tue, 13 Nov 2018 09:36:26 +0100

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).
> 

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