Ontwerp en implementatie in SCORM en METS

Ontwerp en implementatie in SCORM en METS Groep 5 Maarten Decat

Thomas De l’Arbre

1e Master Ingenieurswetenschappen: Computerwetenschappen Optie Gedistribueerde systemen

3e Bachelor Informatica Minor Verbreding

[email protected] Benjamin Slegers

[email protected] Wouter Theetaert

1e Master Ingenieurswetenschappen: Computerwetenschappen Optie Gedistribueerde systemen

1e Master Ingenieurswetenschappen: Computerwetenschappen Optie Gedistribueerde systemen

[email protected]

[email protected] this is an important advantage. After all, Flex presents a developer with difficulties when using old Flash animations, not to mention embedding other technologies. For instance, using Flex with JavaScript requires a special API [2].

ABSTRACT After having worked three weeks with Flex, the topic of the course changed to SCORM and METS. We experimented a couple of hours with both languages and the tools that are used to manage them.

•

In this paper, we’ll first give a short overview of our experiences with SCORM and METS, their advantages and disadvantages, their applications, … We don’t forget the editors we used: eXe and Reload. Both of them are discussed in section 2.

SCORM’s disadvantages:

The last section treats the implementation in SCORM and METS: we’ll take a look at what we did in both environments, and what difficulties we encountered.

•

While developing a RIA, the biggest disadvantage of SCORM is the impossibility of creating content. SCORM is only useful when the content is already created. This is in big contrast with Flex, that permits to create attractive applications and even succeeds in adding a lot of functionality.

•

The connection between the functionality SCORM adds, and the JavaScript code needed to realize it, isn't clear at first sight. This can be an advantage, but only when the application performs flawless. If there's a failure, finding the problem can be very difficult. Of course, this last proposition is applicable to Flex as well, but the connection between the code and the functionality is more obvious.

1. SCORM A D METS When evaluating SCORM from the developer’s point of view, it doesn't look bad. It does improve the interoperability, the accessibility and the reusability of web based educational material [1]. SCORM certainly is convenient when it comes to combine different parts of educational applications, and defining the relations between the parts. It works well, even if these applications are made with different technologies that doesn't have to do with each other. However, while brainstorming and creating the storyboard, we departed from the idea of a RIA that looks pretty. In that point of view, SCORM isn't a useful platform to develop that design. SCORM doesn't offer the functionality to develop the content of a RIA. Moreover, the functionality that SCORM offers generally isn't useful in a RIA, and especially in the team's design. In the RIA we designed, the goal was a logical sequence of actions, special relations aren't necessary at all. SCORM’s advantages: •

The most important advantage is the openness of the platform to different content creating technologies. Development of a SCORM project can use different kinds of content, e.g. HTML pages, possibly enriched with JavaScript, Flash animations, wiki pages, movies, etc. In comparison with Flex,

When the relations in an application are more complex than 'proceed from this part to the next', SCORM is a useful platform to establish these relations. In that case, Flex needs extensive conditions, while SCORM is created to deal with these relations.

Conclusion: using SCORM for educational purposes can be very useful, but when it comes to creating attractive RIA's, SCORM isn't comparable to Flex. During the last session, we got introduced to METS (Metadata Encoding & Transmission Standard), a standard for encoding metadata within a digital library. For instance, it is used in several museums all over the world to digitalise their collections. Next to storing the data itself, METS also hands some tools to view the resources. METS Viewers can be used to generate HTML documents that show the resources, like images or movies, in a browser together with their respective descriptions and some meta-data. METS uses XML, a schema language of the World Wide Web consortium. The use of this language makes it possible to archive resources in a structured manner. This is a very important property of XML, since it must be possible to process large amounts of data. After having worked some time with METS, we

got convinced that it is a powerful tool to do the things it was developed for: it is a flexible technology which can be adapted to the precise problem at hand. But in a wider sense, METS is a limited tool: we couldn't think about any other application of it except those that were mentioned during the session. We used a Java-class to generate the METS XML-code. Because we students are quite familiar with Java, this was a great advantage: we didn't have to know anything about the specific XML tags used in METS to generate a working METS file. On the other hand, the miss of a Graphical User Interface could be a barrier for those who never programmed before. People like that could prefer SCORM above METS, because of the 'What You See Is What You Get'-acting. It is difficult to relate METS to Flex, because we're convinced that both applications are developed for totally different reasons. Flex is a polyvalent tool which allows users to generate dynamically font-ends for RIA's easily. METS, on the other hand, is commonly used to archive large amounts of data in a structured way. One can compare these applications by saying that XML is used in both of them. It allows the user to work intuitive: one can obtain nice results without the need to read boring manuals.

