View
248
Download
0
Tags:
Embed Size (px)
Citation preview
Common Workflows
DigiTool Version 3.0
Workflows 2
Deposit
Approval
Search&
Index
Dispatcher &
Viewers
Single&
Bulk
Web Services
DigiTool Modules
Workflows 3
Common Workflows
Add New Administrative Unit
Deposit - Ingest – Meditor – Harvest
Ingest (MD + Streams) – Meditor
Add new MD fields
Miscellaneous
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
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
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.
Workflows 7
Common Workflows
Add New Administrative Unit
Deposit - Ingest – Meditor – Harvest
Ingest (MD + Streams) – Meditor
Add new MD fields
Miscellaneous
Workflows 8
Deposit -> Ingest -> Meditor -> HarvestThe 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.
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).
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.
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.
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).
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.
Workflows 14
Common Workflows
Add New Administrative Unit
Deposit - Ingest – Meditor – Harvest
Ingest (MD + Streams) – Meditor
Add new MD fields
Miscellaneous
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.
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:
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.
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.
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.
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).
Workflows 21
Common Workflows
Add New Administrative Unit
Deposit - Ingest – Meditor – Harvest
Ingest (MD + Streams) – Meditor
Add new MD fields
Miscellaneous
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)
Workflows 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
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
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
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
Workflows 27
Add new local Dublin Core field(s) – Q41. 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.
Workflows 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.
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:
<dcterms:myField xsi:type="dcterms:myEncoding1">, <dcterms:myField xsi:type="dcterms:myEncoding2"><dcterms:myField xsi:type="dcterms:myEncoding3">
Note: Attributes are not required.
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
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.
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 formsRepository indexingMeditor catalogingSilo harvest Silo indexingDisplay from Resource Discovery
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 – <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.
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.
<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>
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)
Workflows 36
Add new MD fields – Repository indexing
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.
<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.
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.
<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.
Workflows 39
Edit/Add new MD fields – Silo IndexingAdding 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
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.
<find_code> <code>WMY</code> <option_name lng="ENG">My Field</option_name> </find_code>
Workflows 41
Edit/Add new MD fields – RD DisplayAdding 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>
Workflows 42
Common Workflows
Add New Administrative Unit
Deposit - Ingest – Meditor – Harvest
Ingest (MD + Streams) – Meditor
Add new MD fields
Miscellaneous
Workflows 43
Deep Linking - Example
Deep Link search requests are possible in DigiTool
For an example, click here, and then View the Source.
Workflows 44
www.exlibrisgroup.com
Thank you!