Stable URIs for registered relation types

[mnot]

From #39. We need a convention for registered relation types to be assigned URIs, so that applications (such as RDF) can refer to them.

From previous discussion:

I think the resolution is a modification of what I suggested way above (incorporating feedback from @dret). In "Registered Relation Types", add:

Applications that wish to refer to registered relation types with a URI [RFC3986] MAY do so by prepending them with "http://www.iana.org/assignments/relation/". Note that the resulting strings are not considered equivalent to the registered relation types by many processors, and SHOULD NOT be serialised unless the application using link relations specifically allows them.

(with possible adjustments to the prefix depending on decisions below)

[dret]

i would consider even stronger wording, such as "the resulting URIs MAY NOT be used outside of well-defined environments, and any serialization depending on registered IANA link relations MUST use the registered strings as link relation type identifiers." maybe that's too strict, but i think there's quite a risk here that the URIs will creep out of the places where they need to be used (such as RDF models that would like to use them as predicates) into the rest of the world where they really really shouldn't be used. establishing a URI convention substantially increases that risk, so trying to contain it with strong language may be in order.

[mnot]

Reopening to discuss that, and to remember we need to finalise the URL (considering things like / vs # ), and perhaps instruct IANA about what to do.

[dschulten]

@dret your concern is that services start using the URI and break applications which rely on the simple rel string, right?
Your proposal seems to say: "if you depend on a registered rel, you have to use the simple string. But in a well defined environment you may use the URI instead". The alternative is not quite balanced, it is not about depending on a registered rel vs. well defined environment.
To me it appears that the alternative is: implementation that has an implicit notion of unique IANA rels vs. implementation that has no implicit notion of IANA rels and thus requires them to be unique identifiers (e.g. RDF).
How about using that alternative as the discriminator, and mention RDF to make it more clear which kind of scenario we are talking about?

"Serialisations such as RDF that have no implicit notion of unique IANA link relations MAY refer to them with a URI [RFC3986] by prepending them with "http://www.iana.org/assignments/relation/". Note that the resulting strings are not considered equivalent to the registered relation types by many processors, and therefore MUST NOT be used for serialisations which have an implicit notion of registered IANA relation types."

[dret]

"Serialisations such as RDF that have no implicit notion of unique IANA link relations MAY refer to them with a URI [RFC3986] by prepending them with "http://www.iana.org/assignments/relation/". Note that the resulting strings are not considered equivalent to the registered relation types by many processors, and therefore MUST NOT be used for serialisations which have an implicit notion of registered IANA relation types."

maybe i am not quite understanding your usage of the term "implicit" here. to me, the fundamental problem we're discussing is RDF's lack of structural (i.e., coherent) context. in HTML/XML (and JSON), it is trivial to say something like this: <link href="...." rel="relation"/> the @rel attribute is only meaningful in the context of the link element, and the model provides that kind of context. that kind of context is lacking in RDF, which is why strings (that need context to be meaningful) don't work. that's how i see the underlying problem of RDF's inability to use non-URI identifiers. are we in agreement? if yes, then maybe it would be better to talk about "context-dependent identifiers" or something along these lines? i am mostly struggling with your term "implicit notion", which i don't quite know how to interpret.

[dschulten]

By implicit notion I mean: when an application interprets an HTTP link header or an HTML link element, it can assume that a non-URI @rel value must be a IANA registered rel. Why can it assume that? That fact is not explicit in the link representation, but the application must bring along knowledge about the general implications of an HTTP link header. By being an HTTP link header, the rel attribute implies that its value is either an IANA registered rel or a custom rel. If I may rephrase what you said, the context of an HTTP link makes it clear that the rel is a registered rel.

One more try:
"Serialisations such as RDF that have no contextual notion of unique IANA link relations MAY refer to them with a URI [RFC3986] by prepending them with "http://www.iana.org/assignments/relation/". Note that the resulting strings are not considered equivalent to the registered relation types by many processors, and therefore MUST NOT be used in contexts where simple strings are known to be registered IANA relation types."

[dschulten]

Or maybe more straightforward:

"Applications which have no concept of context-dependent identifiers to support plain strings as IANA registered link relation types MAY refer to them with a URI [RFC3986] by prepending them with "http://www.iana.org/assignments/relation/". Note that the resulting strings are not considered equivalent to the registered relation types by many processors, and therefore MUST NOT be used in contexts where simple strings are known to be registered IANA relation types."

[elf-pavlik]

in HTML/XML (and JSON), it is
trivial to say something like this:

<link href="...." rel="relation"/>

As I understand it:

• in HTML5 the spec itself implies that non URI string values should match those explicitly listed in a spec or registered in blessed registry [1]
• in HTTP Headers, same implication comes from RFC5988 [2]
• AFAIK in JSON each system needs to define their usage of link relations independently since no normative reference exist for that

@dret , do you know of any other specs which in normative way specifies that any string used in a particular context, references a link relation from IANA registry?

Maybe simply stating something in lines:

"In HTTP headers[2], HTML links[1] or other environments which define in normative way usage of link relations from IANA registry, applications MUST use link relations short sting form. In environments which does not allow use of short string form and enforce use of URIs for identifiers, for example all RDF serializations[3], applications SHOULD reference link relations by prefixing their short string form with "http://www.iana.org/assignments/relation/'".

It definitely needs better wording, but as much as possible I see it helpful to keep it simple and to the point, without introducing any conceptually heave ideas.

[1] http://www.w3.org/TR/html5/links.html
[2] https://tools.ietf.org/html/rfc5988#section-6.2
[3] http://www.w3.org/TR/rdf11-new/#section-serializations

[dret]

As I understand it:

• in HTML5 the spec itself implies that non URI string values should
  match those explicitly listed in a spec or registered in blessed
  registry [1]
• in HTTP Headers, same implication comes from RFC5988 [2]
• AFAIK in JSON each system needs to define their usage of link
  relations independently since no normative reference exist for that

the difference here is that HTML(5) and HTTP are talking about links
explicitly, whereas JSON is just some data metamodel. in JSON models
talking about links, you often find the very same link relation
semantics encoded (in various variations) as in HTML/HTTP. here is a
very nice overview:

http://dracoblue.net/dev/overview-of-json-hypermedia-link-formats/

@dret https://github.com/dret , do you know of any other specs which
in normative way specifies that any string used in a particular context,
references a link relation from IANA registry?

there are many (start with above link) and it would be futile and a
mistake to try to list them explicitly/exhaustively. RFC 5988 defines
how link relations types work (strings for registered values, URIs for
extensions), and that's all that needs to be said. anybody using web
linking should be using that model, ot they are on their own.

Maybe simply stating something in lines:
"In HTTP headers[2], HTML links[1] or other environments which define in
normative way usage of link relations from IANA registry, applications
MUST use link relations short sting form. In environments which does not
allow use of short string form and enforce use of URIs for identifiers,
for example all RDF serializations[3], applications SHOULD reference
link relations by prefixing their short string form with
"http://www.iana.org/assignments/relation/'".

not quite, i think. there is no "short string form". the short string
is the only allowed value if you want to properly reference a
registered type. anything else should not be considered a proper
reference to the registered type, to avoid creeping out those "pseudo
values" onto the web.

[elf-pavlik]

not quite, i think. there is no "short string form". the short string
is the only allowed value if you want to properly reference a
registered type. anything else should not be considered a proper
reference to the registered type, to avoid creeping out those "pseudo
values" onto the web.

Above statements don't seem to take into account environments like RDF which require use of URIs, and to my understanding we try here provide a way to still have there a proper reference to the registered type. How about something like "... aplications MUST NOT add 'http://www.iana.org/assignments/relation/' prefix with exception where particular environment does not support use of references other than URIs (for example all RDF serializations)"

[elf-pavlik]

@dret I think we all better trust you and Mark with your spec editorial experience. I would just like to make two requests

1. keeping it as simple as possible and preferably not going into conceptually heavy statements which people may struggle to understand and see as vague
2. offering informative advice about possible consequences of misuse of introduced prefix, and avoiding statements which may seem dogmatic and make people, who have to use URI in media types they work with, feel like they do something wrong

Reopening to discuss that, and to remember we need to finalise the URL (considering things like / vs # ), and perhaps instruct IANA about what to do.

This one I see very much related to #144 and very likely decisions there will influence the final recommended prefix. I guess we may end up with "http://www.iana.org/assignments/relation/#"

[asbjornu]

@dret wrote:

not quite, i think. there is no "short string form". the short string is the only allowed value if you want to properly reference a registered type. anything else should not be considered a proper reference to the registered type, to avoid creeping out those "pseudo values" onto the web.

@elf-pavlik wrote:

Above statements don't seem to take into account environments like RDF which require use of URIs, and to my understanding we try here provide a way to still have there a proper reference to the registered type.

It also seem to not take into account that RFC 4287 has described this algorithm for almost 10 years now.

This one I see very much related to #144 and very likely decisions there will influence the final recommended prefix. I guess we may end up with "http://www.iana.org/assignments/relation/#"

Yes, that would be good. But it would work so much better if the resulting page wasn't just an enormous HTML <table>, but instead divided into sections (<h2 id="{relation}">) that could be referenced individually.

[stain]

BTW, here's my suggested RDFa-from-XSLT approach: (from #39)

https://gist.github.com/stain/d4656bede203b7c3ba4e

[elf-pavlik]

@stain great to see your concrete proposal! I still think that W3C should take responsibility of all the RDF related aspects (possibly using your XSLT) and IANA page could simply link to it using appropriate link relations, as I propose in #144 (comment)

[melvincarvalho]

+1 to http://www.iana.org/assignments/relation/#

Do you even need the final trailing "/"? Doesnt make a huge difference in the grand scheme of things.

May I request that the final resource is CORS enabled?

[dret]

i am starting to wonder if it wouldn't make sense to start a separate document listing a number of requirements for IANA registries (also including #144 and maybe even #40) and how they are exposed. while not all of IANA's registries will need something like this, for many it might be useful, and least some aspects of it, so separating this issue into a standalone document might be useful to make it reusable. but then again, @mnot would be the right person to say whether that's a realistic and reasonable goal to have, or whether this would be too much effort for something that might see less (or no) reuse regardless of the best intentions.

[mnot]

@dret - no, that's been tried and failed before, and I'd like to avoid doing so for now.

All - can we please keep issues discussion on-topic? I'm very happy to have the discussion, but not when it veers all over the place. Thanks.

[jasnell]

@mnot ... +1 to this change. I don't believe @dret's additional constraints are necessary (not that there's anything particularly wrong with them).

[asbjornu]

I'd also say 👍, but with one exception: Drop the trailing /, so we end up with:

http://www.iana.org/assignments/relation#

It is more in line with how such fragment URIs tend to look, and there's nothing to gain by having the trailing slash, is there?

[gkellogg]

Given that relations are all defined in a single resource, I agree that http://www.iana.org/assignments/relation# makes the most sense. Using '/#' would just seem indecisive.

[mnot]

@asbjornu @gkellogg I agree that relation# makes more sense than relation/ but RFC4287 did specify the latter, and this issue is about stability :)

If there's really broad consensus to change it, I'm OK with that, but I wonder if we can determine that here.

Also, is it really that important that they resolve to something relevant/non-404, or is that just Nice to Have?

[asbjornu]

@dret What seems to be missing from your equation is the use-case of distributed creation of link relations, which was the reasoning behind section 4.2.7.2 of RFC 4287, IIRC. I also don't read RFC 5988 the same way as you, which I believe is one of the reasons this issue exists in the first place.

I think the internet community still needs a way to mint proprietary link relations without the overhead of registering them in IANA. I believe that use-case will exist even if the process of registering relations is made a global showcase of bleeding edge user-friendlyness and simplicity.

The solution we came up with in Atom WG to allow for distributed creation of link relations was to use a URI. To make that consistent with the non-URI relations that already existed, we invented a prefix that made http://www.iana.org/assignments/relation/describes and describes equal. Looking back, I think it might have been wiser to obsolete the non-URI relations and mandate the use of the IANA base URI prefix.

Accidentally, the idea of using URIs have shown to fit with other use-cases as well, such as in RDF. However, I do think those are two different use-cases that shouldn't be conflated.

[dret]

On 2016-04-28 01:38, Asbjørn Ulsberg wrote:

@dret https://github.com/dret What seems to be missing from your
equation is the use-case of distributed creation of link relations,
which was the reasoning behind section 4.2.7.2 of RFC 4287, IIRC. I also
don't read RFC 5988 the same way as you, which I believe is one of the
reasons this issue exists in the first place.

for distributed creation, there are extension relation types, which seem
to work just fine in practice, afaict.

https://tools.ietf.org/html/rfc5988#section-4.2

I think the internet community still needs a way to mint proprietary
link relations without the overhead of registering them in IANA.

that's a very different discussion, on whether a registry is the right
pattern to use for keeping track of link relation identifiers. to me the
"overhead issue" is a problem of perception, but than nevertheless is a
problem. but regardless of that, "namespace design" and "namespace
management" are two different issues.

I
believe that use-case will exist even if the process of registering
relations is made a global showcase of bleeding edge user-friendlyness
and simplicity.

then let's look at those use cases. so far i see little problems in
practice. many register their link relations, the registry is growing
slowly but steadily. and for those that see it as a hurdle as you do, i
have helped with the registration process a number of times for
currently evolving w3c specs. i did not do that much, and it did not
take a lot of time or effort, just the willingness to make those values
well-known.

The solution we came up with in Atom WG to allow for distributed
creation of link relations was to use a URI. To make that consistent
with the non-URI relations that already existed, we invented a prefix
that made |http://www.iana.org/assignments/relation/describes| and
|describes| equal. Looking back, I think it might have been wiser to
obsolete the non-URI relations and mandate the use of the IANA base URI
prefix.

maybe. but that train has left the station a long time ago. there really
is no point to discuss that any more, we cannot change the past.

Accidentally, the idea of using URIs have shown to fit with other
use-cases as well, such as in RDF. However, I do think those are two
different use-cases that shouldn't be conflated.

afaict, RDF seems to be the only model that has trouble using non-URI
identifiers. everybody else seems to be happy either way, happily living
in RFC 5988 land using link relation types that are either short names
or strings.

also, please keep in mind that originally, this issue was not about
changing the registered values from strings to URIs. that notion just
crept in and maybe should be factored out anyway. originally, this issue
is only about having dereferencable URIs for link relation types, but
the identifiers that must be used would still be the short names and not
the URI.

[elf-pavlik]

also, please keep in mind that originally, this issue was not about changing the registered values from strings to URIs. that notion just crept in and maybe should be factored out anyway. originally, this issue is only about having dereferencable URIs for link relation types, but the identifiers that must be used would still be the short names and not the URI.

I understood that as of last iteration, depending on application spec marks identifying link relations with URIs as NOT RECOMMENDED but allowed. Which I see enough so that people who have reason to use NOT RECOMMENDED option can still do so.

Now for example, after parsing HTTP Link header, RDF applications can simply store all the links as triples, of course during serializing triples for use in HTTP Link header, application must always remove the http://www.iana.org/assignments/relation/ prefix. While one can argue that each application can choose one's own prefix for that purpose, having a standard prefix to only use it in very specific cases makes thing interoperate better in many cases. For example if application/trig response wants to make information from HTTP Link header also available in the payload as separate named graph.

👍 from me for providing standard prefix, marking it as NOT RECOMMENDED and shortly explaining possible interoperability issue when using it in not appropriate application.

[mnot]

what are "serialisations that explicitly accommodate them"?

E.g., as Atom does, or as RDF probably would.

values will very easily disseminate through perceived format boundaries. for
example, if you have JSON-LD, then you would like to see the registered
values to be used in the actual JSON. but people using RDF tooling may
end up creating URIs, because from their perspective, they have been
using RDF so using URIs was kind of ok. and their JSON-LD toolbox may
not even have support for value mapping when serialising RDF to JSON-LD.

If you implement a parser that ingests links from a serialisation that has such a mapping, it's your responsibility to convert them to registered link relations before serialising them into another format. It needs to be a requirement of the serialisation.

[mnot]

WRT 2 specified vs n -- The problem is that Atom already specifies one extra way to serialise registered relation types, and many have expressed dissatisfaction with that base URI (because it's controlled by IANA, because what's at the URL isn't what is desired, because it isn't a # URI, etc.).

Therefore, I highly suspect we're going to have at least three. Baking the third into this spec raises the chances that we'll get it wrong, for some community (the Semantic Web isn't the only game in town).

As with many things, the right number is likely to be zero, one, or many.

[dret]

On 2016-04-28 18:13, Mark Nottingham wrote:

If you implement a parser that ingests links from a serialisation that
has such a mapping, it's your responsibility to convert them to
registered link relations before serialising them into another format.
It /needs/ to be a requirement of the serialisation.

i agree. but isn't that saying that if you claim to use/expose link
relation types as spec'ed and registered, you MUST use the identifiers
in their single correct representation? and if so, then why even say
that in some contexts, people may do things differently?

i understand the RFC 5988 language to acknowledge the RFC 4287 legacy,
but by now we might be over that hump of introducing and then having to
deal with aliases. i haven't seen any of these in the wild for quite a
while. people haven't used them, afaict, because they weren't interoperable.

to me, this is like knowing that in some implementations/contexts,
people decide to use numbers instead of media type identifiers. there's
nothing we can do to stop them from doing it, but there's no need to
even acknowledge that it's happening. if you want to represent a media
type, it must be in the x/y form; anything else is not a media type
identifier.

[[ btw, anybody know of an dataset of HTTP headers harvested in the wild
(preferably even over time) that we could analyze and see which link
relations show up in link headers? not necessarily a representative way
of measuring link relation type usage in general, but maybe interesting
nevertheless. ]]

[elf-pavlik]

WRT 2 specified vs n -- The problem is that Atom already specifies one extra way to serialise registered relation types, and many have expressed dissatisfaction with that base URI (because it's controlled by IANA, because what's at the URL isn't what is desired, because it isn't a # URI, etc.).

I would see comments on current http: prefix more as proposals for various possible improvements than dissatisfaction that one standard prefix exists. As of today, registered link relations act just as unique identifiers and to my knowledge no one expects to discover additional information by dereferencing them. Possibly at some point in the future IETF will find interest to leverage this currently dormant potential, but as of today I believe everyone, who shared mentioned feedback, can live with agreeing just on the standard http prefix. I think that keeping question, what response one can expect when dereferencing link relation URIs, as separate issue makes a lot of sense here. Once we agree on the prefix it can take as much time as needed and available to work on answering that question.

Not sure if we still should take just a quick look at HTTP vs HTTPS ? AFAIK schema.org started moving their prefix to HTTPS http://schema.org/docs/faq.html#19

[mnot]

@dret it's pretty clear that there are some communities that want to use them, so some guidance would help avoid common pitfalls.

I don't think that having One True Prefix in the spec is going to be helpful, because AIUI there are some fairly exacting requirements on how that namespace is run, both in terms of the URIs and potentially what happens when you dereference them (based on discussion with @timbl).

In this approach, a serialisation of links like JSON-LD can use URIs for registered relation types as it wishes, and have appropriate assurances that it controls that name space; much easier than offloading that task to IANA.

Furthermore, as long as it assures that they're converted back to "native" registered link relations at the appropriate time, it can interoperate well with other applications / serialisations, whether they recognise the prefix or don't.

[dret]

On 2016-05-02 18:05, Mark Nottingham wrote:

@dret https://github.com/dret it's pretty clear that there are some
communities that want to use them, so some guidance would help avoid
common pitfalls.

i am sorry to be pedantic, but what is "them"? i think we have to be
really clear about what we are talking about, and in the discussions so
far, i think to things get mixed up:

• the normative lexical value of registered relation types.
• stable URIs that can be used to refer to the types, but are not the
  lexical value of the type.

sorry if this is a dumb example, but just to make it clear, it is like
this when talking about language tags (a la RFC 5646)

• the normative lexical value for english is "en"
• http://www-01.sil.org/iso639-3/documentation.asp?id=eng is the URI
  that is closest to a being a URI for the "en" language tag.

i have to admit that i have a hard time distinguishing the cases when
the discussion is about changing the lexical value (or adding a second
allowed lexical value, which is a URI), and when it is about being more
disciplined in having stable and well-defined URIs.

I don't think that having One True Prefix in the spec is going to be
helpful, because AIUI there are some fairly exacting requirements on how
that namespace is run, both in terms of the URIs and potentially what
happens when you dereference them (based on discussion with @timbl
https://github.com/timbl).

+1, i think it is unlikely that IANA's substantial registry
infrastructure can be changed easily. and so far i have not heard any
argument on why you would need the URIs to be dereferencable: they are
identifiers, and their semantics are defined by the specs that register
them. the registry is there to make those specs discoverable. even if it
were possible to dereference the URIs and you would get some RDF as a
result, it would do little more than containing a link to spec that
registered the value, and effectively say "go and read this spec".

In this approach, a serialisation of links like JSON-LD can use URIs for
registered relation types as it wishes, and have appropriate assurances
that it controls that name space; much easier than offloading that task
to IANA.

just to make sure: the URIs would not actually show up in JSON values,
right? i assume they would only show up if somebody put on their RDF
goggles and processed the JSON as JSON-LD and then looked at the
resulting RDF? and when serializing RDF as JSON via JSON-LD the opposite
thing would happen and the URIs would get serialized as the registered
strings?

[mnot]

The lexical value of the type as defined in the standard is not what may appear on the wire, depending upon the transformations that a serialisation applies to it.

Trivial (and common) examples of such a transformation are character encoding, compression and encryption.

The draft is saying that other transformations are possible, including mapping registered relation types into a separate space, for the convenience of the users of that serialisation.

How JSON-LD and friends decide to handle this is up to them.

If you can suggest ways to clarify this in the spec, it'd be much appreciated.

[dret]

On 2016-05-02 20:09, Mark Nottingham wrote:

The lexical value of the type as defined in the standard is not what may
appear on the wire, depending upon the transformations that a
serialisation applies to it.

agreed, but that is entirely out of scope of the spec, is it not? the
spec says which lexical value represents a registry entry.

Trivial (and common) examples of such a transformation are character
encoding, compression and encryption.

sure, but these are layered concerns and do not affect the spec.

The draft is saying that other transformations are possible, including
mapping registered relation types into a separate space, for the
convenience of the users of that serialisation.

i am still not clear about why that needs to be said. of course if
there's agreement on two sides, they can apply whichever transformation
makes them happy and as long as the mapping works robust in both ways,
things will work out.

we do not say that a value can be compressed or encrypted or unicode
encoded, because we don't have to. what's different here?

If you can suggest ways to clarify this in the spec, it'd be much
appreciated.

if we keep the model that registered values have one lexical value which
is the simple string we have today, then i think there is no need to
talk about possible ways to map this string to URIs. it could be mapped
to many other things as well, as you point out.

my concern is that this language is confusing readers and developers to
assume that the URIs are legitimate lexical representations, which
they are not. i don't see which value this adds, and i see a risk of
inviting misunderstandings.

[mnot]

#142 has a TODO to add a section about creating new serialisations. I think moving this text into that might help.

[asbjornu]

@mnot Thanks for finally providing a conclusion on this issue. The more I think about it, the more I agree with you in that it's not up to rfc5988bis to provide mapping to other serialisations of link relations. That can and probably should be solved externally in another RFC or W3C REC.

[elf-pavlik]

just to make sure: the URIs would not actually show up in JSON values, right? i assume they would only show up if somebody put on their RDF goggles and processed the JSON as JSON-LD and then looked at the resulting RDF? and when serializing RDF as JSON via JSON-LD the opposite thing would happen and the URIs would get serialized as the registered strings?

JSON - 'application/json'
doesn't specify how to use link relations, "rel": "next" can as well mean the name of a cat

JSON-LD - 'application/ld+json' (plus 3 profiles)
HAL - 'application/hal+json'
JSON API - 'application/vnd.api+json'
UBER - 'application/vnd.amundsen-uber+json'
Mason - 'application/vnd.mason+json'
Siren - 'application/vnd.siren+json'
All above have some differences in how to serialize link relations, some use relation lexical form in name/key in objects, some as value of "rel":. In JSON-LD expanded profile they would appear as URIs used as name/key in objects, also sometimes as value in case of reification or n-ary relations. In JSON-LD compacted profile, one could provide @context which would alias all URIs denoting link relations to short strings matching their lexical form in IANA registry. I could consider writing a script which would generate such @context from IANA page, than one could just add link to it to "@context": [].

@dret If you would like to continue discussing use of link relations in JSON and JSON-based media types, maybe we could move it to comments of this article: https://dracoblue.net/dev/overview-of-json-hypermedia-link-formats/ ?

[sbp]

The more I think about it, the more I agree with you in that it's not up to rfc5988bis to provide mapping to other serialisations of link relations. That can and probably should be solved externally in another RFC or W3C REC.

@asbjornu Did this ever actually happen?

[asbjornu]

@sbp not to my knowledge, no.

[elf-pavlik]

I know of https://www.w3.org/ns/iana/link-relations/relation but to my knowledge it doesn't have any official status. Maybe @csarven has some more information about it.

Personally I think that if someone defining new relation wants it to be available as full IRI, they should just use full IRI and don't register short string. With this in mind some kind of directory with common full IRI link relation could be useful complementary reference to make it easier for community to discover existing relations. Some arguments for registering short string are purely for making them known to others. It would be great to have similar option for full IRI relations.

[sbp]

@elf-pavlik Thanks. The W3C have a persistence policy at https://www.w3.org/Consortium/Persistence which mentions that everything starting "https://www.w3.org/ns/" will be carefully maintained. Of course anyone can make and maintain URI aliases for the IANA link relation registry entries. I was just surprised that the IANA would consider it out of scope to do this themselves and create an obviously canonical source, especially since they're already maintaining a CSV version of the registry. Maintaining JSON-LD or N-Triples or something would not be much more work. Certainly not as onerous a task as @mnot seemed to fear it would be!

[melvincarvalho]

There's also:

https://w3id.org/

So, after all this time, I'm guessing that IANA doesnt really want to prioritize throwing cycles at this

I did push for quite a few years for keys to be used as nicely self-describing http URIs, conforming to link data standards

From my experience, I've found that a large chunk (perhaps majority) of developers are content with strings and short names. My conclusion is that rather than trying to get people to conform to Linked Data, perhaps we should try and make Linked Data conform to real world usage, and allow normal strings as keys, rather than only (http) URIs

So, I'll withdraw my previous requests, and if IANA has cycles to address this so much the better