2. EXE A D RELOAD This section is dedicated to the applications eXe and Reload, which can be used to construct SCORM packages with some predefined elements and applied prerequisites. Both programs are evaluated and their advantages are given, as well are their disadvantages. At last, these applications are compared to Flex. The eXe application is built to assist teachers and academics in the publishing of web content without the need to become proficient in HTML or XML mark-up. It is certainly not a SCORM exclusive editor as it is possible to export the built content in many different kinds of files. In this project, it was used to built some basic learning content about Flex and exporting it to a working SCORM package which can be viewed in the SCORM player and can be altered in Reload. Reload is a tool used for editing eLearning resources. Editing the SCORM packages afterwards was necessary because eXe doesn't support adding some prerequisites to the interactive parts of the package. For example, in SCORM it is possible to make a page inaccessible before the user passed a test with a certain percentage. This option gives a lot of neat possibilities but to use it, one must built the SCORM pages in eXe and add the correct prerequisites to them in Reload. A SCORM package does not solely contain educational information in the raw sense of the word, but also makes it possible to show this information the way you want to and test the reader afterwards. Fox example, it is possible to integrate a YouTube movie, a Wikipedia page and some self written text into the same page. To make sure the information is fully understood, one can add a SCORM test after this page which the user needs to pass to enter the next page. This way, the information is studied better and faster. How these tests can be used to make the whole application more interactive, is explained later on. The big advantage of eXe is the collection of so-called iDevices which are given in advance and are ready to use instantly. Some examples of these iDevices are the prementioned SCORM test and Wikipedia page, some plain HTML which can contain Flash files or images, and so on. eXe grants you the possibility to add these

iDevices to your page with a simple click of the mouse and lets you edit them in a what-you-see-is-what-you-get manner. In eXe you have the possibility to change the sequence of the different iDevices, even after you created and finished them. This worked fine and made it a lot easier to get the result the way you want it. On the contrary, with a SCORM-test you cannot change the sequence of the questions and possible answers afterwards. So a lot is editable, but not all. The same goes for the pages: you cannot change the sequence in eXe, but you can do it in Reload afterwards. The list of iDevices is quite extensive though some essential components seem to be missing to fully rebuild the music application. For example, a calendar on which all upcoming band performances can be seen. The only option in eXe to do this was the use of free text, which would make the whole a lot less spectacular. An advantage of Reload is that you can oblige the user to look at the different pages in a fixed order and make some pages accessible at the right time using the prerequisites. In Reload, it wasn't always clear how to use these prerequisites or which one we should use. That's why, for us, they did not work like we would have liked them to. We even stumbled upon a 'bug': A page that has been looked at (for example: a SCORM-test) but which hasn't been changed, still counts as completed, and cannot be revisited. So if you did not finish a SCORM-test positively (or did not finish it at all), you cannot see some of the other pages, as they may require passing that SCORM-test. After noticing this, the user cannot visit the test again because this page is listed as completed. Thus, the user cannot finish the test anymore and at the same time, he or she cannot visit the pages relying on this test. Reload has some other disadvantages as well; it is impossible to implement functions, for example a function that directs you to another page once you clicked a certain button. Another disadvantage from which both eXe and Reload suffer, is that there is insufficient documentation available, either delivered with the tools themselves or on the web. This makes it even harder to fully understand all the different possibilities of these two tools. You just don't know what they are capable of. eXe and Reload apparently have a lot of disadvantages and little advantages. But all the preceding has been written while looking from one point of view: "Can we build a decent music application with these tools?". And for this, the tools do not lend themselves. The applications for which these tools could come in handy are situated in the domain of online tests, examinations or inquiries. Also educational resources that have to be seen in a certain fixed sequence can be modelled with these tools. When comparing eXe and Reload to Flex, we must note that eXe, Reload and SCORM do not lend themselves directly for creating a music application, like we mentioned before. That's why it would be unfair to make a direct comparison between them and Flex. The latter gives the programmer a lot more freedom and possibilities in putting in his own creativity. Moreover you can define your own functions, what made that we preferred Flex to eXe and Reload for creating our own music application.

3. RESULT 3.1 Implementation in SCORM Because SCORM wasn't the most useful tool for creating a RIA, a new assignment was arranged. The goal was to create an application for educational purposes, explaining Flex and our

application. The content, mostly HTML pages, was created with EXE. The most important relation between the different pages was the sequential order, which can fixed with EXE. However, some pages require more complex prerequisites, and therefore Reload was used. The idea can be clarified with the graph which is attached to this paper. The sequential order of the pages: •

