[Deploying Sakai] [Using Sakai] Requesting Help In Copying Courses from One Semester to Another (without breaking links)

Diego del Blanco Orobitg diego.delblanco at samoo.es
Tue Jan 10 04:22:52 PST 2012

Hi everyone:


A variant to the Andrew’s 1st option that we have used in one of our
customers is to create that repository course but enroll the students with a
modified role without the site.visit permission but with content.view
permission. So you don’t need to have the contents public, because only
enrolled users will have access to the contents. And they don’t notice that
they are enrolled in that site.


The problem (depending of the flexibility of your SIS more or less complex)
here is to enroll the users in both sites, the normal site and the
repository site. 


Diego del Blanco Orobitg

Director de operaciones

diego.delblanco at samoo.es

Tlf Oficina: 673 80 32 69

Tlf Móvil: 653 683 489





De: sakai-user-bounces at collab.sakaiproject.org
[mailto:sakai-user-bounces at collab.sakaiproject.org] En nombre de Beith,
Enviado el: lunes, 09 de enero de 2012 23:41
Para: sakai-user at collab.sakaiproject.org; production at collab.sakaiproject.org
Asunto: Re: [Using Sakai] [Deploying Sakai] Requesting Help In Copying
Courses from One Semester to Another (without breaking links)


Hi everyone,

I did send a response to Andy but thought I’d also share our solution with
everyone else as well. 


Our initial migration process was to copy all Blackboard content into each
faculty member’s My Workspace Resources site (except of course tests and
quizzes which had to be reformatted using Respondus). We then walked the
faculty through making each course content folder publicly viewable (moving
out anything they did not want students to see). So a typical faculty My
Workspace Resources folder looks like this:


Description: cid:image001.png at 01CCCC6B.EF034E40


Currently we have an SIS integration with our Datatel administrative system
that automatically creates our course shells, connects the instructor
accounts (which are external AD accounts) and updates the rosters on a
nightly basis.  For the initial course development we walked faculty through
the process of copying their URLs to their course content stored in My
Workspace Resources that they had made publicly viewable and then pasting
the links to the folders as web links in their new Fall course Resources
folder. Now when they do an Import from Site into their Spring courses, they
are rolling over just the links to their content that is stored in My
Workspace, which are absolute links. This way they don’t duplicate the
content from semester to semester taking up unnecessary server space and
also don’t have any problems with links. This also accounts for the
occasional removal of old courses from the server (which we haven’t figured
out a schedule for yet!) so that they don’t mistakenly lose their original
content stored in an old course. So a typical Fall or Spring course
Resources folder would look like this:


Description: cid:image002.png at 01CCCC6C.5ECF25F0


This conceptually is a sound practice however here are a couple of
challenges that we have had with it:

·         Faculty have a difficult time understanding the difference between
putting things in My Workspace Resources and then linking back to them from
their course Resources

·         Faculty forget that they have “linked” to a folder in My Workspace
Resources and when they want to add to a folder or remove documents in their
course they can’t find the original source location

One issue we’ve run into with the way we are creating courses is that we
can’t take advantage of the Section option which would be attractive to many
of our lab/lecture type of courses where the preference would be to populate
a parent course and then link to the content from the child sections. 


Another issue is because we’ve integrated the course shell, instructor and
student roster we’ve hampered the ability of our faculty to combine rosters
or to add non-registered students (for example those making up an Incomplete
from a prior semester). When faculty try to combine multiple sections of the
same course into a single course shell, or those who are team-teaching or
cross-listing courses want to combine their students into a single location,
all the students are moved back each night when the update runs. As you can
imagine this is very frustrating. Since we haven’t had the opportunity to
change our SIS integration process yet, what we’ve done as a workaround is
create a separate Student role that contains all the same permissions and
access but is named MStudent (for manually created student). So when faculty
combine rosters they have to go in and change the role for all the blended
students to MStudent in order to keep them in the course while providing
full access to all the tools. It’s time consuming initially but it lets them
do what they want for the duration of the semester since the update process
only recognizes and verifies against the Student role.


We were thinking of the course creation model that University of Rhode
Island is using that connects the rosters only to the faculty accounts but
then relies on the faculty member to go in each semester and create each of
their course shells, attaching the rosters according to their preferences
during the creation process. Our only concern is that this is expecting a
lot of our faculty who up until now expect that we will do all of this for
them J


Providence College is planning on doing a modified approach where they
automatically create the courses each semester and attach the faculty
members. However they will not integrate the rosters into the shells. The
faculty who want to use Sakai will have to go in at the beginning of the
semester and attach their own rosters. This way the rosters will still be
updated daily and will only be available to the specific faculty, but there
is no automated connection to the actual course shell so they can mix and
match rosters at will. I don't believe they’ve put this in place yet but I
know that this is the plan. If they can pull this off, we’ll probably adopt
that process since it seems to be the most flexible while still automating
most of it.


Sorry for the long-winded answer. Hope this helps. 




