1. Common Workflows DigiTool Version 3.0

2. Workflows 2 Deposit Approval Search & Index Dispatcher & Viewers Single & Bulk Web Services DigiTool Modules

3. Workflows 3 Common Workflows Add New Administrative Unit Deposit - Ingest – Meditor – Harvest Ingest (MD + Streams) – Meditor Add new MD fields Miscellaneous

4. Workflows 4 Add a New Admin Unit To add a new unit to DigiTool, carry out the following steps: From the Unix command prompt, enter: >dp >source p_create_new_unit

5. Workflows 5 Add a New Admin Unit To allow work in the new unit: Perform the following: > cd $dtle_root > dtl_shutdown Followed by: > dtl_startup

6. Workflows 6 Add a New Admin Unit A new staff user by the name of the new Admin unit will have been created as part of the script : For instance, when creating new unit ADM01: Staff user/Password ADM01/ADM01 is created. This user has full privilege within the ADM01 unit. Additionally, all ADMIN staff users will be granted full permission in the new unit.

7. Workflows 7 Common Workflows Add New Administrative Unit Deposit - Ingest – Meditor – Harvest Ingest (MD + Streams) – Meditor Add new MD fields Miscellaneous

8. Workflows 8 Deposit -> Ingest -> Meditor -> Harvest The following example workflow represents: Deposits that are submitted, reviewed and approved. Following their approval, and depending on the deposit workflow used, the deposit undergoes certain ingest rules whereby all the submitted information is loaded into the repository in the desired manner. Once in the repository, each file attains a new PID with certain metadata which can be further tailored and honed for end-user access. Once ready for end-user access, the PID can be harvested and made available for end-user search and exploration.

9. Workflows 9 Deposit -> Ingest -> Meditor -> Harvest Deposits that are submitted, reviewed and approved. Depositor submits the.pdf version of his doctoral thesis using the institution’s ETD workflow. The workflow provides a DC form, access rights association and ability to upload one.pdf file. The workflow also has a certain behind-the-scenes post- approval setting, which determines how the deposit will be relayed to the ingest module after review and approval e.g. manual, automatic, tasks, assignment, etc. (Let’s assume ETDs utilize manual ingest and assigned to staff user DTL02).

10. Workflows 10 Deposit -> Ingest -> Meditor -> Harvest Deposits that are submitted, reviewed and approved. Staff approver receives the submitted deposit and reviews its contents. This may involve editing metadata, relaying a note to the depositor for more information or simply returning the deposit for lack of information. Once the staff user deems the deposit to be appropriate for approval, the deposit is approved.

11. Workflows 11 Deposit -> Ingest -> Meditor -> Harvest Following their approval, and depending on the deposit workflow used, the deposit undergoes certain ingest rules whereby all the submitted information is loaded into the repository in the desired manner. Staff ingest user DTL02 receives the assigned ingest activity and must decide the ingest routine appropriate for the deposit. Staff ingest user DTL02 might decide to run the ingest using a task chain involving full text indexing and technical md extraction that will be scheduled for tonight at 22:00 pm. The ingest runs successfully at 22:00 pm and from the Task log, we ascertain the related PIDs now in the repository.

12. Workflows 12 Deposit -> Ingest -> Meditor -> Harvest Once in the repository, each file attains a new PID with certain metadata which can be further edited and honed for end-user access. Staff Meditor user with rights in the Admin unit DTL02 searches for the new PID or by any indexed field to access the new repository element. Once found, the staff user may wish to tailor the existing metadata or add new metadata. Save all md and object changes and the element is now ready for harvest (into the Silo – Resource Discovery).

13. Workflows 13 Deposit -> Ingest -> Meditor -> Harvest Once ready for end-user access, the PID can be harvested and made available for end-user search and exploration. From the Staff Meditor “Services” menu, choose Silo Maintenance Procedures – Harvest Repository into Silo (p-harvest-01) Assuming this PID fits the rules for harvest based on Silo definitions and service paramaters, this PID will be harvested successfully and automatically indexed and added to the set of resources available to the end-user from the Resource Discovery.

14. Workflows 14 Common Workflows Add New Administrative Unit Deposit - Ingest – Meditor – Harvest Ingest (MD + Streams) – Meditor Add new MD fields Miscellaneous

