our interpretation of resolvable is the same, but we have different view on URNs.
I was talking about URNs which are actionable and can therefore be expressed as HTTP URIs. Such as
There is fundamental difference between the URN above and any other URI that happens to contain the same string of numbers. Both ISBN and URN based on ISBN are standard identifiers, whereas a URL like http://example.com/9789512530625 is not a proper identifier (although RFC 3986 says so) even if it were actionable. We don’t know who created that URL, how persistent it is going to be, or even if it has anything to do with the ISBN in it.
There are URN namespaces which are not resolvable yet, but will be in the future, such as urn:issn. And since resolvability is not required in the URN standard, there are also URN namespaces within which URNs are just identifiers. For instance, Homer multitext project is currently in the process of registering URN namespaces to identify texts and textual objects (items). See
I see no problem in having non-resolvable URNs as well. They are useful in the same way as traditional identifiers such as ISBN.
HTTP URIs are not ideal as identifiers / links since they are technology dependent. Some day, in the more or less distant future, they will stop functioning. For URN-based links, getting rid of the resolver URI such as http://urn.fi is possible, if a) DNS (or its future replacement) knows where URNs from an actionable namespace can be processed, and b) Web browsers and other apps support the use of URNs.
Resolving URNs can be simple, because some URN namespaces like urn:issn will have just one relevant target system (in the case of urn:issn, the ISSN database). If there are several potential target systems, URNs in that namespace must contain a hint with which the correct service can be found. In the URNs above those hints are the country code “fi” for urn:nbn and the ISBN registration group element “951” for urn:isbn. When new URN namespaces are registered, we do check that URNs in that namespace, if intended to be actionable, can be resolved as such, without the resolver address.
I guess I have a different interpretation of “resolvable”. If I can paste the identifier into the address bar in my browser and it does something, then it’s resolvable. If not, then I would say it’s not. URNs aren’t resolvable in that sense.
If I have to track down a resolver service and then paste the literal identifier into a pattern and then that works, then I’d wonder why the resolver URI isn’t being promoted as the linked data identifier.
as regards the question of what do I (or users in general) expect to get:
if an actionable URI is based on a persistent identifier such as DOI/Handle or URN, multiple resolution is possible due to the functionality provided by PID resolvers such as Handle System. A user may get descriptive or other kind of metadata about the resource, or the resource itself, or whatever he/she wants and the resolver and the target system supports, as long as the thing he/she wants is available in the Web, and the resolver knows either its URL, or a URL that can be dereferenced to the current URL of the thing.
I don’t think that there is a single answer to the question of what I/we/the end users want, and therefore it is important to be flexible. Any model or technology forcing one solution only is a procrustean bed to be avoided.
Different PID systems have different ways of achieving multiple resolution, and in some cases (e.g. ARK) the solution currently supported is not satisfactory. But both PID specifications and resolvers will become stronger in this respect in the future. For instance, the National Library of Finland and the ISSN International centre are currently enriching the functionality provided by the library’s URN resolver, using URN R- and Q-components as specified in RFC 8141.
If the actionable URI is not PID-based, the additional functionality provided by PID resolvers is lost. It may be a weeny bit difficult to support resolution from one URL to many relevant URLs (multiple resolution) via HTTP dereferencing only. But that should not force us to specify any kind of default link behaviour or preference in Bibframe or elsewhere.
Can I bring the discussion back to the original question, whether a URI, supplied as the value (rdf:value) of bf:identifiedBy, should be encoded as a literal or an actionable URI.
I believe the question is probably irrelevant, because, I still believe, there is no practical purpose served by doing so.
Let me ask this: if it is to be an actionable URI, what do you expect to get upon dereferencing it?
So what do you expect to get?