| 1 | Requirement as defined by the groups | Questions, Specifications | Priority Priority | Comments | ||
|---|---|---|---|---|---|---|
| 2 | Repository | |||||
| 3 | Functionality: | |||||
| 4 | 1 | import/export functionality. Exchange of content between organizations (UAS masters, small institutes of universities). Standardized gateways. | How does a user interact with the system when content is imported/exported? Scenarios? Sample workflows? | ES:3 / MH:3/ 3/SG:3/ JM:3/ ST:3 / DA:3 ES:3 / MH:3/ 3/SG:3/ JM:3/ ST:3 / DA:3 | CS: Für Dozierende sollte der Aufwand möglichst klein gehalten werden. Import von Content könnte darum über lokales CSPC's koordiniert bzw. übernommen werden (einerseits aus Qualitätsgründen, andererseits zur Entlastung der Dozierenden). Export sollte unter Beachtung von Copyright-Regelungen für alle User möglich sein (Authentifizierung über AAI). // MH: A "service" to help with upload and download should be "offered" on different "levels". Online documentation how to... or if possible a sort of "wizzard" leading through the steps is thinkable. It should be possible to upload or download any kind of files but it should be obvious if it is f.ex. a SCORM-package (*.zip) or *.ppt or *.html or whatever should be defined as possible. //ST: I agree with CS that content upload should be coordinated by local CCSPs according to a national "standard". // DA : if there is an automatic harvesting made every day by the federative repository directly on each LMS. The question is how to configure the upload from each LMS with a standardization of the metadata (fields description). A "search engine like" indexation with ranking is maybe a better and more easy solution, even if the data are hetrogeneous in structure. The other solution is a real-time federated search on each LMS, but then the different structures could be difficult to homogenize on the fly (see federated search interfaces on several databases like METALIB) | |
| 5 | 2 | library systems can provide knowledge about indexing, meta-data | Library systems are complex and can only be managed by professional librarians. This might contradict to requirement "easy to use repository"? | ES:3 / MH: 3/ 1// SG:3/ ST:2 / DA : 3 ES:3 / MH: 3/ 1// SG:3/ ST:2 / DA : 3 | ES: Das Repository stelle ich mir nicht vor als einfache Internetablagefür kurzlebige Arbeitsdokumente, sondern als Pool von möglichst ausgereiften Lernressourcen // MH: A form has to be filled in withobligatory and nonobligatory answers. The author must define the grade of access after publishing. A sort of editing office juges the upload and the filled in "metadata" and finishes for publishing just to guarantee a "minimum-standard" of quality. This standard should bedefined in advance and be published on the site for uploads. (perhaps with a link) SG: Ein Minimum an Metadaten sollten vom Autoren schon eingegeben werden (oder von der stellvertretenden Person, Kompetenzzentrum, die das für ihn tut -> diese Leute könnte man ev. sogar schulen). Danach sollten Profis die Indexierung übernehmen. Das ist immer noch "easy to use" für die Autoren und hoffentlich dann auch "easy to find" für alle. // JM: Know-how on cataloguing can be borrowed from librarians. However, indexing by librarians shouldn't be a requirement, for several reasons, including (very high) costs, time (there are many more learning objects than books, and they have a shorter lifetime !). Things can go much faster if authors index content themselves, with a minimum of meta-data, and there is a good full-text search function. // ST: in the repository (DOOR) we developed at eLab we require just a minimum of meta-data, I find this is a good solution. // DA : instead of a classical library system, it would be preferable to use an OAI-PMH compatible system, adapted to learning objects (softwares : DSPACE or CDSWARE, see CERN, MIT, EPFL, have a look at a harvester of institutional repositories : OAISTER). These systems have proven that they are suitable for individual filling by multiple users. The quality and enrichment of the metadata can be managed by librarians or pedagogical specialists. I agree then with MH. | |
| 6 | 3 | access to existing databases | Examples for existing databases? Merlot, Careo, ...? | ES:2 // MH: 1// 3 // SG:2 // DA : 1 ES:2 // MH: 1// 3 // SG:2 // DA : 1 | CS: Existierende Datenbanken an den CH-Hochschulen, in denen bereits Content enthalten ist, sollten angeschlossen werden bzw. in Suchabfagen integrierbar sein. Auf andere externe Datenbanken (Merlot usw.) kann via Linksammlung hingewiesen werden. // DA : the aim of the platform is to promote the swiss production, not to give access to all the material available in the world. But the data collected in the federative swiis platform could be made accessible to international or major databases, like MERLOT. | |
| 7 | 4 | Support for math. formulas, symbols, notes | MH: 3// SG: 3// ST:3 // DA : 1 MH: 3// SG: 3// ST:3 // DA : 1 | MH: any kind of files or "archives" (*.zip) containing "program files" should be possible. Best exchange format might be "SCORM". "Exotic" file-types must be easy "usable" on "normal" systems with "free" available software or just with a browser and some plugins. | ||
| 8 | 5 | multilingual | ES:3 // MH:2// 3// SG:3 // JM: 2// ST:2 // DA : 3 ES:3 // MH:2// 3// SG:3 // JM: 2// ST:2 // DA : 3 | MH: you cannot await multilingual content. You can put the language on the list of metadata. if the system is english its quite usable. if the system is multilingual it is nice. SG: Das System sollte multilingual sein, dass der Content nicht multilingual ist versteht sich für mich von selbst. Oder seh ich das falsch? // JM: a multilingual interface will increase acceptance by authors. However, this brings additional problems, such as translation of common terms used in meta-data.// ST: the system interface could be in English; if necessary, the instructions to use it and/or a glossary might be translated in German, French and Italian. // DA :Multilingual content, multilingual interface and screens. | ||
| 9 | 5' | Social taging and enrichment by users | Amazon like features, popularity analyses | DA : 3 | DA : let the users give a constructive feedback, and analyze it automatically. Tags, comments, ratings, but also access counts, list of actual queries made by users, … | |
| 10 | Access, user rights, presentation: | |||||
| 11 | 6 | granular access control rights based on AAI | Who manages access rights? Should access control be sophisticated or simple? Which user roles are to be defined? | 3 // MH:3// SG:3 // JM:3// ST:3 // DA : 1 3 // MH:3// SG:3 // JM:3// ST:3 // DA : 1 | ES: so offen wie möglich! // CS: 1. SWITCH Admin -> Full Control;2.local CSPC -> Control of all contents from his institution;3.Content-Owner -> Control of his content; 4. User ->Search,Download //MH: The author defines who has access for his data,however metadata with access rights should be shown with the search results.Perhaps the finder can "deal" with the author in case of no access. SG: Wenn der Autor definieren kann, wer welche Rechte hat, dann sollte das Rechtesystem relativ einfach sein, sonst ist es für den Autoren nicht mehr einfach zu bedienen. Ich denke, wenn jemand seinen Content in ein solches Repository stellt, dann kann man auch davon ausgehen, dass alle mit Zugriff auf das Rep. den Content sehen können. Man könnte auch noch eine Option "ask for permission" einbauen, also"see" (not read), und "ask for permission to read or download"; dazu "read" und "download". // JM: access rights should be defined by authors, as open as possible being the default recommendation. // DA : no need of AAI, the ressource is on a local LMS, not on the federative platform. I agree with MH : the author defines the access rights. Then the rights shown in the federative platform must be inherited from local LMS and coded as 1. Open to all, 2. Open to members of the author's institution, 3. permission to ask, 4. No access. I don't believe in a 5th option like "access to every swiss student or swiss teacher". | |
| 12 | 7 | multi-client capable ("mandantenfähig") multi-client capable ("mandantenfähig") | Does every institution need it's own virtual repository? Do institutions need more than a customized look-and-feel? Is it acceptable to store all content in a single pool? | 2 // MH:1 2 // MH:1 | ES: mehrere Repositories finde ich eher kontraproduktiv. //CS:Grundsätzlich "single Pool" mit sowohl "stored content" als auch "linked content". Als Option sollte möglich sein, einer Institution einen eigenen passwortgeschützten Bereich einzurichten, um Content-Austausch innerhalb der Institution zu unterstützen. SG: Dem stimme ich zu, ansonsten ist die Aktualisierung und Abgleichung wieder schwieriger zu bewerkstelligen.// ST: I imagine that each institution has its own repository and a national system ("search engine") allows users to search learning material through all repositories. | |
| 13 | 8 | free/anonymous access to content | Some content may not be freely accessible. How to protect copyrighted content? Who decides what content is accessible? At what granularity level (course,module,chapter,resource) access may be granted or denied? | 3 // MH:3// SG:3 // JM:3// ST:3 // DA : 3 3 // MH:3// SG:3 // JM:3// ST:3 // DA : 3 | ES: beide Möglichkeiten bieten: Offen und kostenpflichtig. Die Rechte müssen in beinen Fällen für alle Inhalte des Repository geklärt sein. Alles andere muss hinter Passwort im LMS der Institution bleiben (schon da gibt es unterschiedliche Meinungen, ob legal). // CS: Entscheid über Content-Zugang soll beim Owner liegen. Content sollte möglichst frei zugänglich sein. Nur bei kostenpflichtigem Content oder Content mit speziellen Copyrightbestimmungen sollte eine Anfrage / Freischaltung (evt. automatisierte Request) nötig sein. Alle Levels von Granularität sollten unterstützt werden. // DA : options as written in the protokoll from 17th may (pt 5.3), except the "free for members of swiss univesities" option which smells an old-flavored nationalism. Is Switzerlad in Europe or not ???? ;-) | |
| 14 | 9 | variable/customizable layout/look-and-feel | Who realizes the customization? What skills are required for customization? How much may customization cost in terms of money and time? | ES:1 / // MH:1 // 1// SG:1 // JM: 1// ST:1 // DA : 3 ES:1 / // MH:1 // 1// SG:1 // JM: 1// ST:1 // DA : 3 | MH: layout should just be "national", because it is a "national" platform for exchange. So customisation is not necessary. // DA : why not having the possibility to make an extension for Firefox, giving a search form in a navigator, or to allow to local LMS a direct access to the fedartive platform on thir interface. | |
| 15 | Content management: | |||||
| 16 | 10 | reusability of content and design | Most content is context dependent. How to to achieve reusability of context dependent content? | 3 // MH:3// SG:3 // DA : 1 3 // MH:3// SG:3 // DA : 1 | CS: Kontext über Metadaten möglichst genau erschliessen(Thema,Fachgebiet, Lernziele, Voraussetzungen, Zielgruppe,Kontextbeschreibungusw.). SG: Lernszenario in Metadaten beschreiben. // DA : as said in the protokoll : "the idea of storing only meta information in the central repository". In a second stage (2009 ??) it could be interesting to manage the content also, like the Swiss national library is doing for e-Helvetica (long term storage and access to electronic public and academic swiss documents). | |
| 17 | 11 | reuse entire courses, modules or parts of courses | Specify functionalities: Repository for content? Database for quizzes, flash-cards or questions-and-answers? Streaming content? | 3 // MH:3 // SG:3 // JM:3 3 // MH:3 // SG:3 // JM:3 | CS: Plattform sollte alle Levels der Granularität und Content-Typenunterstützen. Wichtig sind gute Suchfunktionalitäten, damit Suche eingegrenzt werden kann auf bestimmten Content-Typ oder -Level. // MH:Description of Chapters or Modules. Maybe parts of the content are also usable and customizable for the own needs, if allowed by the author. Sure that depends on the file-format. SG: Der Meinung schliesse ich mich an, nicht zwischen Content und Wissensüberprüfung (Quizzes etc.) unterscheiden, sondern eine starke Suchmaschine und eine gute Indexierung dahinter stellen, damit man alles finden kann. // JM: agree with CS. Reusability is one of the main objection to learning objects, small objects might be easier to reuse than complete modules or courses.// ST: agree with CS. | |
| 18 | 12 | compliance with SCORM and other standards | Which standards are required? SCORM 1.x, SCORM 2.x, IMS-CP, IMS-LD, IMS-QTI, IMS-SS, ...? | ES:3 // MH: 3// 2 // SG:3 // JM: 2 // DA : 2 ES:3 // MH: 3// 2 // SG:3 // JM: 2 // DA : 2 | CS: Einhaltung von Standards sollten kein Muss sein, aber es sollte erkennbar sein, ob ein Content einen Standard erfüllt oder nicht. Format-Standards evt. verpflichtend d.h. nur Content, der mit gängiger Software/Editoren (MS Office, Open Office, pdf, flashplayer,HTML-Editoren usw.) übernommen bzw. weiterverarbeitet werden kann. SG: Beim Output (also download) sollten Standards aber unterstützt werden, sonst kann man (vgl. u.) den Content möglicherweise nicht in sein System integrieren (sofern das denn mit den Standards klappt :-) // JM: Export in SCORM/IMS-Content Packaging format (even if content wasn't originally in SCORM format) might be good for reuse. SCORM (mostly used) version, IMS-Content Packaging, IMS-QTI should be supported. // DA : when indexing the content of local LMS in a google like approach, the standards are not very important. But if it is planned to store not only the metadata but the content too, then standards are essential. Has somebody, in any working group, a deep knowledge of the standards already in use in LMS in Switzerland ? Could be interesting to have a review on this. | |
| 19 | 13 | versioning: traceable at any time what was the content of a course in particular semester | versioning on file, module or course level? | MH:3// 1// SG:3// ST:1 // DA : 3 MH:3// 1// SG:3// ST:1 // DA : 3 | MH: versions must be obvious. Maybe if there already exist different versions it can be limited by age (f.ex. not older than 2 years) or maximum number of versions. // DA : two options for the central platform : i) there is one record (metadata) for every version of a learning object, ii) or one record contains the list of versions and links towards the content on the local LMS, in its several versions. The question is then : what is the general policy with versioning on each local LMS : are the previous versions of the same object kept or discarded ? | |
| 20 | 14 | (minimal) national standards (regarding content) | Quality-, technical-, or pedagogical-, graphical-, ... standards? This might contradict to the requirement "customizability" | ES:3 / 3 // MH:3 // DA : 1 ES:3 / 3 // MH:3 // DA : 1 | ES: Schwierig. Qualität des Contents ist kontextabhängig, hängt in der Regel davon ab, wo und wie er eingesetzt wird. // CS: Nur im Unterricht bereits erprobten Content zulassen. Einhaltung von Minimal-Standards halte ich für zwingend. CSPC's sollten minimale Qualität garantieren durch Vorselektion respektive durch Peer-Review. Es sollte eine Qualitätsauszeichnung sein, wenn Content auf diesem Portal angeboten wird.// JM: Who would define "standards" ? Peer-review as well as comments on objects will hopefully foster good content (also CSPCs might be a kind of filter). // DA : If we want the repository to be filled in by the institutions, it has not be the national "miss competition". Who is able to judge the quality, who wants to be part of the jury ? I prefer to to have a social rating system (as written in the protokoll ((4.3)). | |
| 21 | 15 | tech./paed. standardization of learning resources | Tradeoff between standardization and customization. Define mandatory or optional level of standardization? How much individuality is acceptable? | MH:2// JM: 1 MH:2// JM: 1 | ES: ?? // MH: as open as possible but a minimum limit for technical and paed. standard should be defined. f.ex. a simulation or a quiz with individual learning steps must work or the main goals or purpose of a module should be obvious by the metadata. If content is used in the own LMS it should be free for the reuser to customize (question of time,money and work to invest) or not. SG:Metadata // JM: standardization of learning resources is not possible (and it wouldn't be accepted, anyway ;-) // DA : ?? | |
| 22 | Usability: | |||||
| 23 | 16 | easy to use / only little metadata | What is the minimum/maximum of required metadata? Is it possible to agree on a small subset of IMS-Metadata? | 3 // MH:3 // SG: 3 // JM: 3// ST:3 // DA : 3 3 // MH:3 // SG: 3 // JM: 3// ST:3 // DA : 3 | MH: the MUST-data can be a small subset the CAN-data give further informations and might help to find a module or to use it more often. SG: MUST-data soll der Autor ausfüllen, die CAN-data die Indexierfachleute. Die MUST-data können sich auf Titel, Autor, Thema, Fachbereich, Lernziele, Lernszenario, Kontext beschränken. // JM : we should look at the most successful repositories to see what they use as meta-data (most projects that require too much meta-data have failed). // DA : easy to use does'nt mean little metadata. Easy import of metadata into the central repository means clear harvesting protocol, well documented. Easy to use export functionalities is a must, no training needed. Easy to use search form too. (as simple as google is). | |
| 24 | 17 | Solution for legal issues (copyright, licenses) / supports digital rights management | ES:3 / 3 // MH:3// SG:3 // JM:3// ST:3 // DA : 3 ES:3 / 3 // MH:3// SG:3 // JM:3// ST:3 // DA : 3 | ES: Muss durch Lizenztyp definiert werden. Creative Commons wäre gute Basis. // MH: different levels should be possible, which the author can choose before publishing (free,universitities,home-university,home-institution, small community of persons administrated by the author himself. SG: Für Open Content Creativ Commons (die Vernehmlassung der Schweizer Version sollte eigentlich in diesen Tagen erfolgen). Für kostenpflichtigen Content ist jeder Autor oder Institution zuständig selbst ein Pricing Modell zu entwickeln. Möglicherweise gibt es auch einen Vorschlag für ein Pricing Modell auf der Plattform. // JM: Creative Commons for licenses, no complex DRM system. // ST: agree with JM. // DA : creative commons should be promoted among the community. Open access by this way is for me very important : University teachers won't earn money with their learning material. They will earn REPUTATION. And they are paid to teach, so the average citizen won't understand why they could earn more money by selling their courses online. The same questions arise with the scientific open access movement (FNS has signed the Berlin declaration ein february 2007, promoting open access to scientific publications ins Switzerland). | ||
| 25 | 18 | ease of use; must not be time-consuming; little support needed; good usability | How much training is acceptable? How to satisfy power users who need an extensible/adaptable environment? | ES:3 / 3 // MH:3// SG: 3 // JM: 3// ST:3 // DA : 3 ES:3 / 3 // MH:3// SG: 3 // JM: 3// ST:3 // DA : 3 | CS: Zusätzliche Features wie RSS / personalisierte Suche / Speicherung von Suchanfragen / Abonniermöglicheit per eMail / User-Kommentar zum Content. // MH: power users are welcome to use more functionalities by using "further links". Starters use only the "central" or main functions. SG: Am liebsten gar kein Training. RSS fände ich persönlich ein MUST. // JM: RSS-feeds for new/updated content, very good usability (make user tests !). // DA : see 16 | |
| 26 | ||||||
| 27 | Further possible criteria for a repository (to be confirmed by SWITCH-els working groups): | |||||
| 28 | Technical: | |||||
| 29 | 19 | Extensible framework, clean architecture, documented API | ES: 3 // MH:3// SG: 3 // JM: 3 // DA : 3 ES: 3 // MH:3// SG: 3 // JM: 3 // DA : 3 | Well documented APIs might encourage reuse in other contexts/applications (ala Google Maps), e.g. students access a "live" version of the repository directly from a course. | ||
| 30 | 20 | Development of extensions/customizations: High productivity | ES: 3// MH:2// SG:2.5 // DA : 1 ES: 3// MH:2// SG:2.5 // DA : 1 | question of money | ||
| 31 | 21 | Programming development environment | Is there a preference for a programming environment or framework? (Java, .Net, Flash, Ajax, PHP, ...) | ES:1 // MH:2// SG: 2.5 // JM: 2// ST:1 ES:1 // MH:2// SG: 2.5 // JM: 2// ST:1 | MH: might be important for developers. Not too many mixtures // SG:php // JM: php or Java (but with documented API, this shouldn't be too important). // DA : i am not able to say anything else than : Python seems to be a very versatile language well adapted to OSS. | |
| 32 | 22 | Programmers documentation available | ES: 3 // MH:3// SG:3 // JM:3 // DA : 3 ES: 3 // MH:3// SG:3 // JM:3 // DA : 3 | |||
| 33 | 23 | Scalability | ES: 3 // MH:3// SG:3// ST:3 ES: 3 // MH:3// SG:3// ST:3 | |||
| 34 | Usability: | |||||
| 35 | 24 | End users documentation and tutorials are available. | ES: 3 // MH:3// SG:3// ST:3 // DA : 3 ES: 3 // MH:3// SG:3// ST:3 // DA : 3 | SG: Hier ist natürlich die Multilingualität wieder wichtig. // DA : I agree with SG. | ||
| 36 | Community: | |||||
| 37 | 25 | Developers community: large, international community with skilled developers. Long-term continuation of project assured. | ES: 3 // MH:2// SG:3 ES: 3 // MH:2// SG:3 | MH: Important but difficult to judge how the developers community is working. Who is the "customer" of the developers. Who defines the orders for functionalities, who controls or claims disfunctionality?That should only be a small team of persons working on inputs by the users community. Who are "contract-partners"? SG:Möglichkeit neue Features incl. use-cases zu posten, die dann in der Community diskutiert werden. | ||
| 38 | 26 | Users community: actively communicating with developers and mutually supporting other users. | ES:3 // MH:2// SG:2// ST:2 ES:3 // MH:2// SG:2// ST:2 | ES: Es muss definiert werden, wer die Weiterentwicklung koordiniert(«Konsortium»). // MH: The behaviour of a users group is not easy to influence.SG:Es fragt sich, ob die User überhaupt Bedarf dazu haben. Möglichkeit bieten ist aber sicher gut. Aber vermutlich reicht den meisten Usern eine gute Dokumentation, um sich im System zurecht zu finden, der Rest (wie Community oder Entwickler) wird aber den meisten "Standard"-Usern egal sein. | ||
| 39 | 27 | Approach/product has been used with success at other comparable institutions. | ES:3 // MH:2 // JM:2// ST:2 ES:3 // MH:2 // JM:2// ST:2 | |||
| 40 | Services: | |||||
| 41 | 28 | Services (development, training, integration, ...) are available from peers or a commercial partner | ES:3 // MH:2// SG:2 ES:3 // MH:2// SG:2 | |||
| 42 | ||||||
| 43 | Integration | integration of major LMS with related tools: video conferencing, synchronous/asynchrornous collaboration, instant messaging, web-logs, calendar, repositories | The type and level of integration would need to be further specified. What is the purpose of an integration, and how far should it go? Can you give some examples or scenarios of integrations? | ES:1 // MH:1 // JM: 3// ST:3 ES:1 // MH:1 // JM: 3// ST:3 | MH: easy to use from the same place without new login. Instant messaging for occasional use while being present on the platform might be aspects but not important. // JM: integration of the repository in the major course platforms used in Switzerland might be a key factor for the success of the repository. See for instance the NLN Module for Moodle : http://moodle.yeovil.ac.uk/mod/resource/view.php?id=11913 | |
| 44 | 29 | library systems have difficulties with dynamic content (versions) --> interface to repository? | Problem solved with snapshots of courses/content? | ES:1 // MH:1 // DA : 1 ES:1 // MH:1 // DA : 1 | MH: snapshots (once a week or once a month) might be a possibility. Always using the youngest versions. // DA : see 2 : wise to use an open archive system instead of a traditional library system | |
| 45 | 30 | integration of LMS with student administration system | ES:1 // MH:0 //ST: 1 // DA : 1 ES:1 // MH:0 //ST: 1 // DA : 1 | MH: Not possible on a national platform. Only possible with a system on the own campus. Therefore it is important to download and integrate the content in the own systems. // DA : I suggest to do the opposite : integrate the national repository search form into every local LMS or student administration system. | ||
| 46 | 31 | LMS->Library: dynamic bibliography | MH: look at 43 (29) | |||
| 47 | 32 | Modular architecture - choose optimal tool for each task | DA : 2 DA : 2 | MH: possible but depends on what is defined as "task". According to the squares on "SWITCH Services" The Big Picture / e-Academia. // DA : anti plagiarism software, available for every identified user / provide bibliographic tools that permit easy searching in RERO and NEBIS / to students who are using the platform : provide information about developing learning skills and how to find help in their own institution / to teachers who are using the platform : provide information about how to develop their teaching techniques and skills and how to find assistance in their own institution. | ||
| 48 | ||||||
| 49 | 33 | Development Services | Development of small e-learning add-ons | Will need to be specified in each case... | MH: look at 36 (25): who is the customer and who the "worker" being payed. SG: Und auf jeden Fall vorher die Use-Cases publizieren und zur Diskussion stellen, damit nicht am Publikum (zu definieren) vorbei entwickelt wird. | |
| 50 | 34 | Development of custom extensions | Will need to be specified in each case... | |||
| 51 | ||||||
| 52 | ||||||
| 53 | ||||||
| 54 |
| 1 |
|---|
| 2 |
| 3 |
| 4 |
| 5 |
| 6 |
| 7 |
| 8 |
| 9 |
| 10 |
| 11 |
| 12 |
| 13 |
| 14 |
| 15 |
| 16 |
| 17 |
| 18 |
| 19 |
| 20 |
| 21 |
| 22 |
| 23 |
| 24 |
| 25 |
| 26 |
| 27 |
| 28 |
| 29 |
| 30 |
| 31 |
| 32 |
| 33 |
| 34 |
| 35 |
| 36 |
| 37 |
| 38 |
| 39 |
| 40 |
| 41 |
| 42 |
| 43 |
| 44 |
| 45 |
| 46 |
| 47 |
| 48 |
| 49 |
| 50 |
| 51 |
| 52 |
| 53 |
| 54 |
A | B | C | D | E | F |
|---|