15. Workflows 15 Ingest MD with Files -> Meditor The following example workflow represents: MARC or Dublin Core XML that should be prepared in conjunction with files that should be associated with the records. Editing these records/files from the Meditor after ingest.

16. Workflows 16 Ingest MD with Files -> Meditor MARC or Dublin Core XML that should be prepared in conjunction with files that should be associated with the records: Staff ingest user prepares a MARCXML or DCXML schema compliant.xml file. Staff user decides on the files which should be associated to each record. Within the xml file, the full filename is defined in any of the MARC or DC tags defined in the DE template to be used in the ingest activity. For instance:

17. Workflows 17 MARC X-Path Definition for DE Template @@856/#/#/u@@ @@245/#/#/a@@ Above represents potential default tags. Note: any MARC tag may be used.

18. Workflows 18 DC X-Path Definition for DE Template @@dc:identifier@@ @@dc:identifier[@xsi:type='dcterms:URI']@@ Above represents potential default tags. Note: any DC tag may be used.

19. Workflows 19 Ingest MD with Files -> Meditor Template Digital Entity is created in the admin unit’s /conf/template/ directory to represent the placeholders used in the MARC or DC xml file. DTL02 user runs ingest using MARC transformer and D.E. template. Ingest success provides 1 md file PID per 1MARC or DC record.

20. Workflows 20 Ingest MD with Files -> Meditor Staff Meditor user with rights in the Admin unit DTL02 searches for the new PID or by any indexed field to access the new repository element. Once found, the staff user may wish to tailor the existing metadata or add new metadata. Save all md and object changes and the element/s are now ready for harvest (into the Silo – Resource Discovery).

21. Workflows 21 Common Workflows Add New Administrative Unit Deposit - Ingest – Meditor – Harvest Ingest (MD + Streams) – Meditor Add new MD fields Miscellaneous

22. Workflows 22 Add new MD fields The following example workflow represents: Adding local Dublin Core fields which will be available and recognized in the following modules/functions: Deposit forms (automatic as part of script) Repository indexing (not part of script – recommendation only) Meditor cataloging (automatic as part of script) Silo harvest (not part of script – recommendation only) Silo indexing (not part of script – recommendation only) Display from Resource Discovery (not part of script – recommendation only)

23. Workflows 23 Add new local Dublin Core field(s) The following example workflow represents: Run the following: >> dp >> add_new_dc_tag.pl For instance: >> add_new_dc_tag.pl ADM01

24. Workflows 24 Add new local Dublin Core field(s) – Q1 Field Code (one word, lower case only) : Field Code represents the name of the field to be used - without the dc or dcterms namespace. For instance: myField

25. Workflows 25 Add new local Dublin Core field(s) – Q2 Field Name : The Field Name represents the name of the field for display purposes. For instance: My Field

26. Workflows 26 Add new local Dublin Core field(s) – Q3 1. dc 2. dcterms Select Name Space : (1-2) : Defines whether the field will utilize the dc or dcterms namespace. e.g. dc:myField versus dcterms:myField

27. Workflows 27 Add new local Dublin Core field(s) – Q4 1. Optional unbounded ( 0* ) 2. Optional single (0-1) 3. Mandatory single ( 1 ) 4. Mandatory unbounded ( 1* ) Select Number of occurrences allowed for tag : (1-4) : Each option relates to the cataloging rules that will be employed when cataloging the newly added field. 1. Optional unbounded - field may occur 0 or more times in a single md record. 2. Optional single - field may appear 0 or 1 time in a single md record. 3. Mandatory single - field must appear exactly 1 time in a single md record. 4. Mandatory unbounded - field must occur at least 1 time in a single md record.

28. Workflows 28 Add new local Dublin Core field(s) – Q5 Help on tag text ( for new line) : This allows the user to explain to other catalogers the intended use of the tag. The help will show up in context sensitive help from the Meditor when the tag is active.

29. Workflows 29 Add new local Dublin Core field(s) – Q6 Does tag have attributes [y]/n ? This y/n question allows the user to decide whether encoding is required for definition as part of the local field you are adding. An example of encoding which may be required:, Note: Attributes are not required.

