testing handles

[Jo]

Hi,

I'm working on support for handles under v4, a requirement for us to migrate from v3 to v4. As a first step I did some refactoring to make the DOIEZIdServiceBean, DOIDataciteServiceBean and HandelnetServiceBean implement an interface. This first step resulted in NotImplemented exceptions for various new methods in the HandelnetServiceBean class. As a second step I pieced together implementations for the not implemented methods as far as I saw them being called somewhere. PR for the first step, PR for the second step which is a PR on the first one.

Now I need to piece together the configuration for testing the handle implementation.

First, I don't want to create real handles, so I suppose I need some handle-ish alternative for the DOI test prefix configured with

   curl -X PUT -d 10.5072 "http://localhost:8080/api/admin/settings/:Authority"

Second, I don't know how to create a file for the JVM argument dvn.handle.admcredfile.

I approach my development virtual machine (vagrant) with http://ddvn.dans.knaw.nl:8080/loginpage.xhtml
So I suppose from this v3 configuration I can omit dvn.handle.admprivphrase and need:

dvn.handle.fqdn=ddvn.dans.knaw.nl
dataverse.siteUrl=http://ddvn.dans.knaw.nl:8080/

Anyone with suggestion for 'first' and 'second'?

[Jo]

Forgot just implementing the HandelnetServiceBean methods is not enough. Should still refactor the dataset command classes to no longer check for DOI or handle protocol... :-(

[Philip Durbin]

Hi Jo, we've been chatting at http://irclog.iq.harvard.edu/dataverse/2016-09-08 but if there's anything else you need, please let us know!

On Thu, Sep 8, 2016 at 9:31 AM, Jo <joke...@dans.knaw.nl> wrote:

Forgot just implementing the HandelnetServiceBean methods is not enough. Should still refactor the dataset command classes to no longer check for DOI or handle protocol... :-(

--
You received this message because you are subscribed to the Google Groups "Dataverse Users Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dataverse-community+unsub...@googlegroups.com.
To post to this group, send email to dataverse-community@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dataverse-community/ea3cb4c7-4564-4afd-8bd8-db577e771cb4%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Philip Durbin
Software Developer for http://dataverse.org
http://www.iq.harvard.edu/people/philip-durbin

[Lucien van Wouw]

Hi,

For the second: these admin credential files are created when you setup your Handle System Resolver using the software at:

https://www.handle.net/download_hnr.html

A client ( dataverse in this case ) needs them to authenticate with and operate your resolver.

[Jo]

It doesn't seem good enough to copy the admpriv.bin from our v3 dataverse (acceptance system) to my v4 developers virtual machine as proposed in the chat with Philip. From HandleResolver.findLocalSites in the stack trace I guess I have to follow Lucien's advice and set up a local handle server on my virtual machine.

Or is there any configuration option for a more distributed solution?

 The class CreateDatasetCommand logs:

  Exception while creating Identifier: Unable to find service for handle, got response: Error(100): HANDLE NOT FOUND
HandleException (SERVICE_NOT_FOUND) Unable to find service for handle, got response: Error(100): HANDLE NOT FOUND
    at net.handle.hdllib.HandleResolver.findLocalSites(HandleResolver.java:650)
    at net.handle.hdllib.HandleResolver.processRequestGlobally(HandleResolver.java:578)
    at net.handle.hdllib.HandleResolver.processRequest(HandleResolver.java:553)
    at net.handle.hdllib.HandleResolver.processRequest(HandleResolver.java:563)
    at edu.harvard.iq.dataverse.HandlenetServiceBean.registerNewHandle(HandlenetServiceBean.java:175)
    at edu.harvard.iq.dataverse.HandlenetServiceBean.createIdentifier(HandlenetServiceBean.java:334)

[Condon, Kevin M]

Hi,

We used to have a jvm option to point to a remote or existing handle server in v3.6.2 but I don't think this level of support was yet added to v4.x.

The developer who was working in this area is on vacation but returning next week. It sounds like we need to add this in addition to the work you are doing.

For reference, the v3.6.2 option can be found here:

http://guides.dataverse.org/en/3.6.2/dataverse-installer-main.html#jvm-options

To enable the optional HANDLE.NET installation and provide access to

study ID registration, add the following (see the “Handles System”

section in the “Optional Components” for

details):

-Ddvn.handle.baseUrl=<-Dataverse Network host URL>/dvn/study?globalId=hdl:

-Ddvn.handle.auth=<authority>

-Ddvn.handle.admcredfile=/hs/svr_1/admpriv.bin

Kevin

---

From: dataverse...@googlegroups.com <dataverse...@googlegroups.com> on behalf of Jo <joke...@dans.knaw.nl>
Sent: Friday, September 9, 2016 8:01:20 AM
To: Dataverse Users Community
Subject: [Dataverse-Users] Re: testing handles

 

--
You received this message because you are subscribed to the Google Groups "Dataverse Users Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to dataverse-commu...@googlegroups.com.
To post to this group, send email to dataverse...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dataverse-community/2c1944eb-158b-4ed6-b24a-5bbbe0992fc9%40googlegroups.com.

[Lucien van Wouw]

Hello,

Yes. I think that probably you need to install a handle system resolver with a test NA on a public machine and ask the CNRI to register it so you can developing the DV client for it. Perhaps Dans already posseses a test NA?

That said, I am unsure if this is really required but I don't know how else the client can know what the associated IP address of the test NA is without consulting the Handle System global registry.

If would be nice if it could, because then developing would be easier obviously.

[Vyacheslav Tikhonov]

Lucien, we don't have handle.net server in house, it's external party.

Best,

Slava

[Vyacheslav Tikhonov]

Hi Kevin,

Great suggestion. Do you also have some handle.net server for tests to create temporary PIDs? I think something should be still available from version 3.6 with handles? We're spending too much time now to figure out how to test it properly.

Best,

Slava

[Lucien van Wouw]

According to this advice, chapter 10 explains how to configure a client and server without the use of the global registry:

http://www.handle.net/mail-archive/handle-info/msg00777.html

On Friday, September 9, 2016 at 4:52:11 PM UTC+2, Lucien van Wouw wrote:

[Lucien van Wouw]

This chapter works when I try it out on my local box. The client does throw a message in my face about SERVER NOT RESPONSIBLE FOR HANDLE, but that does not seem to matter and I can set handles locally that resolve to the intended url. 

[Vyacheslav Tikhonov]

Great news, Joke just successfully finished testing of handle.net support and it works great! 

She will finish documentation and will push latest changes to github.

Best,

Slava

On Thursday, September 8, 2016 at 1:25:25 PM UTC+2, Jo wrote:

[danny...@g.harvard.edu]

Great news!

[Jo]

Well, technically it works great.

But so far I was told never to delete a persistent identifier once it is published. After all that is the meaning of persistent. People may have bookmarked these id's and loose trust in persistent identifiers when they don't resolve any more.

So I'm not amused the DOI's (and handle as I implemented them in the same way to minimise the changes) are deleted when a dataset is de-accessioned. When a dataset is de-accessioned, there is still a tomb stone telling why the dataset is no longer available, so there is no reason at all to unregister the id.

[Mercè Crosas]

You are completely right - A DOI or Handle should not be deleted when a dataset is de-accessioned. That's the way it works, right?

Merce

--

You received this message because you are subscribed to the Google Groups "Dataverse Users Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dataverse-commu...@googlegroups.com.
To post to this group, send email to dataverse...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/dataverse-community/356ad4a9-7b54-456f-989f-3ca559a5768a%40googlegroups.com.

[Kraffmiller, Stephen E]

DOIs are not deleted when a dataset is deaccessioned.  (There is a special case for DOIs that are reserved via EZID - If an unpublished dataset is deleted then we delete the identifier, because the identifier was never public.)

When the provider is EZID and a dataset is completely deaccessioned the target url is changed to the EZID for a “tombstone” page.

Under Datacite, the identifier is not deleted, but the status is set to “Unavailable”. That probably shouldn’t be the way it works.  I’ll enter a ticket and change that behavior to something more appropriate.

Stephen

To view this discussion on the web visit https://groups.google.com/d/msgid/dataverse-community/48C2BB3A-61B8-41CF-908E-531AAFD3FFC6%40gmail.com.

[Vyacheslav Tikhonov]

Hi all,

We've pre-released Dataverse 4.5 with handle support:

https://github.com/DANS-KNAW/dataverse/releases/tag/v4.5-beta.1

Please feel free to download and test it also as we're interested to get Dataverse Community feedback.

-- 

Best regards,

Vyacheslav Tykhonov (Slava)

Senior Data Scientist,

Research and Innovation Department

Data Archiving and Networked Services (DANS)

DANS offers durable access to digital research data.

Please visit www.dans.knaw.nl for more information and contact details.

DANS is an institute of KNAW and NWO.

 

DANS | Anna van Saksenlaan 51 | 2593 HW Den Haag | Postbus 93067 | 2509 AB Den Haag | +31 70 349 44 50 | in...@dans.knaw.nl | www.dans.knaw.nl

 

On Monday, September 19, 2016 at 3:31:59 PM UTC+2, Steve Kraffmiller wrote:

DOIs are not deleted when a dataset is deaccessioned.  (There is a special case for DOIs that are reserved via EZID - If an unpublished dataset is deleted then we delete the identifier, because the identifier was never public.)

When the provider is EZID and a dataset is completely deaccessioned the target url is changed to the EZID for a “tombstone” page.

Under Datacite, the identifier is not deleted, but the status is set to “Unavailable”. That probably shouldn’t be the way it works.  I’ll enter a ticket and change that behavior to something more appropriate.

Stephen

On Sep 19, 2016, at 9:02 AM, Mercè Crosas <merce....@gmail.com> wrote:

You are completely right - A DOI or Handle should not be deleted when a dataset is de-accessioned. That's the way it works, right?

Merce

On Sep 19, 2016, at 4:04 AM, Jo <joke...@dans.knaw.nl> wrote:

Well, technically it works great.

But so far I was told never to delete a persistent identifier once it is published. After all that is the meaning of persistent. People may have bookmarked these id's and loose trust in persistent identifiers when they don't resolve any more.

So I'm not amused the DOI's (and handle as I implemented them in the same way to minimise the changes) are deleted when a dataset is de-accessioned. When a dataset is de-accessioned, there is still a tomb stone telling why the dataset is no longer available, so there is no reason at all to unregister the id.

--
You received this message because you are subscribed to the Google Groups "Dataverse Users Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to dataverse-community+unsub...@googlegroups.com.

To post to this group, send email to dataverse...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dataverse-community/356ad4a9-7b54-456f-989f-3ca559a5768a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Dataverse Users Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to dataverse-community+unsub...@googlegroups.com.

[soU]

Hi Jo

I am checking the remaining issues on "support handle" locally. And I setup handle.net server and it's running as you, Lucien and Kevin suggested. Followed the steps on chapter 10 of the manual and also edit those jvm options. So now how do I switch the default persistent ID from  DOI to handle? 

thanks

[danny...@g.harvard.edu]

Hi Solomon - thanks again for taking over the Handles work that DANS was working on last year!

There are both JVM options and database settings that need to be updated. Is this helpful?

http://guides.dataverse.org/en/latest/installation/config.html#persistent-identifiers-and-publishing-datasets

Thanks,

Danny

[soU]

Thanks Danny

I was checking the Remaining items you picked from Kevin's comment;

And I need some clarifications on these points

• Make Error messages generalized. The message reads "Datacite," but instead should show the registration service being used. (Error – This dataset may not be published because the DataCite Service is currently inaccessible. Please try again. Does the issue continue to persist? Please contact Dataverse Support for assistance.)
• This error came from PublishDatasetCommand but it first checks if the protocol is DOI  and in our case its hdl so I can't reproduce the error with protocol hdl 
• When a dataset is created, the globalidcreatetime column needs to be updated.
• In doi the globalidcreatime is updated on publishing instead of creation and it checks the protocol, so our hdl will be ignored.For that I have added a statement to update the globalidcreatime when the dataset is published with hdl protocol.
• Add a check for globalcreatetime value when publishing a dataset with a Handle
• The line which set the globalCreateTime execute after it checks the field for null.
• An unpublished, draft-only Handle should be able to be deleted
• when unpublished dataset is deleted the identifier also deleted from the dataset table. Is it exists also elsewhere?
• When a dataset is destroyed, it should delete the persistent identifier as well
• If we are saying after published, as Merce mentioned above  "...A DOI or Handle should not be deleted when a dataset is de-accessioned. That's the way it works, right?"

Other than those issues. at what point is the datasets pushed into the handle.net server or get public? I can see publicizeIdentifier function for doi on both providers EZID and DataCite but I can't find a related function for hdl protocol. 

Thanks 

Solomon

[danny...@g.harvard.edu]

Hey Solomon - let's move the discussion over to the github issue:

https://github.com/IQSS/dataverse/issues/2437

I'll tag in a few folks from the Dataverse team so that we can get answers to these questions.