Closed pennington closed 6 years ago
If the DSpace API you are working from is open to the public, could you point me to it? The sites I've been working from don't seem to have data as rich data as yours for me to work from.
Sure, no problem. I'll send you the REST API URL for our DSpace instance direct to your email address. (I would rather not make it super-public,...)
Understood. Thanks again!
Implemented not as an option, but as the regular behavior.
Thanks, Patrick!
My pleasure, and thanks for the links to test against. I have one other possible bug (unrelated) to look at, but the changes should be coming up in a bugfix release soon. Probably this week.
I would like to suggest that only the original bitstreams are imported with the DSpace object. This could be done with a checkbox option on same page where you select whether to import the objects from DSpace.
Currently, Omeka S and the DSpace Connector are importing all of the metadata (good!) and all of the bitstreams (not so good!) with every DSpace object. Most, if not all, DSpace objects have a series of derivative bitstreams, such as thumbnails and branded previews, that are created from the original bitstream (of which there can be several for any one 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.
Currently, we are importing DSpace objects to Omeka S and then deleting the thumbnails and branded previews. It would be great if we didn't have to do that, as we only need the original bitstream(s).
In addition, it would also be nice if the default name of the media files imported to Omeka S as part of an Item was not the REST API URL. The "name" field in the REST API reply data is the real name of the media file, per DSpace.
Thanks.
Stacy