Page History
...
- Login as an Administrative user
- In Sidebase, select "Export" → "Metadata". Type in the Community/Collection name.
- Alternatively, browse to the Community or Collection you wish to export, and then go to "Export" → "Metadata". That Community/Collection will be preselected.
- Click "Export". A new Process will be created (in "Processes" menu). Once completed, download the resulting CSV.
Warningnote | ||
---|---|---|
| ||
As of In DSpace 7.03, it is not possible to export to CSV based on search results. This feature existed in 6.x, and it is scheduled to be restored in a later 7.x release (currently 7.1). See DSpace Release 7.0 Status.to Export search results to a CSV (similar to 6.x).When logged in as an Administrator, after performing a search a new "Export search results as CSV" button appears. Clicking it will export the metadata of all items in your search results to a CSV. This CSV can then be used to perform batch metadata updates (based on the items in your search results). - Release Notes#7.3ReleaseNotes |
Please see below documentation for more information on the CSV Please see below documentation for more information on the CSV format and actions that can be performed by editing the CSV.
...
- First, complete all editing of the CSV and save your changes
- Login as an Administrative User
- In sidebar, select "Import" → "Metadata" and drag & drop the CSV file
Warningnote | ||
---|---|---|
| ||
As of In DSpace 7.0, metadata import will occur immediately & results will be reported. In 6.x, after uploading the CSV, you were first presented with a summary of the changes that were to be performed, allowing you to review and choose whether to apply them or cancel. This "preview" feature will be restored in a later 7.x release (currently 7.1), see DSpace Release 7.0 Status.3, it is now possible to validate a Batch Metadata CSV before applying changes (similar to 6.x). When uploading a CSV for batch updates (using "Import" menu), a new "Validate Only" option is selected by default. When selected, the uploaded CSV will only be validated & you'll receive a report of the detected changes in the CSV. This allows you to verify the changes are correct before applying them. (NOTE: applying the changes requires re-submitting the CSV with the "Validate Only" option deselected) - Release Notes#7.3ReleaseNotes |
Command Line Import
The following table summarizes the basics.
...
- It's possible the CSV was not saved properly after editing. Check that the edits are in the CSV, and that there were no backend errors in the DSpace logs (which would be an indication of an invalid or corrupted CSV file)
- Depending on the version of DSpace, you may be encountering this known bug with processing linebreaks in CSV files: DS-3245: https://github.com/DSpace/DSpace/issues/6600
- If you are If you are setting a new embargo date in the CSV, ensure that the embargo lift date is a future date. It's been reported that past dates may cause DSpace to ignore item changes.
Batch Editing, Entities and Relationships
Consider the following page for this topic: Configurable Entities
Background about entities and virtual metadata
In DSpace 7, we have entities. Entities are items with an entity type (there can still be items without an entity type).
Two entities can be linked to each other. For this purpose relations are defined, which indicate the relationship between the entities. Relationships between two entities are defined by the metadata schema relation. The relation reflects how two entities are related to each other, for example isPersonOfProject or isPublicationOfAuthor.
Until the introduction of entities, we could only link items to each other by inserting DOIs or URLs of other items into metadata fields dc.relation.*. What is new about the linking between entities in DSpace 7 is that UUIDs are entered into the fields, i.e. internal identifiers of other entities that DSpace can easily resolve. DSpace "knows" which entities are linked to each other and how.
On the item view of an entity (remember: an entity is an item with an entity type) metadata of other entities can be displayed. DSpace refers to this as virtual metadata. Virtual metadata does not belong to the item in whose item view it is displayed, but to a linked entity. They can be changed only in the linked entity. As an example: we have the entities journal and journal issue. All journal issues display the title of the journal in their item view. This title is stored only in the journal and is only (dynamically) displayed in the issues.
Admin CSV export
Virtual metadata is exported with the entities in which it is included. For example, when you export projects, you see a column for the project.investigator field. Here, the names of two people have been included as virtual metadata. However, the names are not stored in the project, but exported from the respective person entities at the time of export. The specification ::virtual:: marks this. The specifications ::8585:: and ::27946:: are examples for this documentation and represent IDs of the relations. The specification ::600 comes from the DSpace Authority, which is also specified due to technical circumstances.
The relation itself is also included in the CSV export, in the relation.isPersonOfProject field. Additionally, a relation.isPersonOfProject.latestForDiscovery field is created. This field has internal reasons in DSpace and should help to make things faster discoverable. In the fields you again see the ::virtual::8585::600 specification, which are already explained above. Instead of the values of individual metadata fields, you now have the UUIDs of the items that are linked. You can always get these UUIDs from the URL of the item view of an item.
An example heading row of the CSV export file (project entity):
Code Block |
---|
id,collection,dc.title,project.investigator,relation.isPersonOfProject,etc,etc,etc. |
Subsequent example row in the CSV export file (project entity):
Code Block |
---|
350,2292,Project title,"Smith, John::virtual::8585::600||Doe, Jane::virtual::27946::600","d89c1eb1-2e7c-4912-a1eb-f27b17fd6848::virtual::8585::600||e3595b14-6937-47b9-b718-1972cb683943::virtual::27946::600" |
Admin CSV import
As always, only the columns and rows that will be changed should be specified. You do not want to import the columns that contain virtual metadata, because they are not stored in the imported items, but in the linked items. So in the above example you don't want to import the project.investigator column, but delete it from the CSV.
To link one item to another you need to create a corresponding column of the relation metadata schema, so in our example above relation.isPersonOfProject. All columns of the form relation.*.latestForDiscovery are created and updated automatically, so you don't want to import them. If you want to create a new relation, of course you don't know the ID of the relation, you can replace it with a +, then DSpace will assign it on its own. Of course, people can also be removed from the column or completely new relations can be created for new items, even if there are no old ones to be taken over.
An example heading row for the CSV import file (project entity):
Code Block |
---|
id,collection,dc.title,relation.isPersonOfProject,etc,etc,etc. |
Subsequent example row for the CSV import file (project entity):
Code Block |
---|
350,2292,Project title,"d89c1eb1-2e7c-4912-a1eb-f27b17fd6848::virtual::8585::600||e3595b14-6937-47b9-b718-1972cb683943::virtual::+::600" |