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:

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 https://github.com/mnot/I-D/issues/144#issuecomment-149531806

[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 :+1:, 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?

[dret]

On 2015-10-29 07:40, Mark Nottingham wrote:

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

it's nice to have. the essential thing is that the registered values are identifiers, so the constructed URIs are a nicety. but it would be really convenient if somebody asked "what is this registered value all about?", if such a URI could be used to answer that question succinctly by pointing to the registry entry. and it really isn't a hard thing to make them work, so why not do it well?

[mnot]

If we were working from a clean slate, that would be easy. We're not.

[asbjornu]

@mnot Yes, RFC 4287 specify the use of / as the separator instead of #:

Registry of Link Relations (Section 7), and thus to the IRI that would be obtained by appending the value of the rel attribute to the string "http://www.iana.org/assignments/relation/". The value of "rel" describes the meaning of the link, but does not impose any behavioral requirements on Atom Processors.

A resulting string after processing would thus be http://www.iana.org/assignments/relation/first. In order to be backward compatible with that scheme, we can't introduce #. I wish we had the foresight to specify # back in the early 2000's when we were dabbling with this, but that's too late now.

What's nice, though, is that http://www.iana.org/assignments/relation/first redirects to http://www.iana.org/assignments/link-relations/link-relations.xhtml, which is a behavior I assume no one expects to a degree that they have baked it into their applications. It should therefore be possible to instead redirect to http://www.iana.org/assignments/relation#first (which imho should be the canonical URL for link relations; not http://www.iana.org/assignments/link-relations/link-relations.xhtml) without breaking anything.

[mnot]

@asbjornu sounds reasonable, although some people will undoubtedly copy the resulting # URL and use it to identify :(

The other thing we could do is auto-generate a file for each relation. I'm not thrilled with that, though.

[asbjornu]

@mnot Auto-generating files would then make http://www.iana.org/assignments/relation/first return 200 OK instead of 302 Found? If so, that's indeed a solution that would be both backwards and forwards compatible. Why aren't you thrilled with that solution?

[melvincarvalho]

Some thoughts

• http://www.iana.org/assignments/relation/# is absolutely fine. That's how I do my identity ( http://melvincarvalho.com/#me ). If it's already in an RFC probably makes some sense to stick to it.
• That the resource dereferences is less important than that a normative resource exists. This is something that will be very useful in implementations today. Currently my clients store HTTP headers and having a namespace for them will help to improve the data integrity.
• Redirects can be a pain to work with, especially with CORS. From my experience, best avoided, and using plain old HTTP 200 is easy for software to deal with

[asbjornu]

@melvincarvalho:

• It's not http://www.iana.org/assignments/relation/# that is in an RFC, it's http://www.iana.org/assignments/relation/ without the # that's in RFC 4287. So introducing # would be a breaking change regardless of the trailing slash.
• Being able to dereference the URI is important from an extensibility and usability point of view. It's much easier to figure out what something is by being able to plock the URL into your browser. From there, it's much easier to add metadata to the HTML (or whatever) document being returned, in the form of HTTP headers (such as the Link header), RDFa, and whatnot.
• Good point wrt. CORS. @mnot's idea of minting new resources on each full ("prefixed") relation URI would solve that quite elegantly. Although it isn't a thrilling idea, according to him.

[mnot]

@asbjornu: It complicates the interaction with IANA considerably, and we can't reasonably expect them to do it on their own.

[elf-pavlik]

Maybe HTTP 303 as FOAF does it?

$ curl -I http://xmlns.com/foaf/0.1/knows
HTTP/1.1 303 See Other
Date: Fri, 30 Oct 2015 13:05:32 GMT
Server: Apache/2.4.7 (Ubuntu)
Access-Control-Allow-Origin: *
Location: http://xmlns.com/foaf/spec/
Content-Type: text/html; charset=iso-8859-1

although some people will undoubtedly copy the resulting # URL and use it to identify :(

I think that people who don't pay attention to use of appropriate URL will use technologies which allow simple use of registered strings.

Also http://www.iana.org/assignments/relation/first could do HTTP 303 redirect to #144 and machines would find all the information there without need for # fragments, while people could just search the page for relation they looked for (not perfect but still way better than 404)

[dschulten]

I want to support Elf's point. In the RDF world it is apparently quite customary to have redirects for canonical URIs, for instance

http://purl.org/dc/terms/abstract redirects to http://dublincore.org/documents/2012/06/14/dcmi-terms/?v=terms#abstract

and nobody seems to have any problem with that in RDF land. It certainly helps that the redirection points to a URI that really does not look very canonical :-)

