Switch from URI to IRI terminology in WebID spec

[csarven]

Originally recorded/tracked in https://www.w3.org/2005/Incubator/webid/track/issues/71

Considerations (requirements, advisory..) to include in the WebID 1.0 spec.

• Use in the context of the HTTP protocol and data
• Normalization
• Security

Other considerations:

• Existing deployments and upgradeabillity

[pmcb55]

Hi @csarven/all,

So I completely agree with this. It seems this was originally raised over 11 years ago(!), and in trying to follow all the mailing list threads since then, I don't think I've come across a single objection from anyone in all that time.

The very original comment from @pchampin @Antoine-Zimmermann (here) still makes perfect sense to me today, i.e.:
"all current W3C specs in the Semantic Web activity now use IRI, you should replace URI with IRI everywhere, I think;"

So what needs to happen to close this issue, and then do the search-and-replace...?

If it helps, here's my formal +1 😄 !

[csarven]

Pat, do you mean besides:

Considerations (requirements, advisory..) to include in the WebID 1.0 spec.

• Use in the context of the HTTP protocol and data
• Normalization
• Security

Other considerations:

• Existing deployments and upgradeabillity

?

You're welcome to create a PR addressing those and other considerations (that people have) so that we can move towards "closing this issue".

(And, no, I don't believe something like this is a simple matter of "search-and-replace", although life would indeed be a lot simpler if that's all we had to do :))

[TallTed]

This is an ongoing cyclical discussion.

URL, URI, and IRI are roughly equivalent in most readers' minds. Yes, there are technical distinctions, but surprisingly many people who encounter IRI think it's a typo for URI. URL has managed to replace URI as the superclass of all identifiers, even though the L for location is obviously a subset of identifier (and URN has almost completely fallen to the wayside).

Note, for instance, What is Happening with "International URLs", dated 2015-08-25, which cites the then current URL spec.

The now current URL Living Standard — Last Updated 8 December 2023 says —

Standardize on the term URL. URI and IRI are just confusing. In practice a single algorithm is used for both so keeping them distinct is not helping anyone. URL also easily wins the search result popularity contest.

I'm in several WGs at the moment. All of them have followed the above guidance for human-focused documentation, though all have also recognized the historical and technical differences between URL, URI, and IRI.

I am more than hesitant to suggest that we should treat issues logged 10 years ago as if they were recent, and even more hesitant to accept a comment of similar age ("Comments on current editor's draft (Web 1.0, 3rd October 2012)") as if it were currently accurate, especially as it's being mis-cited above (it's not from nor even cited by @pchampin; it's from @Antoine-Zimmermann and dated 23 Oct 2012 18:53:02 +0200).

[jacoscaz]

The now current URL Living Standard — Last Updated 8 December 2023 says —

Standardize on the term URL. URI and IRI are just confusing. In practice a single algorithm is used for both so keeping them distinct is not helping anyone. URL also easily wins the search result popularity contest.

Very much +1 on this. Furthermore, within the context of WebID, URL is actually what makes the most sense. WebIDs must dereference to profile documents and therefore must not only be identifiers (IRI / URI) but also locators (URL). Based on my personal experience, the "internationalized" characteristic of IRIs is pretty much assumed to apply to URLs, too, whereas the distinction between identifier and locator is much more likely to produce issues.

[pmcb55]

Hiya @TallTed,

This is an ongoing cyclical discussion.

Yep, exactly - and my strong fear is that it'll continue to cycle ad infinitum, unless we once-and-for-all resolve it by being completely unambiguous and explicit. That's precisely what the RDF Recommendation does, in section 3.2 IRIs. And doesn't that spec still remain the very foundation for everything we're discussing here...?