Page 1: A welcome page greets the user and explains the use of the application. After opening page 1, page 2 can be accessed.

•

Page 2 contains a SCORM test with some simple questions about Flex and Flash. If one passes this test (with a score of 70% or higher), the user is allowed to go to the explanation of the advanced applications of Flex. Failing means one have to deal with the basics of Flex on page 3.

•

On page 3, the user learns the basics of Flex and FlexBuilder. Now can page 4 be accessed without additional prerequisites.

•

Page 4 contains a second SCORM test on the Flex basics. Passing this test (with a score of 100%) means that access to the advanced pages, starting from page 5, is allowed.

•

Page 5 gives advanced information about Flex, mostly about additional API's that can be used to widen the functionality of Flex. Accessing page 6 is possible without prerequisites.

•

Page 6 contains some specific information about the CoverFlow effect, including the used libraries. This is explained in detail because the CoverFlow effect was an important aspect of our Flex application.

•

Page 7, the last page of the design, contains a demo of the Flex application and an explanation about this demo. Page 7 can only be accessed after reading pages 5 and 6.

During the implementation, two big difficulties came up. One of them is the bug, described in section 2. It is impossible to revisit a certain page, so it's impossible to retake a certain SCORM test. After failing a SCORM test, the user is stuck in a kind of deadlock situation and he's forced to reload all the pages. Another difficulty was using two pages as prerequisites for one page. We didn't succeed to join two prerequisites from different pages in Reload. So in reality it isn't possible to access the advanced part, without passing the two SCORM tests.

3.2 Implementation in METS In this section, some more information is given about the implementation of the METS project. The assignment focussed on implementing a small METS application with still images. A correct and working example of such an application was given, which definitely helped in understanding the principles of METS and, more importantly, how to apply these principles in an application. The implementation went a lot smoother than the SCORM implementation because of several reasons which are described below. The first and probably most important reason was the given info about the assignment. This information contained clear instructions about what to do and how to do this. Because of these instructions, there were almost no difficulties with the applied technologies, like the Tomcat server or the METS viewer. This

way, more time could be spent on using METS itself instead of just trying to run the tools. This is the exact opposite of the implementation of the SCORM project. When working with SCORM, more hours where spilled on trying to run eXe and Reload on Windows or Linux than could be spent at experimenting with SCORM. The given bash scripts in the METS assignment also were a gift from the heavens, just because they did everything they had to do in the first place. It's no trouble to put these scripts in the assignment, but they did make the difference between frustration or captivation with METS. The second reason is the use of known languages to program in. The Java API, which could be used to form a valid XML document, worked better than editing the XML document itself. Off course it is an overhead to make objects for each node in the XML tree and adding them explicitly to their parents instead of just typing this directly in XML. But it definitely helps to use a known language to get the big picture. It's a shame the given Java example did not contain some more extensive examples about the possibilities of METS. Each page in the example application looked the same and did not yet contain any images although the code for this was in the Java file. It would speed up the process if some more and more different resources were added to the example. This way, the link between in the code and the result would be easier to get. In the case of our own application, we only managed to alter some text and add a few still images from the internet. Although this was exactly the plan, it would have been nice to be able to add some other media like a Flash file or a movie file from the hard disk. Also, the XML structure used in METS (for example the references to resources defined in the first part of the file) did not become clear when trying to change the Java file to our needs. Instead of knowing what we were doing, it became a process of trial and error, of changing something in the code and looking for what had changed in the result. This remark could also be solved by giving a more extensive example file with more inline documentation and structure. The third reason for a smooth implementation is the goal itself. While the goal with SCORM was to build an application similar to the music application built in Flex, a more realistic goal was given here. METS is good for storing and viewing large amounts of resources like still images or movies, and this is exactly what was asked for. The precise goal of the project was left open. Some sample images of a scanned book could be used to build an application similar to the real life applications that use METS, but other content could be used to. What was made in the project was inferior to the process of making it and no precise idea about what to make was stated. At the end, we had a working METS file with some pictures shown together with their description and metadata. All of this was structured into a couple of pages, as was the given example. We can conclude that the implementation of the project in METS went well. The main reasons for this were better practical information and a more realistic view about the project in the first place. Also the possibility to write the code in Java made it a lot easier to start experimenting with METS.

4. CO CLUSIO We can conclude that both SCORM and METS are very decent technologies in their domain. But we could not get the point of

