Page History
...
NOTE: that this model includes the same "Publication" entity as the Research Entities model described above. This Entity overlap allows you to link an article (Publication) both to its author (Person) as well as the Journal Issue it appeared in.
Enabling Entities
By default, Entities are not used in DSpace. But, as described above several models are available out-of-the-box that may be optionally enabled.
Note |
---|
Keep in mind, there are a few DSpace import/export features that do not yet support Entities in DSpace 7.0. These will be coming in future 7.x releases. See DSpace Release 7.0 Status for prioritization information, etc.
|
...
|
1. Configure your entity model (optionally)
As described above, DSpace provides two default entity models defined in [dspace]/config/entities/relationship-types.xml.
These models may be used as-is, or modified.
You can also design your own model from scratch (see "Designing your own model" section below). So, feel free to start by modifying relationship-types.xml
, or creating your own model based on the relationship-types.dtd
.
2. Import
...
entity model into the
...
database
In order to enable a defined entity model, it MUST be imported into the DSpace database This is achieved by using the "initialize-entities" script
...
. The example below will import the "out-of-the-box" entity models into your DSpace installation
Code Block |
---|
# The -f command requires a full path to an Entities model configuration file.
[dspace]/bin/dspace initialize-entities -f [dspace]/config/entities/relationship-types.xml |
If an Entity (of same type name) already exists, it will be updated with any new relationships defined in relationship-types.xml
If an Entity (of same type name) doesn't exist, the new Entity type will be created along with its relationships defined in relationship-types.xml
3. Configuration of
...
community/collection list for Entity types
Because all Entities are Items, they MUST belong to a Collection. Therefore, the easiest way to create a different submission forms per Entity type (e.g. Person, Project, Journal, Publication, etc) is to ensure you create a Collection for each Entity Type (as each Collection can have a custom Submission Form).
- Create at least one Collection for each Entity Type needing a custom Submission form. For example, a Collection for "Person" entities, and a separate one for "Publication" entities.
- Edit the Collection, and create a Template Item (which is used for all Entities/Items submitted to that Collection) from the "Edit Metadata" tab
- In the Template Item, add a single metadata field "dspace.entity.type". Give it a value matching the Entity type (e.g. Publication, Person, Project, OrgUnit, Journal, JournalVolume, JournalIssue). This value IS CASE SENSITIVE and it MUST match the Entity type name defined in relationship-types.xml
- This single metadata field will ensure that every Item submitted to this collection is automatically assigned that Entity type. So, it ties this Collection to that type of Entity.
- In the Template Item, add a single metadata field "dspace.entity.type". Give it a value matching the Entity type (e.g. Publication, Person, Project, OrgUnit, Journal, JournalVolume, JournalIssue). This value IS CASE SENSITIVE and it MUST match the Entity type name defined in relationship-types.xml
- In the Edit Collection page, switch to the "Assign Roles" tab and create a "Submitters" group. Add any people who should be allowed to submit/create this new Entity type.
- If you only want Administrators to create this Entity type, you can skip this step. Administrators can submit to any Collection.
- If you want to hide this Collection, you can choose to only make it visible to that same Submitters group (or Administrators). This does NOT hide the Entities from search or browse, but it will hide the Collection itself.
- In the Edit Collection page, switch to the "Authorizations" tab.
- Add a new Authorization of TYPE_CUSTOM, restricting "READ" to the Submitters group created above (or Administrators if there is no Submitters group). You can also add multiple READ policies as needed. WARNING: The Submitters group MUST have READ privileges to be able to submit/create new Entities.
- Remove the default READ policy giving Anonymous permissions.
- Assuming you want the Entities to still be publicly available, make sure the DEFAULT_ITEM_READ policy is set to "Anonymous"!
Obviously, how you organize your Entity Types into Collections is up to you. You can create a single Collection for all Entities of that type (e.g. an "Author Profiles" collection could be where all "Person" Entities are submitted/stored). Or, you could create many Collections for each Entity Type (e.g. each Department in your University may have it's own Community, and underneath have a "Staff Profiles" Collection where all "Person" Entities for that department are submitted/stored). A few example structures are shown below.
Example Structure based on the departments:
- Department of Architecture
- Building Technology Program
- Theses - Department of Architecture
- Department of Biology
- Theses - Biology
- People
- Projects
OR
- Department of Architecture
- Building Technology Program
- Theses - Department of Architecture
- People in Department of Architecture
- Projects in Department of Architecture
- Department of Biology
- Theses - Biology
- People in Department of Biology
- Projects in Department of Biology
Example Structure based on the publication type:
- Books
- Book Chapter
- Edited Volume
- Monograph
- Theses
- Bachelor Thesis
- Doctoral Thesis
- Habilitation Thesis
- Master Thesis
- People
- Projects
4. Configure Submission Forms for each Entity type
You should have already created Entity-specific Collections in the previous step. Now, we just need to map those Collections to Submission processes specific to each Entity.
On the backend, you will now need to modify the [dspace]/config/item-submission.xml
to "map" this Collection (or Collections) to the submission process for this Entity type.
- DSpace comes with sample submission forms for each Entity type.
- The sample <submission-process> is defined in
item-submission.xml
and named based on the Entity type (e.g. Publication, Person, Project, etc). - The metadata fields captured for each Entity are defined in a custom step in
submission-forms.xml
, and named in the format "[entityType]Step" (where the entity type is camelcased). For example: "publicationStep", "personStep", "projectStep".
- The sample <submission-process> is defined in
- Optionally, modify those sample submission forms. See Submission User Interface for hints/tips on customizing the
item-submission.xml
orsubmission-forms.xml
files Now, in
item-submission.xml
, map your Collection's handle (findable on the Collection homepage) to the submission form you want it to use. In the below example, we've mapped a single Collection to each of the out-of-the-box Entity types
Configuration of Entity types and their relations
There are 2 approaches possible here:
- Re-using one of the models previously created in the community
- Designing your own model
Both parts will be explained in detail
Re-using one of the models previously created in the community
The models currently available in the community are:
- Research Entities
- Journals
- OpenAire (in progress)
In order to start using such a model, the following steps should be used
Configuration of the submission forms per item type
A collection should contain only objects of one item type. E.g. there would be one (or even multiple) collections for Person objects. The submission forms of the collection(s) for Person objects would contain metadata only applicable for the Person item type. Since the item type is stored in the metadata, the collection template can be used to store the item type metadata value.
There’s no need to remain stuck in the model where collections represent departments, and both Publication and Person objects should be stored under the department’s collection.
- In the edit collection, an item template should be created containing
dspace.entity.type
with valuePublication
,Person
or whatever entity/item type should be submitted to that collection. - In the edit collection, the submit group should be defined to identify who can submit to this collection
In item-submission.xml, the collection handle should be linked to the applicable submission-definitions in the file, e.g.
Code Block <name-map collection-handle="123456789/65" submission-name="PeoplePublication" /> <name-map collection-handle="123456789/2796" submission-name="PeoplePerson" /> <name-map collection-handle="123456789/7" submission-name="Project" /> <name-map collection-handle="123456789/280" submission-name="Project" /> <name-map collection-handle="123456789/8" submission-name="OrgUnit" /> <name-map collection-handle="123456789/28" submission-name="JournalsJournal" /> <name-map collection-handle="123456789/29" submission-name="JournalVolumesJournalVolume" /> <name-map collection-handle="123456789/30" submission-name="JournalIssuesJournalIssue" />
...
Once your modifications to the submission process are complete, you will need to quickly reboot Tomcat (or your servlet container) to reload the current settings.
4. Configure Workflow for each Entity type (optionally)
The DSpace workflow can be used for reviewing all objects in the Object Model since these objects are all itemsItems, and separate collections can be used. The workflow used for e.g. a Person Object can be configured to be identical to a publication, different from a publication, or use no workflow at all.
The users who are granted permissions to create a Person Object are determined by the submitters group of that collection.
Configuration of community/collection list for item types
The community list is very flexible, and institutions can use it for various purposes. By using collections for the item types, additional collections can be created in the community/collection list. Extending existing community/collection structures to include collections per item type, can be done using a single collection for the other item types. This is typically useful if the structure is not applicable for the other item types, or should not be displayed. In this use case, it would also be possible to not grant Anonymous READ rights on the People, Projects collections to ensure they’re not visible on the community/collection list page. Or extending these to include collections per item type, can be performed using multiple collections for the other item types. This is typically applicable when they should be clearly displayed in the structure:
Structure based on the departments:
- Department of Architecture
- Building Technology Program
- Theses - Department of Architecture
- Department of Biology
- Theses - Biology
- People
- Projects
OR
- Department of Architecture
- Building Technology Program
- Theses - Department of Architecture
- People in Department of Architecture
- Projects in Department of Architecture
- Department of Biology
- Theses - Biology
- People in Department of Biology
- Projects in Department of Biology
Structure based on the publication type:
- Books
- Book Chapter
- Edited Volume
- Monograph
- Theses
- Bachelor Thesis
- Doctoral Thesis
- Habilitation Thesis
- Master Thesis
- People
- Projects
OR
...
- Book Chapter
- Edited Volume
- Monograph
...
- Bachelor Thesis
- Doctoral Thesis
- Habilitation Thesis
- Master Thesis
...
See Configurable Workflow for more information on configuring workflows per Collection.
Designing your own model
When using a different entities model, the new model has to be configured an loaded into your repository
...