Print

Print


Hello Jeff,

 

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

 

http://urn.fi/URN:NBN:fi-fd2017-00012284

 

or

 

http://urn.fi/URN:ISBN:978-951-25-3062-5

 

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

 

http://www.homermultitext.org/hmt-doc/guides/urn-gentle-intro.html

 

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.    

 

Juha

 

From: Bibliographic Framework Transition Initiative Forum <[log in to unmask]> On Behalf Of Young,Jeff (OR)
Sent: torstai 7. maaliskuuta 2019 17.23
To: [log in to unmask]
Subject: Re: [BIBFRAME] When a bf:Identifier is a URI

 

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.

 

Jeff

 

From: Bibliographic Framework Transition Initiative Forum <[log in to unmask]> on behalf of "Hakala, Juha E" <[log in to unmask]>
Reply-To: Bibliographic Framework Transition Initiative Forum <[log in to unmask]>
Date: Thursday, March 7, 2019 at 1:29 AM
To: "[log in to unmask]" <[log in to unmask]>
Subject: Re: [BIBFRAME] When a bf:Identifier is a URI

 

Hello,

 

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.   

 

Juha

 

From: Bibliographic Framework Transition Initiative Forum <[log in to unmask]> On Behalf Of Denenberg, Ray
Sent: keskiviikko 6. maaliskuuta 2019 22.28
To: [log in to unmask]
Subject: Re: [BIBFRAME] When a bf:Identifier is a URI

 

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?

 

Ray

 

 

From: Bibliographic Framework Transition Initiative Forum <[log in to unmask]> On Behalf Of Young,Jeff (OR)
Sent: Tuesday, March 05, 2019 8:37 AM
To: [log in to unmask]
Subject: Re: [BIBFRAME] When a bf:Identifier is a URI

 

Osma,

 

Humpf. I checked with WebProtoge and you’re right. I wasn’t expecting that because owl:deprecated is an owl:AnnotationProperty rather than an owl:DatatypeProperty.

 

It would still make sense, though, for ISSN (and others) to add this in their linked data RDF to reconcile old school URI schemes and the current Cool http: scheme:

 

<urn:ISSN:0044-1570> owl:sameAs <http://issn.org/resource/ISSN/0044-1570>

 

That way the tools can deal with differences in practice over time. The same can’t be said for treating the URN as a literal or as an rdf:value.

 

Maybe I’m still missing the point?

 

Jeff

 

From: Bibliographic Framework Transition Initiative Forum <[log in to unmask]> on behalf of Osma Suominen <[log in to unmask]>
Reply-To: Bibliographic Framework Transition Initiative Forum <[log in to unmask]>
Date: Tuesday, March 5, 2019 at 3:43 AM
To: "[log in to unmask]" <[log in to unmask]>
Subject: Re: [BIBFRAME] When a bf:Identifier is a URI

 

Hi Jeff!

Young,Jeff (OR) kirjoitti 4.3.2019 klo 19.43:
> I agree that identifier agencies should migrate old URI schemes to http:
> and deprecate them in their RDF with mappings to the modern form for
> backward compatibility. There’s even a W3C standard for expressing this:
>
> <oldURI> owl:deprecated true ;
>                 owl:sameAs <newURI> .

Not sure this expresses what you intend. owl:sameAs means that both its
subject and object are the same thing, the same individual. Thus this
combination of statements implies that <newURI> is also deprecated.

-Osma

--
Osma Suominen
D.Sc. (Tech), Information Systems Specialist
National Library of Finland
P.O. Box 26 (Kaikukatu 4)
00014 HELSINGIN YLIOPISTO
Tel. +358 50 3199529
[log in to unmask]
http://www.nationallibrary.fi