Dear all,
Here are my notes on today's meeting.
1. The relationship between the hands-on training in a computer lab
and the seminar components of the course still need work. Tom Horton
raised a good question of what was even meant by "lab". Here are
some of the alternatives we discussed:
1.1 The hands-on be taught separately as a "boot-camp" or non-credit
course that runs in parallel to the KR course.
1.2 The hands-on be part of the KR course. There be a 2 hour seminar
and a 2 hour lab each week. The lab would provide training in
technologies that then raise issues for discussion in the seminar.
The problem of synchronizing these activities and who would teach the
labs is dealt with below.
1.3 There be self-directed tutorials that students can do in
conjunction with the KR course. Students could pick and choose the
ones that they need.
2. If we go with 1.2 then we need to think about the issue of the
relationship between the hands-on training and the seminar. One idea
was that the labs take place before the seminar and be designed to
lead students to productive failures which would provoke stepping
back, reading around the subject, and discussing it in a seminar.
Rune pointed out that it is hard to map such productive labs onto a
weekly seminar. It is more likely that labs would proceed
independently for a few weeks before they reached points of
intersection with the seminar.
The point was also made that we need to protect the seminar from
becoming an extension of the training. We need to guard against
technical training creeping into the seminar to the exclusion of the
critical.
If we go with 1.2 we also have the problem of who teaches the
training labs. If there is the expectation that people other than the
instructor would come in then we need to ask how that would be
facilitated. Here are some of the ways outside instructors could be
brought in:
2.1 A grant could be sought to pay for the development of tutorial
materials. Each tutorial module would be developed with support by
the local expert. These tutorials would then give the instructor
something to fall back on if the local expert cannot participate in
person. Thus Horton and Ramsay might develop a Ruby tutorial which
someone else could use in the labs. One time funding would pay to
free Horton and Ramsay to develop this.
2.2 Funds could be sought to compensate the local experts every year
to teach the modules. The instructor of the course would have funds
with which to negotiate with departments and units to free up the
time of other instructors.
2.3 Other units could be asked to donate the lab instruction to the
program. For example the Media Centre might run their Flash course
for the KR course as part of their service to the university.
3. Concerns were raised about the intellectual focus of the course.
As mentioned above, the course should not be just a sequence of
training modules with some academic debriefing after each lab. I
would recommend that in the next semester a straw curriculum be put
together from the readings and discussions we have had that would
outline the intellectual trajectory of the course. This would change the
"how to" to "why". Each of the participants could work with Steve and
Andrea to flesh out the topics they led.
4. We discussed Johanna's idea that a colloquium be organized in
parallel to the program that brings in speakers to enrich the
community. John thought a grant to endow such a colloquium might be
possible.
5. Jerry's issue of understanding non-digital systems of knowledge
was discussed. I think most of us felt this program should
incorporate a constant back and forth between the digital and other
systems of knowledge. This could take place in various ways:
5.1 Each topic should be an occasion to revisit how digital systems
are different and similar to other systems.
5.2 Students might be encouraged to take the bibliography course as
their humanities elective.
5.3 The colloquium should include presentations that raise this issue.
5.4 The design course should look not just at digital projects but
also at other projects as examples of knowledge representation.
Ideally this program would make strange the student's understanding of
print, libraries, design and philosophy.
6. Programming continues to an elusive topic to treat adequately.
Some of the points that came out are:
6.1 To treat programming in the depth needed for the software
engineering course is not trivial. As it stands the SE course is
designed not to teach programming. It assumes a level of programming
knowledge on which to build. We need to work with Tom Horton to
identify a minimal knowledge of programming which is needed for the
SE course and then identify ways for students to get that knowledge.
6.2 One of the places the students can be prepared for the SE course
is in the KR course. How many weeks of 2-hour labs on programming
would be needed to cover the knowledge we expect our students to have?
6.3 One suggestion was that in the KR course the students learn
scripting - programming suitable for CGI programs that work with
databases or XML files. If this is the goal for the KR course they
will still be programming content that needs to be acquired before
the SE course. A summer non-credit course was suggested to bridge the
introduction that takes place in KR and the needs of SE.
Self-directed materials could also be made available to students who
feel able to learn on their own.
We never got to digitization ... but I snuck a plug in for
digitization as the fundamental issue of digital humanities.
Everything else, including programming, is just a sauce on the
bread of digitization. :-)
Yours,
Geoffrey Rockwell
--
This archive was generated by hypermail 2b30 : Wed Dec 12 2001 - 18:24:09 EST