Maybe we can replicate that by redirecting from http://www.iana.org/assignments/relation/next

to some fancy fragment identifier such as http://www.iana.org/assignments/link-relations/link-relations.xhtml#transient-next-non-canonical

[melvincarvalho]

I'd really avoid this FOAF and DCT (anti?) pattern. It's a pain to deal with redirects. And I believe, to this day both those vocabs have problems with CORS. We've been trying for years to fix that, and it's technically a challenge, even for experienced coders such as @danbri. There's no reason to split up a document into mini files in that way, and is a maintenance burden. I spent a long time trying to work out the motivation for this kind of pattern, and it boils down to "it looks nice". If the list was several MB large, I could understand it.

[danbri]

FOAF is not broken into "files". Screwing around with Apache configurations is a giant PITA.

The reason we went with / rather than # was that at the time (15 years ago) it was far from clear that using #blah on a content negotiable URI was sensible. Plus it didn't work for bigger things like Wordnet without forcing you to make a single giant download.

[dschulten]

@melvincarvalho:

Am 30.10.2015 16:13 schrieb Melvin Carvalho notifications@github.com:

I'd really avoid this FOAF and DCT (anti?) pattern. It's a pain to deal with redirects. And I believe, to this day both those vocabs have problems with CORS. We've been trying for years to fix that, and it's technically a challenge, even for experienced coders such as @danbri. There's no reason to split up a document into mini files in that way, and is a maintenance burden. I spent a long time trying to work out the motivation for this kind of pattern, and it boils down to "it looks nice". If the list was several MB large, I could understand it.

Maybe I misunderstand you completely, but what do you propose, then? Having a clean URL prefix http://www.iana.org/assignments/relation# that both is a breaking change wrt to Atom and doesn't dereference? If it doesn't dereference, why is CORS an issue at all?

[elf-pavlik]

If we were working from a clean slate, that would be easy. We're not.

from http://tools.ietf.org/search/rfc4287#section-4.2.7.2

If a name is given, implementations MUST consider the link relation type equivalent to the same name registered within the IANA Registry of Link Relations (Section 7), and thus to the IRI that would be obtained by appending the value of the rel attribute to the string "http://www.iana.org/assignments/relation/"

IMO HTTP 303 redirects for all URIs starting with mentioned prefix already defined by rfc4287 should work just fine. Implementations which chose to dereference those URIs, should cache response received after following redirect from URI of any relation, this way not needing to try fetch description of each relation one by one. I guess details of what such response should contain fits more #144

@gkellogg from where did you pick mentioned in https://github.com/ruby-rdf/rdf-vocab/issues/31 http://www.iana.org/assignments/link-relations/ does any spec recommends it?

[gkellogg]

It looks like http://www.iana.org/assignments/link-relations/ was used in error when the vocabulary was moved. The issue is created for people who this may affect have a chance to speak up. However, as it's used as a convenience, it would only be likely to be a problem when interacting with systems that used the previous value stored in a triple store.

[dschulten]

Would IANA be willing to reorganize today's redirects and return 200 OK for http://www.iana.org/assignments/relation?

We have:

1. http://www.iana.org/assignments/relation/* redirects to http://www.iana.org/assignments/link-relations
2. http://www.iana.org/assignments/link-relations/* redirects to http://www.iana.org/assignments/link-relations/link-relations.xhtml
3. http://www.iana.org/assignments/link-relations/link-relations.xhtml finally answers 200 OK

