Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 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. This contains values such as <lastname1>, <firstname1>::virtual::8585::600||<lastname2>, <firstname2>::virtual::27946::600. 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 for example with the value d89c1eb1-2e7c-4912-a1eb-f27b17fd6848. 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||e3595b14-6937-47b9-b718-1972cb683943::virtual::27946::600. 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 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. For example, a valid new entry in the relation.isPersonOfProject column might then look like this: 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

...

"