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

Provide patterns and infrastructure for assigning remote identifiers (DOI, Handle, etc.) #4458

Merged
merged 1 commit into from
Jul 17, 2020

Conversation

cjcolvar
Copy link
Member

There are three patterns provided: dispatcher, registrar, and builder
Dispatcher - assigns registered identifier to a given object
Registrar - handles communication with external identifier service
Builder - constructs identifier to submit to external identifier service

Registrar implementations just need to implement the registrar!
method. They can be tested with the provided shared spec and then
registered with Hyrax by the identifier_registrars configuration (which
is generated commented out in the hyrax initializer).
identifier_registrars should be a Hash with Symbol keys and Class values.

A custom builder implementation can be injected into your registrar by
overriding the registrar's initialize method setting the custom builder
as the default value for the builder keyword argument.

def initialize(builder: MyCustomBuilder.new)
  super(builder: builder)
end

With this infrastructure in place, a new remote identifier can be
assigned to a work by calling the dispatcher with the work object.
Assuming a :datacite registrar has been registered in Hyrax's
configuration then this would look like:

Hyrax::Identifier::Dispatcher.for(:datacite).assign_for!(object: work)

This will set the remote identifier in the work's identifier attribute
and save the work. To avoid saving the object use assign_for instead.
If a different attribute is desired the pass the attribute as a symbol
in the :attribute keyword argument to assign_for!.

This work is ported from mahonia (which had parts ported from epigaea).
Both of those implementations were done by @no-reply.

This is a slightly simpler and less opinionated alternative to hydra-remote_identifier. The mapping of work attributes to metadata submitted to the identifier registration service is left up to the registrar implementation here instead of being configured like in hydra-remote_identifier.

@samvera/hyrax-code-reviewers

…(DOI, Handle, etc.)

There are three patterns provided: dispatcher, registrar, and builder
Dispatcher - assigns registered iddentifer to a given object
Registrar - handles communication with external identifier service
Builder - constructs identifer to submit to external identifier service

Registrar implementations just need to implement the `registrar!`
method.  They can be tested with the provided shared spec and then
registered with Hyrax by the identifier_registrars configuration (which
is generated commented out in the hyrax initializer).
identifier_registrars should be a Hash with Symbol keys and Class values.

A custom builder implementation can be injected into your registrar by
overriding the registrar's initialize method setting the custom builder
as the default value for the builder keyword argument.

def initialize(builder: MyCustomBuilder.new)
  super(builder: builder)
end

With this infrastructure in place, a new remote identifier can be
assigned to a work by calling the dispatcher with the work object.
Assuming a :datacite registrar has been registered in Hyrax's
configuration then this would look like:

Hyrax::Identifier::Dispatcher.for(:datacite).assign_for!(object: work)

This will set the remote identifier in the work's identifier attribute
and save the work.  To avoid saving the object use `assign_for` instead.
If a different attribute is desired the pass the attribute as a symbol
in the :attribute keywork argument to `assign_for!`.

This work is ported from mahonia (which had parts ported from epigaea).
Both of those implementations were done by @no-reply.

Co-authored-by: Tom Johnson <johnson.tom@gmail.com>
Copy link
Contributor

@no-reply no-reply left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this seems great to me!

since it's basically a straight port of code i wrote, i'd like to see someone else review. but i'm chiming in to offer my 👍.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants