Dr. Tom’s Guide to a simple path to Meta-Data implementation
Purpose of DocumentTo describe a simple path to start using the IMS meta-data specification. Ways to break implementation down into manageable parts are discussed.
Your enterprise has decided to implement the IMS meta-data specifications. You've just been informed you will be responsible. You don't know XML. You don't know what information must be cataloged. You don't know who will eventually do the cataloging. You don't know how your enterprise will use your meta-data. What you know is that you are expected to present a plan of action to your enterprise, and the deadline is approaching. You need a simple plan to implement the IMS meta-data specification, and you need it now.
Sound familiar? We've been working with a team that is developing the Learning to Teach with Technology Studio (http://www.ltts.org/). The LTTS is a FIPSE (Funding for Improvement in Secondary Education) supported project at the Center for Research on Learning and Technology at Indiana University. The LTTS helps in-service and pre-service teachers learn to integrate technology into the classrooms. A significant effort is the development of short learning modules to teach the teachers, as for-credit online instruction will be available. The teachers will create learning modules that will be available through the LTTS. The learning resources, both for teachers and for learners, will have IMS meta-data. Resources are limited. In the process of assisting with the meta-data implementation process, we demonstrated that an implementation can be simplified to a series of easily-handled steps. At this point LTTS is in the planning stages on its meta-data implementation. Gary Neely is responsible for the technical aspects of implementation, and has co-authored this guide with me.
We'd like to show you the details of how we approached the problem.
The main concepts we'll illustrate are:
Your first goal is to break your problem down into smaller tasks. This "divide and conquer" method allows you to solve the problem one step at a time. Small tasks are more easily completed and no one is overwhelmed by the challenge. Small steps also allow you to delegate portions of the problem should you have the resources available.
Don't be alarmed if you don't get your solution right the first time. You probably won't. Plan on it. The meta-data will evolve, and you must decide how you will support legacy meta-data records you have already created. As a general rule, don't change things too fast. Live with what you have for as long as you can and let practical applications determine your needs. System administrators will love you for this. Start small: it's much easier to increase the number of the meta-data fields, but much more difficult to reduce the number of fields. If you reduce the number of fields, what do you do with the fields in the existing records? That information may need to be captured in other fields.
Remember to write things down. Write down definitions. Write down scenarios. Write down ideas for what needs to be meta-tagged. Keep notes of conversations and keep records of interesting related web sites. Consider setting up an internal web site or other information forum so that your team can look at your documents as they are developed. This can be a great source of ideas in addition to records of your work.
So start as soon as you can!
breaking things down into major tasks. The major tasks identified for this project are:
Each of these tasks really addresses one or more questions.data base problem refers to which fields should be in your data base. How do you structure your data base?
Data base fields that map to record fields.
To state it simply, LTTS decided to use the IMS Meta-Data specification as a basis for the fields to be stored in its data base. The definitions for the fields provided by the IMS Meta-Data specification are being used. The development of solid definitions is a potentially contentious process. IMS has gone through this process carefully with representation from many domains and countries, so the definitions are considered useful widely. Stick with them. Usefulness is the fundamental purpose of the meta-data. It is the key to all of the IMS specifications.
The IMS Meta-Data specification provides a lot of fields. You probably don't need them all. You may need to capture some information that doesn't seem to be contained in the IMS fields. How do you select the right fields to use?
The technical people want to keep it pretty simple, the users imagine all sorts of future scenarios. Different constituencies within this project have different needs. The LTTS project is large, and includes major organizations beyond the academic institution, some of which have commercial interests. The community naturally divides according to the kinds of scenarios they envision. We discovered this and used it. Again, divide and conquer.
Your team can operate in two modes. In a "small group" mode the team is divided into several small groups. Each group is focused on a particular task. In the "big group" mode the entire team meets to determine the small group tasks and review the results of the small groups' work. Small groups can move quickly; they can also wander off track.
The users are divided into groups to select the fields they feel are important. Small groups can come to conclusions rapidly. You can have the users self-select the group they will join, or they can be assigned. The objective is to have each small group focus on a narrow part of the complete selection from one particular orientation. People no longer will feel that they have to address the whole selection problem; they need only deal with a small area. This is an ideal approach. In reality, because getting a system started had a much higher priority that getting it right, a preliminary set of meta-data was selected by the core team members. This emphasis on "getting started" is the right one, in Dr. Tom's experience. More about that later.
However you select meta-data, use scenarios. A scenario is a description of some real or anticipated course of actions. Get the scenario written down! A scenario does not have to span everything, but may be some small fragment. For example, what happens when a student decides to take a course? How does the student now that he or she is elligible? That the right prequisites have been fulfilled? How does the student register for a course? How does a student know what sort of payment may be required? You are addressing only the process of signing up for a course in this scenario. What meta-data is needed for each step? When all of the groups are through, pool (combine) the selected fields. Review all of the scenarios: often listening to another group's scenarios will trigger revision of your own.
Invariably, some needed fields appear to be missing. Take a three-pronged approach here: 1) inspect the definitions of the needed fields and try to compare them with the definitions of existing IMS fields; 2) investigate using the classification category, and 3) extend the IMS meta-data.
Gene Alloway of the University of Michigan advised us to take a definition-centered approach, and it has worked remarkably well. Write down the definition for each field you feel you need. Start with each IMS field that appears to be of use to you; adopt that definition without revision. You may want to add your own explanatory commentary. Add the definitions of additional fields you feel you need.
Often a careful inspection of the definitions of the existing IMS meta-data fields will reveal that the name chosen for a field does not match up with what the group might select, but that an IMS definition is quite close. This is not really surprising, as the IMS meta-data, which are derived directly from the IEEE Learning Technology Standards Committee Learning Object Meta-Data, were developed by a large number of people, so some may have needs similar to yours. Ignore the name of the field. It is only a token to access the field. The token name was often selected by an international committee, and was chosen to have the least confusion on that scale. Adopt an IMS Meta-Data field whenever possible.
A great deal can be accomplished using the Classification category. I urge you look at the guide to classifications: drtomclassification.html
You still may find that you would like fields that cannot be accommodated with the IMS meta-data specification. You can extend the IMS meta-data. However, as you are just starting your system up, put these extensions at a low priority, if at all possible. Leave them until later if at all possible. Actual practice always changes your thinking on what you need, so leave out as much as you can. Really! As Eliot Christian of the U.S. Geological Survey and spark plug of the Government Information Locator Service (GILS) project is fond of saying, "Any meta-data is infinitely better than none". You don't need a lot to have something useful. It is possible to extend the IMS meta-data. Wait.populate the fields selected?
How do you get the data for the meta-data fields? If you think of entering all of the meta-data in one shot, it can be daunting. This raises the question of who will enter the meta-data. How do you find or train adequate catalogers? The key to populating the fields was to look at the work flow in the creation of a learning module.
The LTTS module production process has been broken down into five steps:
quality control process?
A sample Meta-Data entry form
Quality control is a process for ensuring that what you are producing is good. The idea of quality control of meta-data can raise apprehensions. Are we talking about ISO 9000? Quality Circles? Quality Assurance? You can have as much or as little as you like, but have some. Have a plan. Remember, anything is far superior to nothing. Other organizations will value--or de-value--your meta-data based on their experience with its quality. If your meta-data is considered to fairly and accurately characterize your resources, then it will be used. If not, it will not be used. This judgement will be made against your entire repository of meta-data. Any quality control will put you a large distance ahead of most other efforts. A quality control effort will also let you assess how well your development process is under control.
There are several strategies that you can adopt for meta-data review. You can break it down into logical subgroups and have people evaluate appropriate fields. For example, a technical group might simply test to ensure that the resource will operate within the specified environment and determine the straight running time of the resource, if applicable. Again, divide and conquer.creating the meta-data XML record? Someone's going to have to know some XML: who?
searching of the structured meta-data?
XML Editor for data transfer
Searching structured data can require rather elegant search systems: not something you want to undertake when getting started. It would be convenient to have a small number of flat fields that can be quickly searched. That's a good way to do things: it has been suggested by several vendors. Don't open up the entire set of meta-data for searching. Instead, select a small number of fields and map them directly into a flat data base. Store the XML record of the entire meta-data in a file. When someone searches the small set of fields and requests the meta-data, you just blindly ship out the entire XML record file. Obviously you will have to accommodate edits of the meta-data. If edits are always done on the complete record, and then flat fields are regenerated from the record, synchronization should be manageable.
It's too a big jump to start up the entire meta-data generation system in one step. How can you start up a system in reasonable steps?
You have a lot of pieces: now where do you begin? One of the first things to do is to create a simple system for capturing meta-data. It makes little difference what that meta-data are at the start. I know, that sounds like heresy, but anything is so much better than nothing. You need to work the bugs out of the meta-data collection process first. So don't present your people with two problems: What does this field mean? and How do I enter it? Select a small number of trial fields as a starting point. It's easier to add than delete.
No step in the staged development is rocket science. At the end of the first stage, you are actively developing a library of meta-data XML records. These are in the XML format that conform to the IMS specifications for the exchange of meta-data. This is the format in which you will receive new meta-data records that you will add to your data base. These records are in the format that the various departments of your enterprise will exchange meta-data. This library is a resource that your data-base developers can use during development. The library brings you into the world of meta-data. You are accumulating meta-data records for later use. If you choose to accomplish only stage 1, you have done a good job in your implementation of the IMS meta-data specification.
Creating the data base and developing search tools can proceed with less pressure because you are already collecting meta-data. Your data base experts know far more about this than Dr. Tom--we've just tried to give them resources and time to work. The selection of fields versus buckets can be decided without affecting the meta-data collection.
At the end of the staged development you don't have a complete and wonderful system. You can expect to run into problems when you scale this up. You will find that you need to alter your selection of meta-data fields. You can manage these changes in a reasonable manner, as you have a system up and running. You are storing your meta-data records in the IMS XML binding, so you can import them into newer and better systems.
Many of the terms in this guide are defined in the Glossary.
Thomas D. Wason, Ph.D. (a.k.a. Dr. Tom)