On Tue, Jul 02, 2019 at 02:37:10PM +0600, Anwarul Islam wrote:
> A Bangladeshi renowned public Library has installed Dspace & Koha for
> library automation. It is about done. But a Technical committee of them
> (formed from IT professionals) . The Technical Committee has given the
> following opinion to accumulate the following matters in the automation. I
> this these are not possible at all. Would you please give your opinion.
>
> 1. Configure DSpace in such way that a user of DSpace can generate any type
> of report direct from database.
If users are to query the database directly, there is no need or
possibility to so reconfigure DSpace. The DBMS must be configured for
this. You will need additional DBMS user accounts. Those accounts
should *not* be granted UPDATE or DELETE on any DSpace table. Of
course you should carefully consider who should have access to
personally identifying information in the 'eperson',
'epersongroup2eperson' and 'epersongroup2workspaceitem' tables, and
review all other tables for possible leaks of sensitive information.
> 2. Add some extra columns in each table of DSpace for future use.
a. This requirement is under-specified. "Some" extra columns?
b. Without knowing the future use, one cannot know how the columns
should be created.
c. This will make upgrades more difficult, since the DSpace upgrade
code and instructios will not take these additional columns into
account. It may be better to create new tables which are coordinated
with the existing DSpace-controlled tables, but your site will still
be responsible for any necessary updates or redesign of those tables
during an upgrade.
> 3. Find out or create an API to synchronize between DSpace and Koha.
> 4. Configure DSpace in such way that if a user forgets to entry a book in
> Koha and try to upload the same book in DSpace then DSpace will notify
> him/her to entry the book in Koha first.
Not configurable. This will require new code.
A less intrusive alternative would be to create a "curation task"
which makes this check, and attach it to the workflow for any
Collection which requires it. The check would be executed after
submission, but before the submission is accepted into the archive.
> 5. Add an extra numerical field in DSpace front-end to entry page number.
That should be simple. The input forms are meant to be easy to
modify. You will need to identify or invent a new metadata field to
hold the entered values. The user interface must be extended if you
wish to display the page number in search or browse results.
> 6. Configure DSpace in such way that a user can print any number of pages
> of an eBook direct from DSpace database.
Content files are not stored in the database. They are individual
files located in the "assetstore" directory tree.
This is not configurable. New code will be required.
> 7. Configure DSpace in such way that a user can calculate the total number
> of pages that uploaded in DSpace.
Not configurable. This will require new code. Each document must be
examined, and the number of pages in it determined in a
format-dependent way. It would be convenient to do this at submission
time and store the page count in a metadata field, so that they can be
quickly summed for display. I think that a single database query
could do the summation, but you may need to add indexes to one or more
tables to get acceptable speed. (Adding an index is not intrusive.)
--
Mark H. Wood
Lead Technology Analyst
University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu