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

[Klaus Hartke <[e-mail]>]

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