Talk:Module 5-b: Application software
From DL Curriculum Project
Instructions
1. Click an 'edit' link to type in your comments. Your evaluation may cover general issues concerning the module or a section of it, or you may make more fine-grained comments (e.g., on a particular section by referring to the section number or on a particular point by referring to the page and line number).
2. Add four '~' (without quotations) at the end of each comment. Your id, date and time will show up later.
3. Click the 'Save page' button on the bottom of the 'edit' page.
Module Objectives: Are the objectives appropriate for the topic?
Are the objectives observable? Will students be able to achieve the objectives, given the content in the body of knowledge?
Is it an important objective for the students to be able to describe the details of the features and technologies for these software applications? Allenb 17:14, 30 December 2007 (EST)
I am unclear on the "target" student for the curriculum. I see two distinct groups of students -- the student who is likely to work in systems and be a "techie", and the student who will likely be interfacing with systems people but will be not be building the systems but be a "teammate." The second type of student would be interested in the curriculm so they can work successfully on DL development teams in their libraries in terms of understanding technological limitations and vocabulary during DL development and content development for the DL.
Assesing the objectives from that perspective: for the techie: I think the objectives are observable and on-target. for the teammate: I think that the objectives, particularly c, are beyond what could be achieved.
Objectives a and b seem very weak to me--'describe the features and technologies' sounds as though the students will simply copy out a list of features, for example. And what do you mean by 'technologies' here? The programming languages and tools used to develop the DL software? Is being able to do this useful? Cunninghams 21:18, 12 January 2008 (EST)
I agree with the above comments that the objectives are a little weak. Students need to understand the needs for the DL software applications and what needs are supported by those applications and what are missing. The current objectives seem to help students understand existing several important DL applications. I think the course should support students understand needs and importance of DL applications and make them lead the development of the future DL applications.
Also, the listed DL applications are good examples, but there will be other new applications coming up later. I think the curriculum should broaden the view of DL applications by letting them find other new DL applications. Kohe
Body of Knowledge: Does the module address all areas of the topic that need to be addressed?
Will the body of knowledge enable students to achieve the objectives? Are there any topics that you think are critical to add to the body of knowledge? Are there any topics on that you would remove from the body of knowledge?
1) The module does not seem to encourage the students to develop a broad conceptual framework for dealing with this material. If I were teaching this material I would want to frequently refer to the concept of services -- perhaps this could best be done building on the notion of a "service oriented architecture". Allenb 17:06, 30 December 2007 (EST)
2) For each of the software packages ("topics") discussed in the "Body of Knowledge" Section, I believe that the material in the Overview (e.g., development history) should be de-emphasized.Allenb 16:37, 30 December 2007 (EST)
3) The module does not seem to encourage critical thinking. For instance, there is no discussion of the weaknesses of the software tools or critical comparison between them. Allenb 16:37, 30 December 2007 (EST)
4) The "Application Software" selected for presentation here seems pretty restricted. Shouldn't digital library application software include: XML development environments (e.g., XMLspy), metatata development environments, and search tools (e.g., Google CSE). Even more broadly, I believe that digital library software should include summarization, translation, education, and collaboration environments. Allenb 16:37, 30 December 2007 (EST)
5) For each Topic, it would be helpful to point to a deployed DL that uses the software. This would also allow for discussion of how these systems "play" with commercial library automated systems since libraries may want to integrate DL collections.
6) The application software environment is very dynamic, curriculum should include provding students with a skillset to know how to keep abreast of developments including applications beyond those covered in the curriculum. This could be an additional topic in the body of knowledge.
In summary, after students understand all the listed DL applications, they could compare the different needs of different applications. Also, they could find similar other applications not listed in the Body of Knowledge. I think there should be more open-ended and active lists in the body of knowledge. After five years, there will be more new compelling DL applications. I think the curriculum should cover the future applications by letting students to research about existing DL applications or so. Kohe
Readings: Are the readings the best and most appropriate for the topic?
Are there any readings that you think are critical to add to the list? Are there any readings on the list that you would remove?
There are lots of papers on the web comparing aspectts of different digital library software packagages. For instance, http://www.ariadne.ac.uk/issue45/boock/ http://www.dlib.org/dlib/september05/witten/09witten.html Allenb 17:06, 30 December 2007 (EST)
Most of these readings are from developers of the software. This is excellent for learning about the software but is unlikely to provide students with a critical review. Being able to assess and discuss appropriateness of a specific application software would be a component of meeting objective a (describe the features adn technologies). Including a reading such as the one noted above by Bob would address this.
The idea of a critical review really needs to be added to this module: a framework for allowing the student to semi-formally evaluate a new DL package, in comparison/contrast to other DL software.
Learning Activities: Are the activities appropriate for the topic?
Will students be able to accomplish the activities, given the content in the body of knowledge? Will the activities enable students to achieve the objectives? Can you think of any other class activities appropriate for this module?
I don't understand what instructions the students willbe given about building Concept Maps or how they are to evaluated. Allenb 17:14, 30 December 2007 (EST)
1. A critical evaluation activity would be useful. Students could be assigned to a particular application software and then assess the software features etc., and possibly review deployed DLs using the software.
2. Concept mapping is very powerful but it is unclear how that addresses the goals of this module.
3. Group presentations can be very powerful but if I were teaching this module I would layout very specific guidelines in terms of what to address and how much time should be used. A strategy I have found successful is to have students write a short "white paper" about their topic and to make that available to all students. It serves as a resource and also captures greater detail than can be presented. (I review them for accuracy before posting to the class)
4. Each student provides a glossary word and definition based on their participation in the group presentation. The instructor could then review and choose to include appropriate words in the class glossary.
Talks like this can too easily deteriorate into a laundry list of features pulled off a website. If each group only looks at one DL, it will be difficult for them to critically evaluate the software (that is, they won't be able to look at the DL in comparison to other software)--unless the teacher provides a good checklist to evaluate the DL against.
Concept Maps are useful to the learner, but are highly idiosyncratic--and that seems to be a strength. I also don't understand how to evaluate a CM. At the university level, I would expect the students to use their CMs to create a more conventional representation of their understanding (an essay, presentation, or even a Powerpoint 'read document'). Cunninghams 21:34, 12 January 2008 (EST)
I think the learning activities could be more open-ended. This module is limited to the listed four software, but it can be made to find and compare the DL applications (including the listed ones).
Kohe
Level of Effort and Prerequisites: Is it feasible to teach the module as it is currently constructed?
Is the level of effort required in class appropriate to the scope of the body of knowledge? Is the level of effort required prior to class appropriate? Is the prerequisite knowledge required sufficient for students to comprehend the body of knowledge?
It's difficult to see how this module fits together with everything else. For instance, knowledge of Z39.50 seems to be expected, but I'm not sure where that will happen. The brief description in the Glossary doesn't seem sufficient. Allenb 17:24, 30 December 2007 (EST)
This module is teachable. Relying on student presentations for the majority of the content does present a significant effort to assure that content is adequately covered for each topic.
It's ok, but I also have reservations about relying on student presentations for the material. At this point, the students won't be able to draw any useful comparisons between the different systems, or between different DL paradigms.
Overall Structure of the Module: Is the current module well structured?
Can the topics and their corresponding resources be easily divided? Is there a clear mapping between the objectives and the content of the body of knowledge section? If not, how could the objectives be mapped to the body of knowledge more clearly? [accidentally deleted this: Allenb 17:31, 30 December 2007 (EST) ]
Additional Comments
I'm not sure where this fits, so I'll include it here. I'd drop the mention of CORBA in the Glossary. It is now an outdated standard. Allenb 17:31, 30 December 2007 (EST)
I've got a grab bag of minor comments about the module:
19: search, BROWSE, and add items. How about deleting items from the DL? modifying metadata?
p. 2: 10: 5 - 7 hours seems excessive for just being able to 'describe' something. Presumably this description would in most cases just be copied from existing papers or presentations on the web?
14: and .5 - 1 hour seems too little to actually become familiar with how to search, add items, etc--it would be a minimal pass through most of the software, not enough to really retain it. sive.
p. 3: 15: this 'overview' is a brief history of who developed EPrints, but says nothing about what it does, how it differs from other software in this category, ...
24: the 'Features' listed seem to be a bit of a grab bag. Are these the features that distinguish EPrints from other DL or repository software? The features most important to users? To administrators? Why are these features here, but not others?
34: These benefits are, as acknowledged, largely copied from the EPrints site. Why include them here--why not just have the link to the benefits? These benefits don't include enough explanation to make this text directly useful in a lecture or as a student reading.
p4 and p 5 include the 'Content types' for EPrints and DSpace. Both have Text listed (of course), but Dspace (line 36) also has a listing of types of text documents. Why not make these consistent?
p. 6: If using GSDL as an acronym, spell out what it means at some point
The sorts of ideas listed under 'Features' differs wildly across the systems.
P. 7, line 4: 'Security issues' doesn't mean anything on its own--what about security? what issues?
Why not include sources of information for all the application software (eg, Greenstone)?
Cunninghams 21:46, 12 January 2008 (EST)