Surely all the arguments being made here (i.e., 'URI/IRI are confusing', 'most people conflate them anyway', 'there's only the one algorithm', etc.) should apply to RDF itself too, right? So logically, should the upcoming RDF 1.2 work adopt this 'let's just use URL' position too...?

URL, URI, and IRI are roughly equivalent in most readers' minds. Yes, there are technical distinctions, but surprisingly many people who encounter IRI think it's a typo for URI. URL has managed to replace URI as the superclass of all identifiers, even though the L for location is obviously a subset of identifier (and URN has almost completely fallen to the wayside).

Yep, there sure are "technical distinctions", and this work is a technical specification - so aren't those technical distinctions important (see this "Java doesn't support IRI?")?

Yes, it's unfortunate that people might wrongly conflate, or misunderstand, or mixup these terms, but I think it would be a big mistake to attempt to paper-over these distinctions by misusing the term URL in this specification when we all know we really, technically, mean IRI (again, as per the RDF spec).

Note, for instance, What is Happening with "International URLs", dated 2015-08-25, which cites the then current URL spec.

The now current URL Living Standard — Last Updated 8 December 2023 says —

Standardize on the term URL. URI and IRI are just confusing. In practice a single algorithm is used for both so keeping them distinct is not helping anyone. URL also easily wins the search result popularity contest.

Yep sure - but those WhatWG folks aren't building on the foundation of RDF (are they?). So I don't think they have any strong need to be consistent with RDF's foundations (i.e., IRIs).

I'm in several WGs at the moment. All of them have followed the above guidance for human-focused documentation, though all have also recognized the historical and technical differences between URL, URI, and IRI.

Ok, but are those WGs founded on (or strongly related to) RDF I wonder? If so, then if they ignore the clear, explicit example of RDF itself (i.e., it's IRIs - full-stop, no discussion), then aren't they simply adding to the confusion by using anything other than IRIs (since RDF mandates IRIs - full-stop, no discussion)...?

And isn't this WebID work intended to become a formal technical specification (and so it shouldn't be watered-down technically to appease looser, non-normative needs of 'human-focused documentation', should it)?

I am more than hesitant to suggest that we should treat issues logged 10 years ago as if they were recent, and even more hesitant to accept a comment of similar age ("Comments on current editor's draft (Web 1.0, 3rd October 2012)") as if it were currently accurate, especially as it's being mis-cited above (it's not from nor even cited by @pchampin; it's from @Antoine-Zimmermann and dated 23 Oct 2012 18:53:02 +0200).

Yeah sorry - I've editted/fixed the attribution above. But I don't understand why this suggestion 'being old' would be relevant. The sentence, "all current W3C specs in the Semantic Web activity now use IRI, you should replace URI with IRI everywhere, I think;" seems perfectly correct to me - i.e., it's perfectly applicable right now, today, not matter who says it, or when it was 'originally said'.

So in summary, I see the consistent use of IRI as the only way to prevent the annoying ongoing confusion over URL/URI/IRI, and to stop the cyclic discussion. In other words, this all goes away if all Semantic Web related technical specifications simply followed the example of the foundational RDF Recommendation itself. (Note, they don't have to repeat the Note in section 3.2 IRIs, just reference it).

If you insist on persisting with URL, then I feel you're only continuing the confusion and cyclic discussion (since it obviously misaligns with the extremely clear RDF spec (so you'll always have to explain/justify that misalignment)). And I don't think anybody is going to propose making this consistent the other-way-around - i.e., by changing the RDF Recommendation to use URL (although RDF 1.2 is in the works, so now's your chance to suggest it 😄 !)).

So flip to IRI and be consistent with RDF...
...or stick with URL and continually explain and justify the misalignment with RDF.

[pmcb55]

Hiya @jacoscaz

The now current URL Living Standard — Last Updated 8 December 2023 says —

Standardize on the term URL. URI and IRI are just confusing. In practice a single algorithm is used for both so keeping them distinct is not helping anyone. URL also easily wins the search result popularity contest.

Very much +1 on this. Furthermore, within the context of WebID, URL is actually what makes the most sense. WebIDs must dereference to profile documents and therefore must not only be identifiers (IRI / URI) but also locators (URL).