Can that be changed so that:

1. http://www.iana.org/assignments/relation returns 200 OK with a representation that describes the rels and ideally has fragment identifier targets for the rels?
2. http://www.iana.org/assignments/link-relations redirects to 1
3. http://www.iana.org/assignments/link-relations/* redirects to 1 (includes link-relations.xhtml)
4. http://www.iana.org/assignments/relation/<whatever> redirects to http://www.iana.org/assignments/relation#<whatever> instead of today's redirect to link-relations.xhtml (as proposed by @asbjornu, who argued that this change of redirection is not likely to break anything. I also doubt that Atom clients or services use the fully qualified URL as rel because that would be a misunderstanding of the Atom RFC)

Only if IANA is willing to return 200 OK for http://www.iana.org/assignments/relation it makes sense to go forward with http://www.iana.org/assignments/relation# as canonical URL prefix without redirects that seem to cause CORS problems.

If IANA is not willing to make that change, then RFC5988bis could just make http://www.iana.org/assignments/relation/ the canonical URL prefix and we are done. All necessary redirects are in place already and we are in line with Atom.

[dschulten]

@asbjornu Do I read you correctly that although you said

In order to be backward compatible with that scheme, we can't introduce #.

your final conclusion was that you still want "relation#" to be the new canonical URL prefix? In that case I think @mnot's concern that people would wrongly copy the resulting # URL was a misunderstanding, because people would be right doing so.

[melvincarvalho]

@dschulten I'm not making a proposal. I'm merely pointing out that this would be a valuable thing to standardize. Obviously if an HTTP URI is dereferenable that's much better than if it doesnt. I'm also pointing out from implementation experience 303s are a huge challenge to deal with both from the client and server perspective, especially if you want it to be CORS enabled.

[gkellogg]

How about returning 200 for http://www.iana.org/assignments/relation/ with the content of http://www.iana.org/assignments/relation/ containing the RDFS definitions, and also the Location header of http://www.iana.org/assignments/relation/. That seems to be an accepted pattern now and avoids redirection.

[elf-pavlik]

To my understanding URIs for each relation e.g. http://www.iana.org/assignments/relation/alternate would sill need to redirect to that page which describes all of them. Assuming that prefix recommended by rfc4287 will not change to one with #

[dschulten]

@elf-pavlik it already redirects, and even twice via /link-relations ☺

[stain]

So if we already have the redirections in place, and the RFC already says they end with / which is trickier to change now, then something like my XSLT to include such RDFa statement should be the main thing that is needed.

You are not required to follow the HTTP links (unless you want to) as:

1) The RFC can define the namespace 2) The RDFa on the registry page will include all the statements.

In the spec you can simply say something like:

Applications which require an absolute URI, e.g. producing Linked Data in RDF, MUST use the http://www.iana.org/assignments/relation/ namespace for IANA registered types, and only for IANA registered types. For instance, the registered type alternate is represented as the absolute URI http://www.iana.org/assignments/relation/alternate."

[asbjornu]

@stain Isn't it a problem that http://www.iana.org/assignments/relation/alternate redirects to ?http://www.iana.org/assignments/link-relations/link-relations.xhtml without a fragment identifier? Or will sprinkling RDFa on that HTML page suffice?

I think we need to define (in RFC 2119 parlance) separate requirements for three different types of applications. Let's name them RDF Applications, Legacy Applications and Other Applications, for simplicity. I think each application need separate requirements. Here are some pretty random requirements that probably don't go far enough in some areas and probably go way too far in others:

RDF Applications

RDF Applications are applications producing Linked Data in RDF that require the relation types to be (expanded to) full URIs, such as RDF/XML, RDFa and JSON-LD.

