Handling of non-URI structured metadata in specification text

[laurensdeb]

Note that there is currently non-URI structured metadata in here, the question is whether this is consistent with using Linksets.

Originally posted by @laurensdeb in #81

[acoburn]

For non-URI metadata, such as media type and resource size values, these are not typically link headers (and therefore not part of a linkset resource); rather they have their own dedicated HTTP Headers: Content-Type and Content-Length

[acoburn]

@elf-pavlik is going to look into this to figure whether (a) this can be closed or (b) whether there are changes needed to the spec or (c) something else needs to be adjusted

[elf-pavlik]

For now I looked up the type parameter (distinct from type relation)

https://www.rfc-editor.org/info/rfc8288/#section-3.4.1

The "type" attribute, when present, is a hint indicating what the
media type of the result of dereferencing the link should be. Note
that this is only a hint; for example, it does not override the
Content-Type header field of a HTTP response obtained by actually
following the link. The type attribute MUST NOT appear more than
once in a given link-value; occurrences after the first MUST be
ignored by parsers.

I was experimenting with it in

• Cool URIs for the Semantic Web: 303 URIs forwarding to Different Documents #39

I still find it confusing how link relations used in qualified way work. Translating it to statements/triples I would use the target as a subject not the relation itself. That's also my issue with as:Link but we need to work with what we have.

BTW all registered link relations are non-URI

• link relations for RDF mnot/I-D#39

EDIT I also note

• https://www.rfc-editor.org/info/rfc8288/#section-2.2
• RFC 9423: Constrained RESTful Environments (CoRE) Target Attributes Registry