Yeah, the fact that WebID's are really IRLs(!) is indeed a wee bit niggly. But for me, it's still fine to consider them first-and-foremost identifiers. Yep, I do get your point, that they do have to be dereference-able to be 'true WebIDs', but I don't think that justifies breaking from RDF's mandate for IRIs (and I certainly don't want anyone to coin 'IRL' as a new acronym).

So yep, you make a valid point, but for me it's not strong enough to justify diverging from the RDF foundation of IRI.

Based on my personal experience, the "internationalized" characteristic of IRIs is pretty much assumed to apply to URLs, too,

Maybe I'll just point again to "Java doesn't support IRI?" 😄 !

[TallTed]

once-and-for-all resolve it

Nothing is ever "once-and-for-all resolved" in the world of SDOs. It is only resolved for this edition of this spec.

Note that here you pointed me to --

RDF 1.1 Concepts and Abstract Syntax
W3C Recommendation 25 February 2014

-- and earlier you pointed me to even older things, and that's part of what got me spinning.

It is probably worth pointing also (if not instead) to that section in the latest Editor's Draft of RDF 1.2 Concepts, which mostly matches that from RDF 1.1. It is also worth noting that we (the RDF-star WG, which is working on all of RDF 1.2 and SPARQL 1.2, and it's a lot) had substantial discussion about this, much (but not all) of which is captured here.

I had forgotten that we did conclude that IRI was the right term for purposes of RDF, though not necessarily for purposes of Web browsing (which the WHATWG is far more focused on).

So anyway. Yeah, go ahead with IRI for WebID.

[jacoscaz]

Yes, it's unfortunate that people might wrongly conflate, or misunderstand, or mixup these terms, but I think it would be a big mistake to attempt to paper-over these distinctions by misusing the term URL in this specification when we all know we really, technically, mean IRI (again, as per the RDF spec).

The way I see it, it's exactly the opposite. By using IRI we'd be papering over the distinction between identifiers and locators in a manner that's guaranteed to be technically confusing. Nobody can really mean IRI if they're describing what must be a locator.

I do agree that deviating from the RDF spec would be unfortunate but, and I acknowledge that there's a lot of subjectivity here, I think doing so would nonetheless deliver a technically clearer and more understandable spec.

Both IRI and URL require a compromise:

• going with IRI we would compromise on making it clear that a WebID is a locator in favor of making it clear that the spec supports an extended set of characters
• going with URL we would compromise on making it clear that the spec supports an extended set of characters in favor or making it clear that a WebID must dereference

Today, most technical people I work with don't even question whether URLs can be internationalized or not. They just assume that such is the case and get mildly annoyed when it isn't. On the contrary, all of the technical people I work with are very well aware of the difference between identifiers and locators. IMHO, by going with IRI we'd be making the wrong compromise.

[TallTed]

A WebID which Identifies me does not Locate me. Clearly, a WebID is not a Locator, Uniform or otherwise. It is an Internationalized Resource Identifier (which class includes all Uniform Resource Identifiers; all URIs are IRIs) which identifies an Agent. Dereferencing that Identifier leads to a WebID Profile Document, possibly through a 303 or other redirect, the target of which may be (probably is) a Uniform Resource Locator.

[jacoscaz]

A WebID which Identifies me does not Locate me

Agreed. But, for all practical intents and purposes, a WebID identifies the Agent while locating the Profile Document. This is not 100% sound from a theoretical point of view but reflects what happens in practice: if a WebID can be passed as the primary url argument/parameter of an HTTP client library in order to obtain a Profile Document, then that WebID is, by all practical definitions, a locator.

That said, I should clarify that, although I would prefer URL over IRI, I would personally have no significant issue with any of these. Yeah, I think one would be better than the other but there are other hills for me to die on. I'm mostly here because I'm very interested in learning about the perspectives of others.

I think we have +3 for IRI and +1 for URL, at the moment.

[jacoscaz]

Tagging a few of the most active group participants to encourage the conversation - @woutermont @jonassmedegaard @melvincarvalho @kidehen @acoburn