1. RDF Applications MUST use the http://www.iana.org/assignments/relation/ namespace for IANA registered relations. For instance, the registered type alternate is represented as the absolute URI http://www.iana.org/assignments/relation/alternate.
2. RDF Applications MUST NOT use the http://www.iana.org/assignments/relation/ namespace for relations not registered in IANA. They SHOULD instead find relation types registered elsewhere, such as RDFS, Dublin Core, schema.org, etc. For instance, the RDFS rest relation should be represented as the absolute URI http://www.w3.org/2000/01/rdf-schema#rest.

Classic Applications

Classic Applications are applications producing formats that have existing and defined semantics for implicitly namespaced (or prefixed) relation type strings, such as HTML, Atom and the HTTP Link header.

1. Classic Applications MUST NOT use http://www.iana.org/assignments/relation/ namespace for IANA registered relations. For instance, the registered type alternate should be represented as the opaque string alternate and not as the absolute URI http://www.iana.org/assignments/relation/alternate.
2. Classic Applications SHOULD use a full URI and not opaque strings for relations that are not registered in IANA. For instance, the RDFS rest relation should be represented as the absolute URI http://www.w3.org/2000/01/rdf-schema#rest.

Other Applications

Other Applications are applications that don't produce RDF, but at the same time don't have defined semantics for implicitly namesapced (or prefixed) relation type strings.

1. Other Applications SHOULD use the http://www.iana.org/assignments/relation/ namespace for IANA registered relations. For instance, the registered type alternate is represented as the absolute URI http://www.iana.org/assignments/relation/alternate.
2. Other Applications SHOULD use a full URI and not opaque strings for relations that are not registered in IANA. For instance, the RDFS rest relation should be represented as the absolute URI http://www.w3.org/2000/01/rdf-schema#rest.

Structure

The above can (and probably should) be restructured so each requirement is stated and identified and then referenced from sections describing the requirements for each application type. This allows the requirements to be easily conveyed in a matrix, for instance.

[dret]

it's a bit ironic that in the text above all applications (except one) are described as "legacy applications", whereas the only one that happens to have home-made problems with non-URI identifiers is becoming the one true way forward. what i think would be a bad idea is to create the impression that URIs are valid identifiers. the registry contains strings, and these are valid identifiers. creating legitimate aliases for pretty much anything is a sure-fire way into non-interop, so please let's not do that. and looking ahead, i am wondering what's next. force media types to also be URIs? which other registries come next? IANA currently manages 1885 registries, and the vast majority of these have non-URI entries. all the "legacy applications" using those registries have been doing fine until now, and it's hard to see the problem, except for one specific technology not having a way to deal with non-URI identifiers.

[danbri]

This use of "Legacy" looks disrespectful of mainstream approaches (who have respectable reasons for their choices); I strongly recommend against that terminology.

[asbjornu]

@danbri The use of the word Legacy was not intended to be disrespectful. The above text is also in no way intended to be used in a specification. "Legacy" was just a label I had to invent in order to try to organize my thoughts on how we can classify the different applications of link relations.

Is Traditional a better word? I'm open to ideas and am in no way attached to the names I've picked. I do think I've managed to separate the three different types of applications successfully, though. If you disagree, please let me know.

it's a bit ironic that in the text above all applications (except one) are described as "legacy applications"

@dret Wrt "legacy", please see above.

whereas the only one that happens to have home-made problems with non-URI identifiers is becoming the one true way forward.

Incorrect. Atom had the same problem more than 10 years ago. What other algorithm or process would you devise to make identifiers extensible?

what i think would be a bad idea is to create the impression that URIs are valid identifiers. the registry contains strings, and these are valid identifiers. creating legitimate aliases for pretty much anything is a sure-fire way into non-interop, so please let's not do that.

That's a valid point and one I agree we need to address thoroughly.

and looking ahead, i am wondering what's next. force media types to also be URIs?

Media types are already sufficiently extensible through the vnd. prefix.

which other registries come next? IANA currently manages 1885 registries, and the vast majority of these have non-URI entries.

I have no idea, to be honest, but I think a majority of those 1885 registries should and will remain untouched by anything we choose to do with the link relation registry.

But if I were to boil it down to what the core of the problem is, I think it is extensibility. If a registry defines a way to extend its identifiers with minimum bureaucracy, it should interoperate just fine. If the extension process involves using URI prefixes; even better. If a registry is impossible to extend without publishing an RFC, it's a dead end for most uses of its identifiers.

all the "legacy applications" using those registries have been doing fine until now, and it's hard to see the problem, except for one specific technology not having a way to deal with non-URI identifiers.

I disagree. Not having a distributed way to extend identifiers places a huge potential burden on anyone who wants to use the registered identifiers. Because at one point, the registered identifiers won't solve all the problems at hand, won't fit the application semantics or won't contain the identifiers the application requires. That's a fact of life regardless of the class of application and which technology it uses.

[danbri]

Maybe 'classic' or 'mainstream'? Perhaps I'm over-sensitive on this point but having seen 15 years of semweb advocacy try to describe all prior efforts as 'legacy', and having seen the reactions (offense, laughter, ...) I do suggest anything but 'legacy' would be an improvement. Traditional implies they are old-fashioned; 'classic' does too but seems slightly softer. Mainstream is vague but straightforward.

[asbjornu]

@danbri I like "Classic". I've updated my proposal. I don't want to be mistaken for a semweb advocate, though, since I've just started trying to understand what it is through my involvement in Hydra, which is based on JSON-LD, which (quite invisibly, imho) is powerd by RDF. :wink:

[dret]

On 2015-11-06 14:10, Asbjørn Ulsberg wrote:

But if I were to boil it down to what the core of the problem is, I think it is extensibility. If a registry defines a way to extend its identifiers with minimum bureaucracy, it should interoperate just fine. If the extension process involves using URI prefixes; even better. If a registry is impossible to extend without publishing an RFC, it's a dead end for most uses of its identifiers.

you don't need an RFC. registration is via the mailing list, and all you need is some document saying what your link relation represents (and i think that's a fair ask), and then you can send a request to the list. many/most choose to write short RFCs, but that's probably just because they are a nice way to get some feedback and consensus.

I disagree. Not having a distributed way to extend identifiers places a huge potential burden on anyone who wants to use the registered identifiers. Because at one point, the registered identifiers won't solve all the problems at hand, won't fit the application semantics or won't contain the identifiers the application requires. That's a fact of life regardless of the class of application and which technology it uses.

have a close look at how link relations work today:

• if you want to use a registered value, then use an existing one, or submit a new one and get it registered. using such a string then means that it's supposed to be registered.
• if you don't feel like using registered values, you can always use URIs, and then it's implicit that the link relation is not a registered one, but one that somebody made up. if you want, you can use HTTP URIs and put some documentation there (and that's how we did it in my previous company), but that's just you being nice to devs.

[asbjornu]

you don't need an RFC. registration is via the mailing list, and all you need is some document saying what your link relation represents (and i think that's a fair ask), and then you can send a request to the list. many/most choose to write short RFCs, but that's probably just because they are a nice way to get some feedback and consensus.

Say you want to publish a simple JSON API for your local library. You do it mostly free of charge and good will. Given this or similar situations, I'd say that just being able to figure the registration procedure out is a major task, let alone complete it. Although joining a mailing list and sending an e-mail is simple enough, it's the whole process, starting from pretty user unfriendly plain text RFC's, that's just not optimized for dialogue and participation.

I know this is a bigger problem to fix than what can be achieved in one registry and the RFC describing how it works, but until that bigger problem is fixed, the process of registering link relations needs to be distributed. And extensibility through the use of URIs works pretty well, I think.

if you want to use a registered value, then use an existing one, or submit a new one and get it registered. using such a string then means that it's supposed to be registered.

I agree that all strings should be registered. But with the current process, I think that's too much to expect.

if you don't feel like using registered values, you can always use URIs, and then it's implicit that the link relation is not a registered one, but one that somebody made up.

Yes, this is what RFC 4287 and 5988 already specifies. And that makes unregistered link relations work better with RDF than registered, which is the problem we're trying to solve here.