1 / 44

Common Workflows

Common Workflows. DigiTool Version 3.0. DigiTool Modules. Deposit. Approval. Web Services. Dispatcher & Viewers. Single & Bulk. Search & Index. Common Workflows. Add New Administrative Unit Deposit - Ingest – Meditor – Harvest Ingest (MD + Streams) – Meditor Add new MD fields

zack
Télécharger la présentation

Common Workflows

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Common Workflows DigiTool Version 3.0

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

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

  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. 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. 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. Common Workflows • Add New Administrative Unit • Deposit - Ingest – Meditor – Harvest • Ingest (MD + Streams) – Meditor • Add new MD fields • Miscellaneous

  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. 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. 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. 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. 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. 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. Common Workflows • Add New Administrative Unit • Deposit - Ingest – Meditor – Harvest • Ingest (MD + Streams) – Meditor • Add new MD fields • Miscellaneous

  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. 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. MARC X-Path Definition for DE Template • @@856/#/#/u@@ • @@245/#/#/a@@ Above represents potential default tags. Note: any MARC tag may be used.

  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. 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. 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. Common Workflows • Add New Administrative Unit • Deposit - Ingest – Meditor – Harvest • Ingest (MD + Streams) – Meditor • Add new MD fields • Miscellaneous

  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. Add new local Dublin Core field(s) The following example workflow represents: Run the following: >> dp >> add_new_dc_tag.pl <adminunit> For instance: >> add_new_dc_tag.pl ADM01

  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. 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. 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. 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. Add new local Dublin Core field(s) – Q5 Help on tag text (<BR> 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. 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: <dcterms:myField xsi:type="dcterms:myEncoding1">, <dcterms:myField xsi:type="dcterms:myEncoding2"> <dcterms:myField xsi:type="dcterms:myEncoding3"> Note: Attributes are not required.

  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. 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. Implementing/Editing Tags • 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. 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 – <Language> • 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. 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. • <field index_enabled="true" search_enabled="true" ui_code="201" ui_default_text="Title" index_code="2001" normalizing_profiles_ref="generic"> • <location type="md" md_name="descriptive" md_type="marc" path="245/#/#/a"/> • <location type="md" md_name="descriptive" md_type="marc" path="246/3/3/a"/> • <location type="md" md_name="descriptive" md_type="dc" path="//dc:title"/> • <location type="md" md_name="descriptive" md_type="dc" path="//dcterms:alternative"/> • <location type="md" md_name="descriptive" md_type="dc" path="//dcterms:myField"/> • </field> • or • <field index_enabled="true" search_enabled="true" ui_code="201" ui_default_text=“MyField" index_code="2001" normalizing_profiles_ref="generic"> • <location type="md" md_name="descriptive" md_type="dc" path="//dcterms:myField"/> • </field>

  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. Add new MD fields – Repository indexing

  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. • <dcterms:myfield> • <type> text </type> • <name> My Field </name> • <occurs> 0* </occurs> • </dcterms:myfield> • Create new md.pck Meditor table package by UTIL-K-2-4-1 • Re-connect to Meditor and catalog the field freely.

  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. • <field index_enabled="true" search_enabled="true" ui_code="M300" ui_default_text="doc-300" index_code="M400" normalizing_profiles_ref="empty"> • <location type="md" md_name="descriptive" md_type="dc" path="//dcterms:myField[not(@*)]"/> • </field> • 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. 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 automatice.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 optionale.g. • H WMY W-030 00 00 W-My Field • Run p_manage_91 indexing service – available from Meditor Services Menu

  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. • <find_code> • <code>WMY</code> • <option_name lng="ENG">My Field</option_name> • </find_code>

  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: • <column> • <code type="DATA">300##</code> • <name lng="ENG">My Field</name> • <maxlen>100</maxlen> • <editfield>S</editfield> • </column> • Brief results: • <element> • <code type="DATA">300##</code> • <name lng="ENG">My Field</name> • <maxlen>100</maxlen> • <editfield>S</editfield> • </element> • Full results: • <line> • <code type="DATA">300##</code> • <name lng="ENG">My Field</name> • <editfield>D</editfield> • </line>

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

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

  44. Thank you! www.exlibrisgroup.com

More Related