Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

info-URI #6

Open
RubenVerborgh opened this Issue Mar 9, 2019 · 8 comments

Comments

Projects
None yet
4 participants
@RubenVerborgh
Copy link
Member

RubenVerborgh commented Mar 9, 2019

We mention info-URI. How common are they?

@larsgsvensson

This comment has been minimized.

Copy link
Member

larsgsvensson commented Mar 13, 2019

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

@RubenVerborgh

This comment has been minimized.

Copy link
Member Author

RubenVerborgh commented Mar 13, 2019

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

@phochste

This comment has been minimized.

Copy link

phochste commented Mar 13, 2019

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

@RubenVerborgh

This comment has been minimized.

Copy link
Member Author

RubenVerborgh commented Mar 13, 2019

Thanks @phochste, that settles it then!

@hvdsomp

This comment has been minimized.

Copy link
Collaborator

hvdsomp commented Mar 13, 2019

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 ;-)

@RubenVerborgh

This comment has been minimized.

Copy link
Member Author

RubenVerborgh commented Mar 13, 2019

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?

@RubenVerborgh RubenVerborgh reopened this Mar 13, 2019

@larsgsvensson

This comment has been minimized.

Copy link
Member

larsgsvensson commented Mar 13, 2019

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.

@RubenVerborgh

This comment has been minimized.

Copy link
Member Author

RubenVerborgh commented Mar 13, 2019

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.