LISTSERV mailing list manager LISTSERV 16.0

Help for BIBFRAME Archives


BIBFRAME Archives

BIBFRAME Archives


BIBFRAME@LISTSERV.LOC.GOV


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Monospaced Font

LISTSERV Archives

LISTSERV Archives

BIBFRAME Home

BIBFRAME Home

BIBFRAME  March 2019

BIBFRAME March 2019

Subject:

Re: When a bf:Identifier is a URI

From:

"Hakala, Juha E" <[log in to unmask]>

Reply-To:

Bibliographic Framework Transition Initiative Forum <[log in to unmask]>

Date:

Fri, 8 Mar 2019 09:08:47 +0000

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (161 lines)

Hello Sigge,

nothing is eternal, but there are significant differences in how persistent identifiers and plain vanilla URLs are managed.

For instance, when the Finnish IT Center for Science gives a Finnish university a permission to assign DOIs to their research data sets, the university signs a contract which requires that if the responsibility of the data set is passed on to some other organization, this new owner must adopt also the responsibility of keeping the original DOIs alive. No such requirement exists for URLs of those data sets.
 
When a user sees a DOI link, he can safely assume that it has not suffered from link rot or (even worse) content drift. With URLs it is impossible to know if they were even intended to be persistent. Often that is not the case. I made a small scale analysis of links to referenced publications in old Finnish library science articles, and all DOIs were still working fine. But large percentage of URLs were either dead or provided a link to a wrong resource. If you were correct, DOI links and URL links should have been equally untrustworthy.

We do know, based on large scale analysis by Herbert Van de Sompel and others, that URLs are not reliable. There is no comparable research on the reliability of DOIs and other persistent identifiers, but I do hope that such analysis will be made in the future so that the difference between persistent identifier -based links and URL links is made clear.

Best,

Juha
   

-----Original Message-----
From: Bibliographic Framework Transition Initiative Forum <[log in to unmask]> On Behalf Of Sigfrid Lundberg
Sent: perjantai 8. maaliskuuta 2019 10.05
To: [log in to unmask]
Subject: [BIBFRAME] SV: [BIBFRAME] When a bf:Identifier is a URI

Sorry Juha, but RFC 3986 is right.

The only difference between URNs and NBNs and handls and the rest is the one between the dream of an eternal library and the internet. The URNs and the handles die the next budget shutdown for some organisation, since the whole notion PID resolution by redirect is based on a single point of failure.

A rose is a rose is a rose

In RDF all URIs are born equal.

Yours,

Sigge
________________________________________
Fra: Bibliographic Framework Transition Initiative Forum [[log in to unmask]] på vegne af Hakala, Juha E [[log in to unmask]]
Sendt: 8. marts 2019 08:01
Til: [log in to unmask]
Emne: Re: [BIBFRAME] When a bf:Identifier is a URI

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]<mailto:[log in to unmask]>> on behalf of "Hakala, Juha E" <[log in to unmask]<mailto:[log in to unmask]>>
Reply-To: Bibliographic Framework Transition Initiative Forum <[log in to unmask]<mailto:[log in to unmask]>>
Date: Thursday, March 7, 2019 at 1:29 AM
To: "[log in to unmask]<mailto:[log in to unmask]>" <[log in to unmask]<mailto:[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]<mailto:[log in to unmask]>> On Behalf Of Denenberg, Ray
Sent: keskiviikko 6. maaliskuuta 2019 22.28
To: [log in to unmask]<mailto:[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?

  * Do you expect to get a description of the resource? We've established that that's not an appropriate use of an identifier.
  * Do you expect to get a copy of the resource? Not only is that also not an appropriate use of an identifier, but there is an existing bibframe property to do that.

So what do you expect to get?

Ray


From: Bibliographic Framework Transition Initiative Forum <[log in to unmask]<mailto:[log in to unmask]>> On Behalf Of Young,Jeff (OR)
Sent: Tuesday, March 05, 2019 8:37 AM
To: [log in to unmask]<mailto:[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]<mailto:[log in to unmask]>> on behalf of Osma Suominen <[log in to unmask]<mailto:[log in to unmask]>>
Reply-To: Bibliographic Framework Transition Initiative Forum <[log in to unmask]<mailto:[log in to unmask]>>
Date: Tuesday, March 5, 2019 at 3:43 AM
To: "[log in to unmask]<mailto:[log in to unmask]>" <[log in to unmask]<mailto:[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]<mailto:[log in to unmask]>
http://www.nationallibrary.fi

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
July 2011
June 2011

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager