Dear Aris,
answers inside your text
Il 31/01/2016 08:53, Aris Rotoras ha scritto:
Hi all,
I am using DSpace-Cris 5.3 and I have the following questions:
1. I can see that the out-of-the-box behavior of the Researcher and
Organizational Unit Entity is not to be searchable. But if you click
the Status check box they get searchable. I wonder if I can do that as
an automated batch job. I tried to change the DB status column for
both entity types to TRUE but (even though the check box got checked
for the entities) they are still not shown on the search menu and box.
Should I change something else in order to enable the entities?
It is generally not recommended to make changes directly to the database.
If you do so, you must also
- manually reindex your content (dspace index-discovery -b)
- set the column timestamplastmodified to now() in cris_rpage to
invalidate previous application cache
If your researcher profiles are automatically created during the
submission as result to pick an ORCID record or enter a new name you can
set the default visibility to public changing this configuration parameter
https://github.com/Cineca/DSpace/blob/dspace-cris-5.3.0/dspace/config/modules/cris.cfg#L84
please note that we are going to rename such parameter in DSpace-CRIS
5.4.0 and make it true by default
https://github.com/Cineca/DSpace/blob/dspace-5_x_x-cris/dspace/config/modules/cris.cfg#L90
An alternative way to bulk change the public visibility of an entity is
to use the XLS data import available with the outcoming DSpace-CRIS
5.4.0. We are going to cut the release in the next days, the code is
almost complete and already available on github so you are more than
welcome to download the current branch and make experiments
https://github.com/Cineca/DSpace/tree/dspace-5_x_x-cris
The XLS import can be run from the command line using the
org.dspace.app.cris.batch.ScriptCrisBulkChanges class or from the
DSpace-CRIS administrative UI <dspace-url>/cris/administrator/index.htm
The excel file must be in the 97-2003 format with two sheets
1st sheet: main_entities
ACTION CRISID UUID SOURCEREF SOURCEID <one more columns
for any metadata that you want to manage, the column header must match
the shortname of the metadata)
Action can be one of: CREATE/UPDATE/DELETE/HIDE/SHOW
CRISID/UUID/SOURCEREF/SOURCEID will be used to locate the right object
to modify, it is not necessary to fill all the columns if you have exact
CRISID you can just put these
if you want to update the metadata dept of a researcher page (rp00001)
you can use a row like that
ACTION CRISID UUID SOURCEREF SOURCEID dept
update rp00001 <empty-cell> <empty-cell> <empty-cell> [visibility=PUBLIC
CRISID=ou0001]My department
This will link the rp with the orgunit ou00001. It is also possible to
set the target orgunit via UUID, SOURCEID and SOURCEREF.
2nd sheet: nested_entities
CRISID_PARENT SOURCEREF_PARENT SOURCEID_PARENT UUID
SOURCEREF SOURCEID <one more columns for any metadata that you want
to manage, the column header must match the shortname of the metadata)
can be keep empty, just include the sheet with the about header. It
allows you to update or create nested object in the target cris entity.
2. As I mentioned in my first email, we want to make automatic link
between researchers and organizational units, as if we added the
affiliation field of the researcher by hand. Could I know if there is
a database change that we can perform in order to link the two
entities? (for example if we have a CSV file that has
author_name,organisational_unit_name can what should I do
database-wise in order to link the two as affiliation?)
3. Where do DSpace-Cris keep it's Entities Data (let's say a
Researcher's affiliation and chinese name) in order for me to try and
provide the correct data "automatically"
As said, we discourage direct changes to the database. Just to give you
an initial idea about how the data are structured:
cris_rpage contains the minimal core information about the researcher
pages (IDs, status, timestamps) it is equivalent to the item table in DSpace
cris_rp_pdef contains the information about the metadata that can be
attached to a researcher page. It is equivalent to the
metadatafieldregistry table in DSpace. The column rendering_id links to
one of the jdyna_widget_* tables.
jdyna_widget_* tables contain specific information about the rendering
and validation of the metadata value as for instance the way to build a
link out to ORCID for the ORCID identifier, etc.
cris_rp_prop contains the actual metadata for a researcher page, with
the actual value (value_id) is store in a separated table jdyna_values
where integrity contraints are enforced.
The same schema applies for Projects, OrgUnits and Dynamic Objects.
Again, make direct changes to the database is not trivial and should be
avoid as much as possible. Link researchers to organizations can be done
using the XLS bulk update
Best,
Andrea
Thank you in advance.
--
You received this message because you are subscribed to the Google
Groups "DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to dspace-tech+unsubscr...@googlegroups.com
<mailto:dspace-tech+unsubscr...@googlegroups.com>.
To post to this group, send email to dspace-tech@googlegroups.com
<mailto:dspace-tech@googlegroups.com>.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.
--
Andrea Bollini
International Business Development, Deputy Leader
Open Source & Open Standards Strategy, Head
Cineca
Via dei Tizii, 6
00185 Roma, Italy
tel. +39 06 44 486 087 - mob. +39 348 82 77 525
http://www.cineca.it
--
You received this message because you are subscribed to the Google Groups "DSpace
Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.