applying them on the music application or comparing them to Flex. Both SCORM and METS are situated in the domain of recourse sharing and storing. SCORM focuses more on the aspect of sharing knowledge and adding the possibilities to educate this knowledge. METS on the other hand is a more flexible technology to store large amounts of resources in a structured way. These kind of technologies definitely have their uses but they are also very abstract, maybe to abstract to get to know in three weeks. SCORM and METS are both used when dealing with problems of very large scale. Using them involves thinking about the precise problem and determining the most efficient strategy to process and share the available data. In this course, both technologies were introduced in a time span of three weeks. This is way too short to fully comprehend their use, especially for students who are not at all familiar with the problem of sharing large amounts of data. SCORM was introduced as an alternative to Flex and the assignment was to build the music application all over again but in a different environment. At the end, the goal of the project was to compare SCORM and METS to Flex. At this point in time, we believe that Flex is not comparable to these two technologies in any way except for the use of XML. Flex makes it possible to construct RIA's with a very decent frontend. In the simplest case, these RIA's could be used to show data from the server side in a very graphical way or construct some input forms that send data back to the server. More advanced Flex applications are applications in the raw sense of the word. This made Flex very appropriate to build an interactive internet application with, like our mentioned music application. SCORM and METS on the other hand, are not used for this kind of applications at all and it was very hard to imagine how we could use them the same way as Flex. Although they are state of the art technologies, we weren’t able to fit them into the project after Flex.

5. REFERE CES [1] http://nl.wikipedia.org/wiki/Sharable_Content_Object_Refer ence_Model

[2] http://livedocs.adobe.com/flex/3/html/help.html?content=aja

Maarten

10u

3u

Thomas

10u

3u

Benjamin

7u

8.5u

Wouter

10u

2.5u

B. ISMIR PAPER Titel van de paper: 5 approaches to collection tags for music. Samenvatting Het artikel vergelijkt vijf manieren om toepasselijke tags voor liedjes te verzamelen. Deze technieken worden vergeleken op het vlak van scaleerbaarheid en kwaliteit. De scaleerbaarheid hangt vooral af van de financiële kost, de menselijke inspanning en het gebruik van computers. De kwaliteit hangt dan weer af van hoe goed bepaalde problemen behandeld worden. Een paar belangrijke problemen zijn bijvoorbeeld: •

Het 'cold start problem': over liedjes waar nog nauwelijks annotaties aan hangen (bvb. nieuwe of onbekende liedjes), kan maar moeilijk informatie gevonden worden.

•

Het probleem van de 'popularity bias', wat ook een beetje samenhangt met het cold start problem. Over het algemeen worden aan populaire liedjes veel meer en betere annotaties gekoppeld dan aan minder populaire liedjes. Als er dan gezocht wordt m.b.v. annotaties kan het zijn dat een populair liedje beter scoort dan een minder bekend liedje, dat beter bij de annotaties past.

•

Zwakke labels. Bij sterke labels wordt een tag expliciet aan een liedje gekoppeld als de tag relevant is, en expliciet niet aan het liedje gekoppeld als het een irrelevante tag is. Bij zwakke labeling kan het zijn dat een tag die niet vernoemd is bij een liedje toch niet irrelevant is voor het liedje.

Een ander criterium waar de kwaliteit van de methodes van afhangt is de grootte, de structuur en de uitbreidbaarheid van het vocabularium (bvb. muziekgenres) waaruit de tags komen. Het artikel beschrijft vijf methodes om tags te verzamelen. •

Een professioneel onderzoek: hiermee wordt bedoeld dat liedjes beluisterd worden door professionele mensen, met een toepasselijke vorming, die de juiste tags op de juiste liedjes hangen. Het grote voordeel van deze manier van werken is dat er vanuit kan gegaan worden dat het sterke labels zijn, en dat de annotaties die deze professionals geven van hoge kwaliteit zijn. Ook van het cold start problem heeft deze methode niet al te veel last. Het grote nadeel is natuurlijk de grote hoeveelheid tijd die er door professionals ingestoken moet worden, wat de scaleerbaarheid sterk beknot.

•

Onderzoek van sociale tags: hiermee bedoelt men het onderzoek van tags die door een grote gemeenschap gegeven zijn (bvb. zoals bij Last.fm). Het grote voordeel van deze manier is dat de collectieve kennis van een hele gemeenschap gebruikers kan gebruikt worden. Bovendien kunnen met deze methode ook tags toegevoegd worden die met een sociale context te maken hebben, en niet alleen met de muzikale. Op het gebied van kwaliteit scoort deze techniek veel slechter. Het cold start problem en de popularity bias hebben een grote invloed op de tags die op deze manier verzameld zijn. Bovendien is er ook sprake van zwakke labels, en is de manier

xbridge_1.html

APPE DIX A. TIJDSBESTEDI G Tijdens de onderdelen ‘Scorm’ en ‘Mets’ diende er niet buiten de sessies te worden gewerkt, behalve aan het verslag. Iedereen was op alle sessies aanwezig, behalve Benjamin, die de laatste sessie miste (op voorhand afgesproken met professor Duval). Hij compenseerde dit door buiten de sessies meer aan het verslag te werken dan de andere teamleden. Bij het werken tijdens de sessie heeft iedereen evenveel tijd gespendeerd. Voor sessie 1 werd 3u gerekend (na de inleiding over Scorm), voor sessie 2 ongeveer 4u (quasi de volledige sessie, uitgenomen een korte opdracht-uitleg in het begin) en voor sessie 3 een drietal uur (de lezing over METS werd niet als tijdsbesteding meegerekend). aam

Binnen sessie

Buiten sessie

waarop de verschillende gebruikers helemaal niet eenduidig of standvastig. •

•

•

Een spelletje om tags te verzamelen. Ook hier kan er weer gebruik gemaakt worden van de collectieve kennis van een hele gemeenschap. Bovendien kan er m.b.v. bepaalde spelelementen (bv. een soort van beloning voor een goede annotatie) voor gezorgd worden dat de annotaties die verzameld worden van hoge kwaliteit zijn. Er zijn natuurlijk ook nadelen verbonden aan het gebruik van een spelletje. Wat vooral zeer moeilijk is, is het maken van een spannend spelletje dat ook goede annotaties levert. Onderzoek van webdocumenten: hiermee wordt bedoeld dat de vele websites over liedjes doorzocht worden. Het grootste voordeel van deze methode is dat er heel veel materiaal voorhanden is, dat zonder directe menselijke inmenging onderzocht kan worden. In sommige gevallen kan op deze manier ook weer voor tags binnen een meer sociale context gezorgd worden. Een belangrijk nadeel is dat de methode van 'text-mining' die gebruikt wordt, resultaten kan geven die onbetrouwbaar zijn (afhankelijk van de betrouwbaarheid van de gebruikte website). Bovendien zijn er nog de problemen van popularity bias en zwakke labels, waar deze techniek geen antwoord op biedt. Autotags: deze methode houdt in dat er op basis van alleen de muziek automatisch tags aan het liedje toegekend worden. Dit biedt heel wat voordelen: er is geen directe nood aan menselijke inspanning. Bovendien wordt deze manier van werken helemaal niet beïnvloed door het cold start problem en is er sprake van sterke labels. Aan de andere kant is deze techniek zeer intensief qua computergebruik en gelimiteerd door de manier waarop de muziek digitaal geïnterpreteerd wordt. Een ander nadeel is het feit dat alleen de muzikale inhoud gebruikt wordt om tags te voorzien, en bvb. de sociale context helemaal geen invloed heeft.

De belangrijkste conclusie van het artikel is dat vooral een hybride gebruik van meerdere technieken, het beste alle vijf, tot de beste resultaten leidt. Interessant? Het artikel trok direct de aandacht, omdat muziektags iets zijn waar iedereen dagelijks mee in contact komt. Dikwijls in een vorm waarbij de tags veel meer misleidend dan handig zijn. Zo kan bijvoorbeeld een liedje van Tom Waits door de ene als klassieke rock beschreven worden, terwijl de andere het eerder folk noemt en een derde misschien gitaarmuziek. Het gebeurt zeer zelden dat de tags van een liedje precies de trefwoorden geven die je nodig hebt. Het was daarom zeker interessant om te weten hoe ver het onderzoek gevorderd is om dit te verbeteren. Een tweede punt is de hoeveelheid van gegevens waar deze technieken op steunen. Aan de ene kant is het aanbod van gegevens en beschrijvingen over liedjes immers bijna onuitputtelijk, dus informatie vinden zal nooit een probleem zijn. Aan de andere kant is de aangereikte informatie zo ongestructureerd en dikwijls onbruikbaar, dat het op het eerste zicht een onmogelijke taak lijkt om van deze gegevens gebruik te maken. uttig? In onze Flex-applicatie wordt er veel aandacht besteed aan de zoekfunctie. Het is vanzelfsprekend dat het gebruik van de juiste tags bij de juiste groepen, de zoekfunctie nog heel wat kan verbeteren. Het verschil tussen ons gebruik van tags en dat van de paper, is dat in de paper een enkel liedje als entiteit gebruikt wordt, terwijl er in ons project vooral vanuit het concept artiest gewerkt wordt. Voor de rest zijn de ideeën uit de paper heel bruikbaar. Het is natuurlijk wel een grote vraag of deze technologieën ook op een eenvoudige manier concreet ingebouwd kunnen worden in het project.