30. Workflows 30 Add new local Dublin Core field(s) – Q7 Attribute name(s) (semicolon separated-one word per semicolon separated value): This allows the definition of the encoding values to be used in conjunction with the newly defined local field. For instance: myEncoding1;myEncoding2;myEncoding3

31. Workflows 31 Add new local Dublin Core field(s) – Q8 1. Run Now 2. Report Mode Select desired running method: (1-2): 1. Run now will implement the new tag in the appropriate locations - denoting indexing recommendation setup and actions performed in a log file. 2. Report Mode outputs a log file of intended actions and recommendations without actually performing the changes.

32. Workflows 32 Implementing/Editing Tags 1.To implement the changes done as part of the Add Dublin Core field script, re-start web and pc servers. >> start_w >> start_pc 2. Editing of each change or recommended change can be found in the following slides per function: Deposit forms Repository indexing Meditor cataloging Silo harvest Silo indexing Display from Resource Discovery

33. Workflows 33 Edit MD fields – Deposit Forms Editing Dublin Core fields which will be available and recognized for use in the deposit forms: From the management (“mng”) interface, click the top menu “Common” tab Choose the following sequence of dropdown menu values: Deposit – DC Elements – Edit and save the fields in the displayed list of DC fields. The changes are globally stored and applied for all Admin unit deposit forms.

34. Workflows 34 Edit/Add MD fields – Repository Indexing Adding local Dublin Core fields which will be indexed and searchable within the repository: Server-side configuration file j_conf/repository_indexing_schema.xml Add field either pooled with other tags or as separate entity for index and search. e.g. or

35. Workflows 35 Edit/Add MD fields – Repository Indexing Re-load repository configuration utilizing the maintenance procedure named “Reload repository configuration” available from the management module. (or re-start JBOSS)

36. Workflows 36 Add new MD fields – Repository indexing

37. Workflows 37 Edit MD fields – Meditor Cataloging Editing Dublin Core fields which should be made available for Meditor cataloging Note: This is performed automatically according the the definitions of the script - noted below describes implementing changes needed afterward: Server-side admin unit file $data_root/md/descriptive/dc/editor_conf.xml Edit field in schema: e.g. text My Field 0* Create new md.pck Meditor table package by UTIL-K-2-4-1 Re-connect to Meditor and catalog the field freely.

38. Workflows 38 Edit/Add MD fields – Silo Harvest Allowing local Dublin Core fields to be harvested through p_harvest_01. Server-side file $dtle_tab/tab12 e.g. 300 MyField Server-side GEN01 file $data_root/tab/harvesting_schema.xml e.g. Note: Any field not in the harvesting_schema.xml will not be able to be displayed or indexed independently, but rather will be grouped into the “all metadata” group and searchable only in the broader indexes.

39. Workflows 39 Edit/Add new MD fields – Silo Indexing Adding local Dublin Core fields which will be indexed and available for search from the Resource Discovery. Server-side file $dtle_tab/tab12 automatic e.g. 300 MyField Server-side GEN01 file $data_root/tab/tab01.eng automatic e.g. D 300 00 0000 300 LMyField Server-side GEN01 file $data_root/tab/tab11_word automatic (optional dedicated code not automatic) e.g. 300## a 03 WRD WMY Server-side GEN01 file $data_root/tab/tab00.eng optional e.g. H WMY W-030 00 00 W-My Field Run p_manage_91 indexing service – available from Meditor Services Menu

40. Workflows 40 Edit/Add new MD fields – Silo Indexing Adding local Dublin Core fields that are already indexed and available for individual search (advanced) from the Resource Discovery. Server-side GEN01 file $data_root/tab/www_r_silo_conf.xml e.g. WMY My Field

41. Workflows 41 Edit/Add new MD fields – RD Display Adding local Dublin Core fields which will be viewed in the RD (result views). Server-side GEN01 file $data_root/tab/www_r_silo_conf.xml e.g. Table results: 300## My Field 100 S Brief results: 300## My Field 100 S Full results: 300## My Field D

42. Workflows 42 Common Workflows Add New Administrative Unit Deposit - Ingest – Meditor – Harvest Ingest (MD + Streams) – Meditor Add new MD fields Miscellaneous

43. Workflows 43 Deep Linking - Example Deep Link search requests are possible in DigiTool For an example, click here, and then View the Source.click here

44. Workflows 44 www.exlibrisgroup.com Thank you!