First of all, I really want to congratulate the Omeka S team on the release of version 1.0.0. I’m impressed with the quality and usefulness of the 1.0.0 version. We’ve used the earlier version of Omeka for years, and I like the approach of Omeka S regarding how it builds on the Omeka core ideals inside of a new framework.
I’m successfully using the DSpace Connector to import items from our DSpace 6.2 install. I’m able to connect to the REST interface on DSpace from Omeka S’s DSpace Connector module, view my Collections and Communities, and then import a collection.
However, when I click the button to start the import, I get this result on the next page:
Fatal error: Class ‘DspaceConnector\Controller\Message’ not found in /opt/rh/httpd24/root/var/www/html/omeka-s/modules/DspaceConnector/src/Controller/IndexController.php on line 44
Regardless of the error message, the job is created and does run to completion. However, I wondering what would cause this exception to be thrown.
How can I stop this error? Is anyone else using the DSpace Connector with version 1.0.0 seeing this error?
Stacy
Looks like you win the prize for finding the first silly bug!
There’s a line of code that somehow didn’t get included before we packaged and shipped the module.
If you want to remove that message manually, you just need to add a line to the DspaceConnector/src/Controller/IndexController.php file. Right at the top, above the other lines that being use, add this:
use Omeka\Stdlib\Message;
Here’s what the fixed code change looks like: https://github.com/omeka-s-modules/DspaceConnector/commit/8df89f0c3ecdf672032b84419f1078e99695a9c1
Thanks for reporting this, and let us know if anything else comes up.
Thanks! This patch works great. I appreciate the quick response on this!
As a complete aside, where should we make suggestions for features to the DSpace Connector module?
I would like to suggest that only the original bitstreams are imported with the DSpace object. Omeka S really doesn’t have any need for the branded preview or thumbnail images that get imported with the DSpace object, as it uses ImageMagick to create its own. It is easy to see via the REST interface to DSpace if a bitstream is an original or a DSpace-created derivative image file.
Thanks again!
Stacy
1 Like
Thanks for the feedback! That’s exactly the kind of thing that helps us immensely, since it gets to the things that move into how DSpace works, and the few sites that we test against have different kinds and structures of data available, especially as we try to handle different API versions. (The same goes double for FedoraConnector, if you know any Fedora folks looking at Omeka S!)
The best place for feature suggestions is probably on the DSpace Connector issues page in GitHub, though here also work fine for anyone not familiar with GitHub. They’ll get there eventually, but if they start life there they’ll be easier to track.
Thanks again!
Thanks, Patrick. I’ll make this suggestion on the GitHub page.
We have about 30K objects in DSpace, so I’m thinking the DSpace Connector will get a pretty good workout as we continue our Omeka S testing.
We also have a Fedora repository, but it is Fedora 2.x and nearly impossible to upgrade at this point. I’m sure the Fedora Connector won’t work against the Fedora 2.x API, which has changed in major ways when compared to the Fedora 4.7 API today.
If I hear of any Fedora folks looking for a front-end exhibit builder that is pretty easy to stand up and use, I’ll definitely pass along the Omeka S option to them.
Stacy
Many thanks. That’s all a huge help. Much appreciated.
I saw the issue on GitHub, so I’ll follow up and ask questions there.
Yeah, the FedoraConnector is based on version 4+ of Fedora, since its native use of LOD makes the most sense for connecting up with Omeka S.