Forum .LRN Q&A: Re: LRN Application Status Discussion - File Storage

Collapse
17: Re: LRN Application Status Discussion - File Storage (response to 16)
Posted by Malte Sussdorff on 12/01/04 12:51 PM
I think the content creation as it was mentioned by Michael should not be part of File Storage. Either you can create content using e.g. the Reload Editor and stuff the result into LORS, which should keep track of the relative linking.

Alternatively it might be nice for LORS to be able to import a ZIP file of HTML content, relatively linked, and generate the SCORM package that is generated out of this, automatically.

A totally different approach would have to be taken if you plan to use this not as course material but e.g. for your personal website. In this case, it might make sense to get ETP (or whatever CMS you fancy) to take the contents of the Zipfile, upload all images into the content repository, store the HTML internally and provide the linking this way.

Last but not least, I think the naming of file storage in 5.1.4 already supports this. If you use relative linking it should not break if you upload a ZIP file. If it does, this is a bug :).

Collapse
19: Re: LRN Application Status Discussion - File Storage (response to 17)
Posted by Ernie Ghiglione on 12/02/04 03:25 AM
<blockquote> Alternatively it might be nice for LORS to be able to import a ZIP file of HTML
content, relatively linked, and generate the SCORM package that is generated
out of this, automatically.
</blockquote>

Although possible, this could be a bit tricky. Say for instance you have the following files in a zip file that you want to share with your students:

[ root folder]
|-> default.html
|-> intro.html
|-> flash_animation.swf
|-> xmlfile.xml
|- [ images folder ]
    |-> randompic1.jpg
    |-> randompic2.jpg

Given this structure, LORS can't really guess or know where the entry points are. We could say, well, maybe the default.html might be the entry point, but again, that's an assumption that we would make.

Now Michael has a very good point here and probably we should clarify the difference between learning objects and plain content.

LORS is good to handle learning objects aggregations (courses) and/or individual learning objects. But if the zip file represented above isn't a learning object neither a course, but a piece of content that I want to share with my students, I shouldn't have to convert it into a learning object by using Reload, creating a content packaging, edit metadata, etc, etc... that'll be rather tedious if I have to do this for each hand out in my class.

Probably an example can ilustrate this better. Say for instance I'm a teacher for a class and on the way to uni on the bus I read this article that relates to the subject I'm teaching today. I might want to add this article as "suggested readings" for the subject. This is not necesarily a learning object as such, but just a random article that might content various pieces that you want to share with your class.

I know -for sure- that File-storage works well linking different pieces of content together using its index.vhu. As a matter of fact LORSm relied on it until recently for all its content delivery -now LORSm has its own.

So summarizing, I think it's good that file-storage still maintains its index.vhu for linking random content that might not necesarily need to be part of a course. It's always good to have that as a choice.

Thanks,

Ernie