Subject: PeopleSoft Requisition / Workflow Training |
Overview: |
The following is a base document to be used for training purposes. It contains various topics related to PeopleSoft Requisitions and Workflow, and these topics may be selectively combined in order to provide a variety of customized training modules. The topics of How to Create a Requisition, How to Approve a Requisition, Routing vs. Approval Authority and How to Turn a Requisition into a PO are geared more towards end users, whereas Role of the Workflow Administrator, Workflow Objects, Technical Process Flow and Workflow Setup are geared more towards IT Support personnel. Developed but not Implemented and Comparison to Oracle Workflow are geared towards system architects and future implementors, and About Reusable Learning Objects is for MIS educators and directors. There may be some overlap as well. For example, power users may be interested in some of the technical topics, and functional IT support personnel may be interested in the requisition creation and approval topics. This document is compliant with CanCore standards regarding Learning Object Metadata (LOM). |
Creating a Requisition |
Follow these steps to create a requisition: |
Approving a Requisition |
Follow these steps to approve a requisition: If this requisition was routed to you in error, and you know who should approve it, simply open your worklist and 'Reassign' it to the correct approver (Images\Appr08.jpg, Images\Appr08a.jpg). This can happen if you change departments, for example, and a former employee of yours submits a requisition to you prior to HR updating their records. If you do not know who should approve this requisition, you may also 'Recycle' it back to its originator, or 'Deny' it. If you are going on vacation and expect to receive worklist items, you may delegate authority to another user (Images\Appr09.jpg). You must select a 'From' and 'To' date. During this time, all worklist items will be rerouted to whomever you select. Notice that when you click on the drop-down list, the only options available to you are your peers and your supervisor. If you delegate to a peer, for example, and he does not have sufficient approval limits to approve a requisition, it will be routed afterwards to his supervisor, and so on. |
Routing vs. Approval Authority |
In PeopleSoft, it is important to differentiate between routing and approval authority. Routing only refers to where the requisition will go next. Approval authority refers to the dollar limit for which the current approver is authorized (based on position in the company). The following describes how a requisition is routed: The following describes how approval authority is determined each time somebody receives a requisition to approve: There are some additional rules which we have chosen to implement procedurally since they occur infrequently. |
Converting a Requisition into a PO |
The following steps are followed to turn a requisition into a purchase order. |
Role of the Workflow Administrator |
Timeout notification occurs as a result of running the process illustrated (Images\Admin01.jpg). When you run this process, e-mails will be sent to both requestors and approvers, indicating that their request has not been approved within 3 days (Images\Admin01b.jpg, Images\Admin01c.jpg). This process will be scheduled to run periodically throughout the day, but the Workflow Administrator may also run it manually at any time. The administrator can also choose to manually time them out one at a time (Images\Admin01a.jpg), even if 3 days have not lapsed. The Administrator can also set limits and monitor the level of worklist activity (Images\Admin02.jpg). The monitor can be scheduled to run periodically (Images\Admin02a.jpg). The Administrator has complete control over the status of a worklist item. First, a query page is used to find the worklist in question (Images\Admin03.jpg). After clicking the 'Search' button, navigate to the 'Worklist Entries' page. Worklist items can also be accessed via the context page (Images/Admin04.jpg), or directly from the 'Update Worklist Entries' page (Images/Admin05.jpg). The latter is by far the most direct approach, but it requires knowledge of the worklist #. Approval limits can be reset via the following page: Images/Admin06.jpg. A complete audit trail for a requisition, from initiation to final approval, can be seen from the following page: Images/Admin07.jpg. Here are the steps to perform an administrative approval (i.e. where the approver does not have access to PeopleSoft). |
Workflow Objects |
The following objects are used to configure PeopleSoft Workflow. TriggerBusinessEvent() methods are used to initiate a workflow process. These are PeopleCode functions that tell Activities to fire. As input parameters, they accept the name of the activity, and they return a boolean which indicates whether the activity fired successfully. This method is executed when a user submits a requisition for approval, for example, or when a requisition is approved, or denied, or recycled. This code can appear just about anywhere (e.g. The FieldChange event associated with a push button). It does not have to be part of the 'Workflow' event, although this is customary. Activities (Images\Obj07.jpg) are the fundamental building blocks of workflow routing. An activity is called by a TriggerBusinessEvent() method, and is used to direct what will happen next. Activities can contain many objects, but at a minimum, they must consist of the following: The S_SUPERVISOR activitiy that you just saw was to route worklist items from the submitter to the supervisor. To recycle an activity back to the originator, the S_RECYCLE activity is used (Images\Obj14.jpg). Notice that it also contains an E-mail object, which has many of the same properties as a worklist object, but sends an e-mail message instead. A Timeout activity is delivered with PeopleSoft (Images\Obj15.jpg), and is used to notify both recipient and approver in the event of timeout processing (our only change to this object was to customize its message content). The Notify Requestor Activity is also delivered (Images\Obj16.jpg), and is used to notify the requestor in the event of final approval or denial. Business Process: A business process is simply a group of activities (Images\Obj17.jpg). When referring to an activity in a TriggerBusinessEvent() method, you must know what business process the activity belongs to. Activities can be associated with more than one business process. Also, although we have used only one business process at SeeBeyond, it is possible to build a workflow model which utilizes multiple business processes and activities, forming a directed graph structure. For requisitions, the starting point of this directed graph is defined at the Purchasing Business Unit level (Images\Setup11.jpg). Approval Rule Set: Approval rule sets are used to determine if a given approver has authority to approve a particular requisition (Images\Obj01.jpg). Each object on the approval rule set is called an approval step (see below). This should not be confused with routing. Worklist items are not necessarily routed to individuals in this order. Rather, the approval rule set can be viewed as a decision tree that is used each time an approval takes place to determine whether the approver was authorized. An approval rule set contains certain properties (Images\Obj05.jpg) that control whether it is active, whether self-approval is allowed, the name of the associated business process (Images\Obj06.jpg), as well as some optional features that are not used at SeeBeyond. Rule Steps: Each icon on the approval rule set is called a rule step. A rule step can be viewed as a node on a decision tree, where the tree is used to decide whether a particular user is authorized to approve an item (as previously mentioned). Notice that each step definition (Images\Obj02.jpg) lists all subsequent steps as 'Equally Authorized'. This means that if a MANAGER is authorized, then so is a DIRECTOR, MANAGING DIRECTOR, VICE PRESIDENT, etc. Thus, we have configured each step to include all subsequent steps as equally authorized. Notice also that in the lower left corner, each step has a 'Step Number', which starts at zero and increases by 1 for each subsequent step. The 'Path Number' is always 'A' since we do not have any parallel paths, though this is also possible. The Rules tab (Images\Obj03.jpg) is used to specify the dollar limits for this step. Quantities can also be specified, as well as more complex rules in the Route Control section (such as chartfield values), though this has not been implemented. Finally, the 'Events' tab specfies which activity to fire when somebody at this step approves, denies or recycles the item (Images\Obj04.jpg). (Note: The 'Approval' section only applies when the approver is not authorized.) For example, suppose that a MANAGER approves a requisition for $5,000. The following logic would be used to determine whether she is authorized: |
Technical Process Flow |
The following is a technical description of the requisition workflow process flow. The intent is to aid IT personnel in troubleshooting workflow-related cases. |
Workflow Setup |
The following is a list of workflow setup instructions. The intent is to aid IT personnel in modifying workflow rules, or in troubleshooting workflow-related cases. |
Developed But Not Implemented |
The original prototype included both amount-based approval and chartfield-based approval. In the final prototype, only amount-based approval was implemented. The following section describes the chartfield-related configuration which was not implemented. First of all, amount-based approval refers to workflow that differentiates beteween approval authority purely based on dollar limits. This is the simplest of all workflow to implement. Chartfield-based approval is a more complex, generalized approval methodology. The term 'chartfield' in PeopleSoft refers to a financial field, such as 'Account' or 'Department'. However, chartfield-based approval can include other criteria, such as amount. We chose not to implement chartfield-approval because it would have applied to less than 10 approvers, whereas amount-based approval applies to literally hundreds of approvers. The costs of implementing chartfield-approval outweighed the benefits. The following setup was part of the original prototype, but not implemented: When implemented, the following chartfield-approval path was followed by each requisition (in parallel to the amount-based approval path). |
Comparison to Oracle Workflow |
At the time of this writing (March 2005), Oracle has recently acquired PeopleSoft and announced its plans to merge the two ERP applications into one 'super-application' by 2013 (known as Project Fusion). Oracle has not yet provided deals of its development path. The Oracle E-Business application is written in Java, whereas PeopleSoft is written in its own proprietary development language (i.e. PeopleSoft Application Designer). Eventually, Application Designer will go away and be replaced by Java. We don't know yet how this will occur. However, there are at least three general approaches that could be taken: In many cases, first option may be cheaper, provided it can be done successfully. The second option may require a significant development effort since it would require a virtual reproduction of the PeopleSoft tool set into Java, and would only be worthwhile if a large number of modules were recreated. Oracle may find it cheapest to replace modules where it can, and rewrite them where it cannot. The following is a brief comparison between PeopleSoft and Oracle Workflow. Although I am not intimately familiar with Oracle Workflow, it would appear from their documentation that it has a very high degree of overlap with PeopleSoft Workflow. The implication is that it may be replaced by Oracle (meaning that we will have to re-implement). There appear to be no functionality gaps, so we should be able to support our existing approval processes. Oracle Workflow has a very similar look and feel to PeopleSoft. Both allow browser access. Both provide a graphical development tool (Images\Oracle01.jpg) to build workflow models. Both provide notification using e-mail (Images\Oracle06.jpg) and worklists (Images\Oracle05.jpg), where the worklist item is a pointer to a data item, not the data item itself. Both are highly configurable, allowing loops and branches in the process flow, as well as time-out escalation. Both provide a workflow processing audit trail. Both applications support the XML standard for messages, and both support LDAP compatibility. Oracle Workflow can be implemented as part of the Oracle9i Integration package (Images\Oracle02.jpg), which includes Oracle9i Advanced Queuing (providing support for Oracle Net as well as HTTP and HTTPS communication protocols), as well as Oracle9i Messaging Gateway (which enables integration between Oracle Workflow and other messaging solutions such as IBM MQSeries and TIBCO Rendezvous). It can also be implemented independently. Similarly, PeopleSoft Workflow can be implemented along with Application Messaging or independently. Since SeeBeyond has not implemented Application Messaging, this section addresses only the workflow component. Both Oracle and PeopleSoft have built in workflow trigger code into their various ERP, CRM and HRMS applications (Images\Oracle03a.jpg), so that all you have to do is turn them on. One difference to note is that Oracle contains a separate application development environment for its workflow, whereas PeopleSoft treats its workflow objects just like any other object within its Application Designer. This may imply some limitations on Oracle's ability to customize its workflow, though I cannot be certain without access to the Oracle application. Oracle documentation touts the ability to modify business processes without changing application code. However, it is not clear to me what this means. i.e., Is turning on workflow considered a change in the process? Does this statement just apply to business processes where trigger code has already been built into the application? If so, the same could be said for PeopleSoft Workflow. Also, both applications allow you to introduce modifications to the workflow process without stopping production. Like PeopleSoft, Oracle Workflow is message-based, triggered by 'business events'. In both cases, synchronous messaging is used. Asynchronous messaging is provided through Oracle9i Advanced Queuing and PeopleSoft Application Messaging using publish / subscribe methodology (Images\Oracle03.jpg). Both applications use 'Activities' to control the routing of worklist items. In both cases, activities can be used to model content-based routing and error handling. Also, in both cases a workflow process can be triggered by an inbound message, can send an outbound message, or trigger another event. Another difference is that Oracle uses XML documents to trigger activity branching (Images\Oracle04.jpg), whereas PeopleSoft its own proprietary tools (i.e. role queries, PeopleCode). Both allow notifications to include dynamically generated content (i.e. personalized messages). Also, both allow you to delegate approval to others using from-to dates. Both use role-based notification, allowing notifications to change dynamically as people change positions. One difference is that the Oracle Workflow Monitor is implemented as a Java applet, whereas PeopleSoft implements it using JSP. This could have some performance impact. Also, Oracle can apparently allow users to configure which items are delegated and which items should sit in their worklist. This is something that PeopleSoft would have to be customized to do. Both provide for a Workflow Administrator who can intervene to help reroute worklist items (Images\Oracle07.jpg). However, Oracle does seem to be more powerful in its ability to Stop or pause a process, retry, skip an activity, rewind and re-execute (Images\Oracle08.jpg). In PeopleSoft, this would have to be accomplished through reassignment. It is not clear whether this would benefit SeeBeyond. |
About Reusable Learning Objects (RLO) |
Introduction:This learning module is compliant with CanCore standards regarding Learning Object Metadata (LOM). CanCore is a set of best practices for interpreting and implementing IEEE LOM standards. The CanCore initiative has been coordinated by Athabasca University and funded by Industry Canada/CANARIE, Alberta Learning, Netera Alliance, TeleCampus.edu, and the Electronic Text Centre at the University of New Brunswick. CanCore is used throughout the U.S., Canada, U.K. and France. Some examples include Athabasca University (http://adlibx.athabascau.ca/ADLib/LOR/args0/ADLib/args1/Home/?text=about), BC Campus (http://www.bccampus.ca), CELTS (China), Desire2Learn (http://www.desire2learn.com), Eisenhower National Clearinghouse (http://www.enc.org/), Canadian Treasury Board, National Science Digital Library (http://www.nsdl.org/), and UK LOM Core (http://www.cetis.ac.uk/profiles/uklomcore/). Meta data refers to information that describes the characteristics of the learning object. IEEE (p1484) identifies the following LOM categories: General, Life Cycle, Meta-Meta Data, Educational, Technical, Rights, Relation, Annotation and Classification. The IEEE standard does not define how a learning technology system will represent metadata. The purpose of the standard is to facilitate interoperability. By providing a common taxonomy, users can more easily search, evaluate, acquire, catalog, inventory and use learning objects across organizations and cultures. Learning technology systems should be able to automate this process. A sample of metadata, implemented using the CanCore LOM standard, is illustrated in the Metadata section of this document. (The underlying XML of this metadata can be found in RLO.XML). For a detailed description of the CanCore standard, complete with definitions and examples, see http://www.cancore.ca/en/dynamic/. A Reusable Learning Object (RLO) is an entity, digital or non-digital, that may be used and reused for educational purposes. RLO's (also known as lessons) are viewed as data structures made up of smaller objects called Reusable Information Objects (RIO's, also known as topics). These RIO's may be reassembled as desired to provide customized RLO's. The following is a sample hierarchy developed by Cisco for the Canadian Navy RLO project: The document you are currently reading (i.e. entitled PeopleSoft Requisitions / Workflow Training) has been implemented as an RLO, and each of the topics (including this topic of About Reusable Learning Objects (RLO)) have been implemented as RIO's. We have chosen to use XML as the format to store content, with DTD to enforce data structure, and XSL to define presentation format. Some of the advantages of this approach are as follows: RDF is another good alternative. RDF represents data using a directed graph structure, whereas XML represents data using a tree structure. Just as a tree strcture is one possible configuration of a directed graph, XML is one possible syntax of RDF. Design:This learning module contains the following files: When RLO.XML, RLO.XSL and RLO.DTD are placed in the same directory as XLAN.BAT and XLAN.BAT is executed, the final presentation in HTML format is created. Contents.HTML is the table of contents and RLO.HTML is the learning material itself. There is also a subdirectory called Images which contains all of the JPEG files to which the hyperlinks in RLO.HTML point. In RLO.XML, educational content is organized using the following tags: This design approach helps to organize content, so that it may easily be referenced or reused, while still providing curriculum designers the flexibility to organize it as they wish. Material may be reorganized or combined with other material by simply copying and pasting <RIO> sections of text from one XML document to another. The XSL file does all the work of modifying the presentation format. The RLO.XSL file is the design template for the final HTML presentation. As long as the XML file follows the above structure, a single XSL file will work on all XML files, regardless of their content. Thus, there is no hard-coding of content into the XSL file. All references to content are dynamic, not static. This allows users to enforce a common look and feel for all presentation materials, without having to change each individual module. To accomplish this, the following are some of the techniques that were used in the XSL file: XSL is an open standard, which protects our investment, and saves time when formatting large quantities of educational material. |
Summary: |
Creating a Requisition: Requisitions are created by openning the requisition page, specifying the Requestor (i.e. the person who requires the item), Description, Quantity, Unit of Measure, Category (e.g. Computer, Furniture), Price, and Comments. The Requestor determines the department and the Categogry determines the account number. Use + or - to add or delete lines. Save your requisition. Go to the Supporting Documents page if you want to link to a document in Documentum. When you are ready, Submit your requisition for approval. Once it is submitted, you cannot change it unless an approver 'Recycles' it back to you. You may Cancel a requisition at any time, regardless of its approval status. You will be e-mailed when your requisition is approved. If changes are required, an approver will 'Recycle' it back to you. You will be e-mailed and the requisition will appear in your worklist, along with the approver's comments. You must then resubmit the requisition for approval or cancel it. Approving a Requisition:Requisitions are approved by openning your worklist and select an item, reviewing the approval page, clicking on the Requisition hyperlink as needed to jump directly to the requisition, reviewing the Approval History page, and filling in the Approver Comments section. The Approval Action field defaults to 'Approve', so do not save unless you approve. Once you approve, it will be removed from your worklist and routed to the next approver if required. If you select 'Deny' and save, the requisition will be cancelled, the originator will be e-mailed, and no further processing will occur. If you select 'Recycle' and save, the requisition will be sent back to its originator along with an e-mail. The originator will then have to resubmit. If you do not take action, both you and the originator will be e-mailed after 3 days as a reminder. Routing vs. Approval Authority:The term Routing refers to where the requisition goes, whereas Approval Authority refers to the approver's dollar limit. Routing follows the chain of command, whereas Approval Authority is based on each individual's dollar limit, determined by their job code. Requisitions are routed first to the Requestor's supervisor. As she approves it, her approval authority is checked. If insufficient, it is then routed to her supervisor for further approval, and so on, until somebody with sufficient authority approves it. High dollar requisitions (e.g. $100,000) are also routed to the Chief Accounting Officer for approval. Approval Authority is checked each time somebody approves a requisition. The approver's employee ID is used to determine their job code, and therefore the approval role to which they belong. There are 9 approval levels at SeeBeyond, each with its own dollar limit. An approver cannot approve his own requisition, regardless of dollar amount. Approvers should remember that IT Acquisitions must be approved by the VP of IT, Furniture and Fixtures require approval from the Director of Corporate Services, and Donations require the approval of the Chief Accounting Officer. Converting a Requisition into a PO:Once requisitions are approved, they are turned into PO's. Purchasing selects the requisition, runs the PO Calculation process (scheduled), and the PO Creation process (scheduled). This will create a PO, and a hyperlink will allow you to drill down from the PO to the requisition. Role of the Workflow Administrator:The role of the Workflow Administrator is to intervene when requested to resolve routing problems, or to change the configuration of PeopleSoft Workflow. The timing, frequency and wording of timeout notification, monitoring of worklist activity, changing the status or routing of a single worklist item, researching the routing and approval history of a requisition, or the setting of dollar limits for each position, are among the acitivities a Workflow Administrator may undertake, when authorized to do so. (Such requests are to be documented and approved in accordance with SOX, as with all MIS requests.) Workflow Objects:TriggerBusinessEvent() methods are used to initiate a workflow process, telling activities to fire. Activities are the fundamental building blocks of workflow routing, and are used to direct what will happen next. At a minimum, activities consist of Steps, Lightning Bolts and Worklists or E-mails. Steps indicate what page will open when a recipient selects a worklist item. Lightning Bolts are required to link steps to worklists and/or e-mails. Worklist objects indicate the table name for the worklist entries, control the appearance and functionality of the worklist page itself, and define timeout processing options. The Worklist mapping attributes determine the content and destination of the outgoing worklist message, and often utilize dynamic roles in conjunction with role queries and bind variables to route dynamically. Some of the activities used by PeopleSoft Requisitions include S_SUPERVISOR and S_RECYCLE, as well as some delivered activities such as 'Notify Requester' and 'Find Timeout Worklists'. Activities are grouped together in Business Processes. An Approval Rule Set is like a decision tree that is used to determine if a user is authorized to approve a particular item. This should not be confused with routing as Worklist items are not necessarily routed to individuals in this order. Each icon on the approval rule set is called a rule step. Each step definition lists all subsequent steps as 'Equally Authorized', meaning that if a MANAGER is authorized, then so is a DIRECTOR, MANAGING DIRECTOR, VICE PRESIDENT, etc. Each step also contains a sequential 'Step Number'. The 'Path Number' is always 'A' since we do not utilize parallel paths. The 'Rules' tab specifies the dollar limit, and the 'Events' tab specfies which activity to fire when somebody at this step approves, denies or recycles the item. (Here, 'Approval' only applies when the approver is not authorized.) Technical Process Flow:The technical process flow of a requisition involves its initial creation, submission for approval, determining which routing query to run, using data from the Amount Approval page to pass bind variables to the query, running it to obtain a recipient list, and routing a worklist item to each recipient. Also, when an item is approved, PeopleSoft checks the approver's approval authority using the Approval Rule Set, and either updates the requisition status to 'Approved', or fires the routing process again to find the next approver. HR data is maintained up-to-date by a custom Application Engine process which reads the HRMS tables, adds new users, and updates their security roles accordingly. Workflow Setup:Workflow setup requires the Creation of role queries, dynamic roles, Activties for routing and notification purposes, mapping of worklists to roles, creation of Approval Rule Sets (which includes the definition of each approval step), configuration of Purchasing business units to point to the approval rule sets, turning on workflow, and finally, creating processes to update employee data, including members of dynamic roles, security profiles, Requestors and user preferences. Not Implemented:Chartfield-based approval was part of the original prototype, but was not implemented. Amount-based approval defines approval authority based on dollar limits, whereas chartfield-based approval is more general and complex. The term 'chartfield' refers to a financial field, such as 'Account' or 'Department', but chartfield-based approval can include other criteria as well. The exact same steps are followed when setting up chartfield-approval. However, chartfield approval occurs in parallel to amount-based approval (i.e. two sets of worklist notifications occur in parallel). A different approval page is used, worklist items are routed via separate role queries (multiple instead of just one, and more complex), and approval authority is determined using different approval rule sets with different criteria. The prototype worked, but since it applied to so few users, we felt that the added design complexity was not warranted. Comparison with Oracle Workflow:There is very little difference in functionality between the Oracle and PeopleSoft Workflow solutions. Given the degree of overlap, Oracle may keep its existing solution rather than rewrite PeopleSoft Workflow in Java. Oracle Workflow has a very similar look and feel to PeopleSoft, both having browser access, graphical development tools, e-mail and worklist notification, highly configurable, allowing loops and branches in the process flow, time-out escalation, audit trails, support for XML and LDAP, message servers for high-volume message queuing, integration with other messaging solutions such as IBM MQSeries and TIBCO Rendezvous, workflow trigger code built into the various ERP, CRM and HRMS applications, supporting both synchronous and asynchronous messaging, 'Activities' to control the routing of worklist items, content-based routing and error handling, workflow processes triggered by inbound messages, outbound messages, events that trigger other events, delegation of approval using from-to dates, role-based notification, and Workflow Administrator intervention. Oracle contains a separate development environment for its workflow, whereas PeopleSoft handles all objects within a single development environment. Also, Oracle uses XML documents to trigger activity branching, whereas PeopleSoft uses its own proprietary tools. Oracle Workflow Monitor is implemented as a Java applet, whereas PeopleSoft implements it on the server-side. Oracle delivers the ability for users to differentiate which items are delegated and which items sit in their worklist, whereas this would have to be customized in PeopleSoft. The most significant benefit to SeeBeyond may be the switch to a common Java / XML standard. About Reusable Learning Objects (RLO):This learning module is compliant with CanCore standards regarding Learning Object Metadata (LOM). CanCore is a set of best practices for interpreting and implementing IEEE LOM standards. A Reusable Learning Object (RLO) is an entity that may be reused for educational purposes. RLO's (or lessons) are made up of smaller objects called Reusable Information Objects (RIO's, or topics). These RIO's may be reassembled to provide customized learning content. e.g.: This document uses XML as metadata format, with DTD to enforce data structure, and XSL to define presentation format. Advantages include international standardization, strength in describing educational metadata, separation of content from presentation format, machine readability, enforcement of structure, and human readability of XML. RDF is another strong alternative. The IEEE standard defines a conceptual data schema for learning metadata, although it does not define how a learning technology system will represent metadata. The purpose is to facilitate interoperability by providing a common taxonomy. Cancore provides guidance in interpreting and implementing these standards. The metadata associated with this document is contained within a <Metadata> tag in the RLO.XML file. |
Quiz: |
End User Training: Questions: Answers: Questions: Answers: |
Metadata: |
General:
Last Modified:
Title:
Language:
Description:
Aggregation Level: Key Words: Meta Meta Data:
Meta Meta Data Identifier: Contributor Role: Contributor Entity:
Contribution Date:
Meta Data Language: Technical:
Technical: Educational:
Learning Resource Type: Intended End User Role: Intended End User Role: Educational Context: Typical Age Range: Rights:
Rights Cost: Copyright And Other Restrictions: Rights Description: Relation:
Kind of Relation: Relation Resource: Classification:
Classification Purpose: Taxon Path source: Taxon: |
