[Building Sakai] Reaction: Sakai course on CD

[Mike Ozornin]

On Tue, Jun 9, 2009 at 10:33 PM, Philip Fedchin <philip at smolny.org> wrote:

> Mark,


Hello, Philip.

You mention that 'SCORM "could" be used to delivery encrypted tests - could
> you give any insights on what is the way for achieving the task?
> And another concern I mentioned is related to the necessity to download
> full course content from CD in order to do the search/use the content. Do
> you consider this as a problem at all?


I was  always sure, that flash technology (Air, etc) is strong enough to
have some Crypto functions etc.
Maybe it's possible to change Quizes export to export them cryptes with some
symmetric-key algorithms.
I'm talking about flash just because it's more native to web systems that
Java + SWT.


> With best wishes,
> Philip
>
> ----- "Mark Norton" <markjnorton at earthlink.net> wrote:
>
> > First off, lumping SCORM and IMS-CP (I assume you mean IMS Content
> > Packaging) together does them a disservice, since SCORM is based on
> > IMS-CP.  CP is an envelop specification.  As such, it DELIBERATELY
> > doesn't place any  restrictions or requirements on what goes into it.
> >
> > So saying that CP is flawed because it won't encrypt tests kinda
> > misses
> > the point.
> >
> > SCORM (sharable content object resource model) provides a way to
> > define
> > reusable learning objects and includes ways to deliver content that
> > includes sequencing, navigation, tracking, communications (that
> > includes
> > grade capture), and bookmarking (btw).  While SCORM "could" be used to
> >
> > delivery encrypted tests, in practice, most don't bother.  Why?
> > Because
> > learning objects are focused on learning.  Assessment, like tests, and
> >
> > high stakes tests, like finals and qualification exams require a more
> >
> > secure environment (as you have pointed out).  So the fact that SCORM
> >
> > doesn't encrypt tests isn't a flaw, it was a design decision.  That
> > may
> > make it unsuitable for your needs, but it doesn't make it any less
> > useful.
> >
> > As for SQLite, while it may be the most widely deployed SQL database
> > solution in the world, it uses a C/C++ interface.  Sakai is largely
> > based on Java (there are a few exceptions).  As such, Java developers
> >
> > tend to prefer Java database solutions, like MySQL or Oracle.  Adding
> >
> > encryption to an existing Java database solution (even a generic,
> > cross
> > platform solution) wouldn't be difficult to develop.  Finally, SQList
> >
> > doesn't include encryption out of the box.  A separate organization
> > provides SQLiteCrypt, that does.
> >
> > All that aside, there is a need for good security in delivering tests.
> >
> > Most of Sakai assessment applications, including Samigo and Melete,
> > rely
> > on the fact that tests are delivered via the web.  The content
> > available
> > to students at the time of the test DOESN'T include answers.  It would
> >
> > require direct access to the server and finding the particular XML
> > files
> > in question to find answers to a question.  This is further
> > complicated
> > by random question selection at delivery time.  So, used as designed,
> >
> > Sakai can deliver secure assessment.
> >
> > It therefore seems to me that your problems arise BECAUSE you want to
> >
> > deliver it on a CD.  It's no surprise that moving to an older delivery
> >
> > technology would re-introduce old security issues.
> >
> > - Mark Norton
> >
> > Philip Fedchin wrote:
> > > Dear Collegues!
> > >
> > > We do appreciate your help and constructive suggestions! And sorry
> > for the delay in reaction. I would like to outline our position (and
> > reaction to expressed suggestions) in one message. Once again, I will
> > be really thankful for any additional
> > criticisms/clarification/comments etc. Sorry, if I missed any of your
> > arguments.
> > >
> > > 1) Yes, we did consider Solo initially as a possible option. But the
> > problems with Solo, it seems, that offline search and test
> > functionality would not be possible to realize?
> > > 2) Concerning using SCORM (and IMS) packages as the background
> > format for this offline instrument there are the following obstacles:
> > > - SCORM and IMS packages are zip archives as opposed to the solution
> > we envision where data is stored in SQLite database;
> > > as a result of using these zip files the search functionality will
> > be limited (all the data needs to be downloaded to active memory) - it
> > means the resources needed are rather large and it will be a rather
> > serious burden for end-user workstation;
> > > - Am I right to suggest that both SCORM and IMS do not have any
> > serious support of content encoding? On the opposite in the SQLite
> > there is AES password encrypting support and so even if you download
> > the database on other workstation, you would not be able to decipher
> > the data. This is essential if we want students to run tests offline
> > and then to synchronize the results. My understanding is that in SCORM
> > package case the student will be able simply to open the folder and
> > find the correct answers ;
> > > - Another functionality missing in case of SCORM/IMS would be
> > bookmarking of the course content.
> > >
> > > With best wishes,
> > > Philip
> > >
> > >
> > > Interesting idea, John, but there are some pretty serious
> > restrictions
> > > in IMS-CC.  There is no sequencing defined in the spec, for example.
> >
> > > Melete modules would need special treatment, though SCORM is
> > supported
> > > as a data type in CC.  Glossary should be simple enough - burn it
> > as
> > > HTMLpages.  CC has no support for Search.  Also tests would have to
> > be
> > > in the restricted form of QTI supported by CC.
> > >
> > > Zach and I worked on getting IMS-CC import to work in Sakai some
> > time
> > > ago.  The spec definition changed out from under us (in part because
> > IMS
> > > took waaay too long to validate the spec and make it "public".  Zach
> > and
> > > I both moved on to other (paying) projects, so there is some code,
> > but
> > > it's broken.  It's a good place to start from, however.
> > >
> > > - Mark Norton
> > >
> > > John Norman wrote:
> > >
> > >> In addition to other comments, this sounds like a slightly unusual
> >
> > >> (from Sakai perspective), but very reasonable scenario for IMS
> > Course
> > >> Cartridge support. If you could find or create a lightweight
> > >> distributable IMS Course Cartridge player and distribute/develop
> > that,
> > >> then Sakai will be wanting to support Course Cartridge export (if
> > we
> > >> don't already) as part of its archiving strategy. The reason I
> > mention
> > >> this specification is that the scenario you outline seems very
> > similar
> > >> to the Publisher use-cases that informed the development of the
> > spec,
> > >> and distributing materials on CD that include content and
> > assessment
> > >> is very similar to some of the online active textbook projects that
> >
> > >> publishers are developing and distributing using the spec.
> > >>
> > >> A key issue might be around expectations of communication back from
> >
> > >> the system running the CD, about the activities and scores of the
> >
> > >> student.
> > >>
> > >> John
> > >>
> > >> PS there are commercial Course Cartridge players.
> > >>
> > >>
> > >
> > >
> > >> On 5 Jun 2009, at 11:31, Philip Fedchin wrote:
> > >>
> > >>
> > >>
> > >>> Dear Collegues!
> > >>>
> > >>> We have a rather urgent need at our university to create
> > CD-versions
> > >>> of our Sakai courses.
> > >>> In relation to this need we are considering a development of
> > >>> specific tool on the basis of OCW. We would be really grateful for
> >
> > >>> your comments/suggestions/expressed interest to participate.
> > >>> Although we are very much looking forward to Sakai 3, but the task
> >
> > >>> is much more urgent and we are forced to base the process on
> > current
> > >>> Sakai 2.5.4 version with the addition of couple Contrib tools. May
> >
> > >>> be you have some ideas concerning more productive way of realizing
> >
> > >>> our short term goals in terms of Sakai future.
> > >>>
> > >>> So, we have in mind the following list of tools/functions
> > available
> > >>> from the disk/local workstation:
> > >>> 1) modules content (Melete and Resources, perhaps Conditional
> > >>> Release);
> > >>> 2) tests (Test&Quizzes);
> > >>> 3) glossary (glossary);
> > >>> 4) search (new tool for the search on CD).
> > >>>
> > >>> The preliminary plan is to develop the tool on the basis of OCW.
> > The
> > >>> tool would consist of server and client parts. The server part
> > would
> > >>> be fullfilled by Sakai through the creation of standard course
> > site
> > >>> with modules created using Resources, Melete, Test&Quizzes. The
> > >>> client part is a player (interface), which allows to present on
> > the
> > >>> CD the course downloaded from Sakai.
> > >>> And we plan to use Adobe Air (Flex) as the technology behind the
> >
> > >>> client part.
> > >>>
> > >>> The standard scenario is the following:
> > >>> 1) Professor creates a course in Sakai using Melete, Resources,
> > >>> Test&Quizzes and Glossary
> > >>> 2) Using the tool the course materials files are downloaded
> > together
> > >>> with the XML file reflecting the structure.
> > >>> 3) The files are copied to CD
> > >>> 4) The course is played from CD using Adobe Air based player.
> > >>> There will be an opportunity if needed to create client interface
> >
> > >>> using SWT (The Standard Widget Toolkit) as we are planning to
> > >>> document and make available the code.
> > >>>
> > >>> Looking forward to your reaction.
> > >>> Best,
> > >>> Philip Fedchin
> > >>> Associate Director for Information Resources
> > >>> Smolny College of Liberal Arts and Sciences
> > >>> (St.Petersburg State University & Bard College)
> > >>>
> > >
> > >
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to
> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
> "unsubscribe"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20090609/54c163eb/attachment.html