From: production-bounces at collab.sakaiproject.org
[mailto:production-bounces at collab.sakaiproject.org] On Behalf Of Valenti,
Andrew P.
Sent: Friday, January 06, 2012 2:30 PM
To: sakai-user at collab.sakaiproject.org; production at collab.sakaiproject.org
Subject: [Deploying Sakai] Requesting Help In Copying Courses from One
Semester to Another (without breaking links)


Hi Sakai Colleagues!


Happy New Year!


I am writing to solicit ideas, suggestions, and solutions to problems that
occur when links to tools & content in one course site are created using the
Import from Site tool to bring content into a new course site. 


The Problem

In the Tufts instance of rSmart Sakai CLE 2.7 (which we call Trunk), we do
not use Sakai Course Management.  A new course is created each semester,
automatically triggered by the appropriate SIS information; under our course
management process, course shells are not reused from semester to semester.
In some schools, it is a common practice that instructors create a syllabus
using an HTML page in which they insert links to their course materials
using the FCK editor and these links will be “absolute” meaning they point
to the resources contained in the original course site.  The first time the
course is created there’s no problem as the instructor/site owner has
permission to access them.   Let’s suppose that in a subsequent semester a
new instance of the course is created and the instructor decides to populate
it  using the Import from Site tool.  If the instructor selects the check
box for importing Resources (along with whatever else is needed), the tool
will bring in the syllabus and the course materials.  If no further action
is taken to modify the links that are in the copied syllabus, the following
will happen.


To the instructor clicking on a link in the copied syllabus, the instructor
is able to access the content and everything appears to be working.  To a
student, confronted by an HTTP access error message, the links appear
“broken”;  what has happened?  The “absolute” link in the copied syllabus
points to the course material in the instructor’s original course site for
which the student does not have permission to access.  Thus, the instructor
can see it but not the student.  Interestingly, the course material copied
from the original site is “orphaned” with no links pointing to it.  Emerging
from discussions with our internal support team and our Sakai vendor,
rSmart, were three alternatives:


Option 1 – Use a non-production site as a Sakai “content repository”


a.       Create a root site that serves as a content repository and make the
content “public”.

b.      In the original course design, ensure that the syllabus uses links
pointing to the desired content in the repository site

c.       When the course is copied over, the links in the syllabus will work
because they correctly point to content that has been made public. Since no
actual course material has been copied to the new course site, there is no
“orphaned” content.



*	Instructors don’t have to be aware of “relative” vs. “absolute”
*	Maintains single copy of course materials in a repository



*	Requires thinking though an “information architecture” design for
content stored in Sakai in order to oversee and maintain protection of
copyrighted information
*	Difficult to prevent multiple repository sites from proliferating
which adds to content management woes

·         Ultimately, we’d like content to be stored in a repository outside
of Sakai which will allow us to provide more sophisticated content
management services such as, access control, capacity planning, and more
sophisticated search capabilities


Option 2 – Copy content/fix addressing


a.	Change the FCK editor so that the instructor creates “relative”
links to course material when initially creating the syllabus.
b.	When the course is copied using the Import from Site tool, the
relative links correctly point to the course material copied into the new



*	Material is kept in course sites which simplifies the management of
copyrighted information
*	Doesn’t require instructors to be too aware of “relative” vs.
“absolute” address and doesn’t require them to set up a non-production
repository site.



*	Changing a pervasive tool such as the FCK editor can have unintended
consequences which even thorough testing may not surface.  It also creates a
fork in the application code tree that we’d have to maintain.
*	Course material is duplicated from site to site, gradually consuming
file storage
*	Moving to an external content repository will be require scooping up
information from individual sites 


Option 3 – Use Duplicate Site tool 



*	The tool maintains the proper link addressing and might be the
simplest solution.



*	In our current design, the duplicates sites would not be
automatically populated from our feed.  We’d have to undertake a manual
process to populate them with the roster.
*	Currently instructors don’t have access to this tool. We’d need to
think through this workflow.
*	Continues the duplication of course material.




Why we need your help

Each solution has advantages and disadvantages which might be balanced
differently based on an institution’s LMS strategy and course management
process.  Since the course duplication seems like it would be a fairly
common process across the higher education Sakai community, we’d like to
know what approach your institution has taken to populate new instances of a
course and how you’ve overcome the aforementioned problems.  If there are
additional options that we’ve not identified, we’d certainly like to hear
about them!


Thanks in advance for the time you’ve taken to help a fellow peer







Andy Valenti, MSc., PMP

LMS Project Manager

Educational & Scholarly Technology Services 

University Information Technology (UIT)

Tufts University

108 Bromfield Road

Somerville, MA 02144


Tel 617.627.3814

Email andrew.valenti at tufts.edu



No se encontraron virus en este mensaje.
Comprobado por AVG - www.avg.com
Versión: 10.0.1416 / Base de datos de virus: 2109/4132 - Fecha de
publicación: 01/09/12

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/production/attachments/20120110/a2b4a683/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 42709 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/production/attachments/20120110/a2b4a683/attachment-0002.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 35639 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/production/attachments/20120110/a2b4a683/attachment-0003.png 

More information about the production mailing list