How common are they?

There are not many registered namespaces, and I cannot say how widely used they are. I know that the SRU/SRW identifiers are still alive in the SRU protocol, e. g. in the Record Schemas. There is even one for the University of Gent Repository. Maybe you can find out something there.

Note: If we decide to keep the info-URIs, we should reference RFC 4452

Summoning @phochste. How popular are info URIs? Something we actively use?

Oh yes. Worldwide it is in use by OpenURL resolvers to specify formats, encodings, services and all that. Every academic library in the world has some sort of resolver (SFX, 360 Link, Umlaut, LinkSolver to name a few). Our Gent Repository uses info URI-s for internal digital archiving services.

Here is an example of a info URIs in use on our UGent SFX resolver:

http://sfxit.ugent.be/sfx_local?url_ver=Z39.88-2004&url_ctx_fmt=info/fmt:kev:mtx:ctx&ctx_ver=Z39.88-2004&ctx_enc=info:ofi/enc:UTF-8&rfr_id=info:sid/sfx:meercat&sfx.ignore_date_threshold=1&rft.object_id=954925427238&svc_val_fmt=info:ofi/fmt:kev:mtx:sch_svc&svc.fulltext=yes

Thanks @phochste, that settles it then!

did I hear info URI? :-)

There's a lot I could say about info URI. Not sure whether anyone is interested though ;-)

The need for info URI arose from the standardization of OpenURL. There, we needed URIs to express "legacy identifiers" (typically of creative works etc) for which no URI schemes existed yet. Think LCCN etc. So, one could register a namespace e.g. "lccn" and then express an LCCN number as a URI info:lccn/... The idea was that info URIs eventually would be resolvable against one or more HTTP resolvers, eg http://baseURL(Resolver)?info:lccn/... Something similar to ARK identifiers with that specific regard. We stopped accepting registrations of info URI namespaces when, in the Linked Data movement, everything was given HTTP URIs. In hindsight, and without us being aware of it when spec-ing info URI, it somehow touched upon the HTTPRange14 problem domain. info URIs were assigned to "non-information resources" and a description of the non-information resource would be obtainable by throwing its info URI against the HTTP baseURL of a resolver. In short: information resources have HTTP URIs and non-information resources info URIs. And access to information about non-information resources is obtained by resolving their respective info URIs. Some day, someone should explore where such a paradigm could have taken us ;-)

In short: information resources have HTTP URIs and non-information resources info URIs.

Ooh, that sheds a different light upon this though, give that we point to information resources.
@larsgsvensson Shall we remove then after all?

I always thought that profiles are non-information resources that can be described one way or another (be it through a PDF document à la DCAT-AP.de or through a (set of) SHACL and/or ShEx shapes, XML Schema documents or whatnot. I think that the PROF-Ontology Spec takes a similar stand.
So no, @RubenVerborgh, I don't think we should remove the references to info-URIs.

Warning: pedantism ahead 🙂

I always thought that profiles are non-information resources

I actually made that less explicit in the introduction:
99be959#diff-30ae7ee064bd6b284e77a49b8fa45321L149

Calling it "a document" would make it an information resource.

that can be described one way or another (be it through a PDF document à la DCAT-AP.de

So you distinguish between the description and the profile itself. (Which is also interesting, given that I changed "document" into "description".)

I think that the PROF-Ontology Spec takes a similar stand.

I was looking for evidence either way, but didn't find any. It's currently "a named set of constraints". Could be argued that this is information (possibly also the other way).

Bottomline is: I don't mind info-URIs that much; it was just because @hvdsomp said they are explicitly for non-information, that I started wondering again. I'm fine with keeping them in, unless they are really out of scope (so feel free to close).