Learning Technology Standards Observatory Luis Anido-Rifón Grupo de Ingeniería de Sistemas Telemáticos (GIST) University of Vigo

2 Contents 1. Project Team 2. Introduction 3. Support for a Dynamic Observatory 4. A Multilingual Observatory 5. Roles involved 6. Interoperability 7. Additional Functionality 8. Population 9. Technical support 10. Hosting 11. CWA 12. Timeline

3 The Project Team  PT leader: Luis Anido-Rifón  PT members: Manuel Fernández-Iglesias Martín Llamas-Nistal Manuel Caeiro-Rodríguez Judith Rodríguez-Estévez Juan Santos-Gago Fernando A. Mikic Luis Álvarez-Sabucedo Grupo de Ingeniería de Sistemas Telemáticos ETSI Telecomunicación University of Vigo

4 Introduction  The output of this work will be A dynamic Observatory for Learning Technology Standards A set of administration tools to manage the entire web site.  Different lingual versions of the observatory may be provided as a result of this work.  Further population will be based on administration tools with restricted permissions over the observatory data.

5 Support for a Dynamic Observatory  Structure and contents will be dynamic.  Structure will consist on a tree composed of a three-level category system and a fourth level for contents  Each node in the first three levels will have a page linked to it.  The fourth level will have as many pages linked as desired.

6 Support for a Dynamic Observatory (ii)  To create and fill the repository administrators will follow a three-step procedure: 1. Create the structure 2. Create contents (www pages) 3. Bind contents to nodes in the structure  The whole process will be supported by a Web-based authoring tool.

7 Generating a dynamic structure. Example

8 Generating a dynamic strucutre. Example

9 Generating a dynamic structure. Example

10 Generating a dynamic strucuture. Example

11 Generating a dynamic structure. Example

12 Generating a dynamic structure.  Administration tools will allow to: Create a node in the structure Rename Enable/Disable (visible / not visible) Delete

13 Generating dynamic contents  Contents are supported by two main components: Pages: containers for information Elements: media elements to be included in pages Pages  SCO Elements  assets

14 Generating dynamic contents. Elements (i)  Authoring tools provided will facilitate the creation of the following types of elements to be included in pages: Paragrahps Text + Images Hyperlinks Enumerates Itemizes

15 Generating dynamic contents. Elements (ii)  Advanced elements will support to directly introduce HTML code in a page. In this way, other multimedia elements not included in the pre-defined elements can be used in the observatory.  A tool to upload embedded objects will be provided.

16 Generating dynamic contents.

17 Generating dynamic contents (ii)  Pages may be annotated with keywords and areas (selected from a pre-defined set of areas of interest for the observatory). This information will be used by an internal search engine to help users to locate contents in the observatory.

18 Generating dynamic contents (iii)  Example: A page containing a description on LOM draft 4.0 may be annotated as follows: Keywords: LOM, previous versions Areas: Educational Metadata The set of areas of interest will be dynamic (add a new area, remove, etc.)

19 Binding contents and structure (i)  So far, we have a container structure and a pool of pages with contents.  The last step is to bind a page from the pool to a node in the structure.

20 Binding contents and structure (ii)  This binding is implemented through a simple UI where users just need to match the element of the structure with the page already created in the previous step.  This binding can be modified, removed or created at any time using the authoring tool.  The same page may be bind to two or more nodes in the structure

21 Binding contents and structure

22 Index 1. Project Team 2. Introduction 3. Support for a Dynamic Observatory 4. A Multilingual Observatory 5. Roles involved 6. Interoperability 7. Additional Functionality 8. Population 9. Technical support 10. Hosting 11. CWA 12. Timeline

23 Multilinguality (i)  Different views of the observatory (structure+contents) may exist. One instance per EU language is possible.  Each lingual view of the repository will be managed by a concrete administrator responsible for the development and maintenance of its contents.  Different lingual versions may have different contents and structure.  The same individual may be responsible for more than one lingual version of the repository.

24 Multilinguality (ii) Different language versions may be completely different. Actual contents depend on those responsible for filling it; for example, User20 is responsible for the observatory in German, …

25 Multilinguality (iii)  While User21 is responsible for the observatory in English

26 Multilinguality (iv)  Interface towards standards observers will be automatically updated according to the information provided by administrators. Therefore, support for the whole set of EU languages will be automatically provided.  Nevertheless, some pre-defined labels are fixed (e.g. the word “news” to access the news system). Help from the WS will be required to translate them to the whole set of EU languages.  The interface for administration and authoring tools will be developed in English.

27 Index 1. Project Team 2. Introduction 3. Support for a Dynamic Observatory 4. A Multilingual Observatory 5. Roles involved 6. Interoperability 7. Additional Functionality 8. Population 9. Technical support 10. Hosting 11. CWA 12. Timeline

28 Roles involved  There are four different roles involved: 1. Standards observers. 2. Administrators: a) General administrator b) Observatory administrator c) Local administrator

29 Roles involved: Local administrator (i)  Responsible for managing the structure and the contents below three-level nodes  They define subcategories below the second-level nodes.  They produce pages to be used in the third and fourth levels.

30 Roles involved: Local administrator (ii)

31 Roles involved: Local administrator (iii)  The same local administrator may be responsible for different categories in different lingual versions of the observatory

32 Roles involved: Local administrator (iv) For example, user2 may be responsible for entering and maintaining information on IEEE LTSC, LOM and PAPI in English and French and IMS consortium, LIP and SCORM in Spanish, while user 3 may be responsible for AICC and CMI in English, French and Spanish and IEEE LTSC, LOM and LIP in Italian.

33 Roles involved: Observatory administrator (i)  Responsible for the dynamic development of the main structure of the Web site.  Responsible for one or more lingual views of the observatory.  He will also be allowed to act as local administrator in the lingual versions he is responsible for

34 Roles involved: Observatory administrator (ii)  At least, the observatory administrator would create a first level category for “standardization bodies” (with each body appearing as a second level category below it, e.g. LTSC, IMS, ADL, etc.) and for each standardization category or area (e.g. metadata, learner profiles, runtimes, packaging, etc.).

35 Roles involved: General administrator  Responsible for managing observatory administrators and local administrators (e.g. definition of new users, assignation of responsibilities).  The general administrator will have complete access to the different lingual versions of the repository available.

36 Roles involved

37 Index 1. Project Team 2. Introduction 3. Support for a Dynamic Observatory 4. A Multilingual Observatory 5. Roles involved 6. Interoperability 7. Additional Functionality 8. Population 9. Technical support 10. Hosting 11. CWA 12. Timeline

38 Interoperability (i)  In addition to the previously presented dynamic information system, administrators will have the possibility to enter metadata about the different standards present in the repository.  For this, the PT will define a conceptual model and a binding to XML for describing e-learning standards and e- learning standardization bodies.

39 Interoperability (ii)  Administrators with the correct permissions will be allowed to fill a metadata record to be binded to a page.  Publication needs approval by the observatory administrator.  This record will be used to generate the corresponding XML file.

40 Interoperability (iii)  Metadata about e-learning standards (conceptual model): Name: LOM Version: 1.0 Date: June 2002 Area: Educational Metadata Institution: IEEE LTSC Editor: Erik Duval Locator: Summary: This standard defines ….

41 Interoperability (iv)  Binding to XML LOM 1.0 June 2002 Educational Metadata IEEE LTSC Erik Duval This standard defines…

42 Interoperability (v)  The main page of the observatory will provide a link to those available downloable “metadata” files about the standards in the observatory  Although this data may also be displayed to standards observers, the main aim is to provide a mechanism to transfer information to other e-learning standards observatory/portals.

43 Index 1. Project Team 2. Introduction 3. Support for a Dynamic Observatory 4. A Multilingual Observatory 5. Roles involved 6. Interoperability 7. Additional Functionality 8. Population 9. Technical support 10. Hosting 11. CWA 12. Timeline

44 Additional Functionality (i)  Open discussion forum  News: administrators will be able to define news which will be displayed in the Observatory.

45 Additional Functionality (ii)  Events. administrators will be allowed to publicize events related to the learning technology standardization process. Initial data for an event will be the same as provided for a page in the observatory main structure. The home page of the observatory will include an events display area where they will be shown according to the event dates. Past events will be automatically deleted from this area.

46 Additional Functionality (iii)  Events calendar. Using this information, a calendar with the information about events will be displayed to users.  News and events letter bulletin. Using data from news and events, the repository will create a monthly bulleting including news published and events celebrated during that month. This bulleting will be created in PDF

47 Additional Functionality (iv)  Notification mechanism. There will be a notification mechanism to allow users to subscribe to the news and/or events information system. News and information on events will be sent by e- mail.

48 Additional Functionality (v)  Standards producers agenda. An agenda will be developed to provide access and contact information for those individuals actively involved in the learning technology standardization process. Approval for being included in the agenda will be granted by the general administrator.

49 Additional Functionality (vi)  Internal search engine. To locate information on standards or standardization bodies. This engine will use keywords and areas marked when contents are annotated.

50 Index 1. Project Team 2. Introduction 3. Support for a Dynamic Observatory 4. A Multilingual Observatory 5. Roles involved 6. Interoperability 7. Additional Functionality 8. Population 9. Technical support 10. Hosting 11. CWA 12. Timeline

51 Population  The PT will fill the observatory with initial data on those standards and bodies indicated by the WS.  The main standardization bodies will be contacted and provided with local administration accounts to further feed the observatory, maintain and update their data.

52 Index 1. Project Team 2. Introduction 3. Support for a Dynamic Observatory 4. A Multilingual Observatory 5. Roles involved 6. Interoperability 7. Additional Functionality 8. Population 9. Technical support 10. Hosting 11. CWA 12. Timeline

53 Technical issues Due to the expertise of the team and the strict project deadlines, the development of the observatory will be supported by the following technologies and software infrastructure:  ASP.NET  SQL Server 7.0  MikTex  Propietary C++ software to create PDF news and events letter bulletin.

54 Index 1. Project Team 2. Introduction 3. Support for a Dynamic Observatory 4. A Multilingual Observatory 5. Roles involved 6. Interoperability 7. Additional Functionality 8. Population 9. Technical support 10. Hosting 11. CWA 12. Timeline

55 Hosting The prototype will be developed and accessed from the University of Vigo facilities. From September, 2003, the observatory will be deployed in an ISP that will provide a high-bandwidth access.

56 Index 1. Project Team 2. Introduction 3. Support for a Dynamic Observatory 4. A Multilingual Observatory 5. Roles involved 6. Interoperability 7. Additional Functionality 8. Population 9. Technical support 10. Hosting 11. CWA 12. Timeline

57 CWA (i) In addition to the above described observatory itself, it is expected that a CWA is developed and agreed upon, based on the contents of the design document. The final CWA is expected for delivery by end 2003.

58 CWA (ii) The PT suggest to focus the CWA contents on a reference manual to ease the further maintenance of the observatory: Manual for administrators (local, observatory and general). Manual for standards observers. In addition, the conceptual model for the metadata used to describe standards and standardization bodies should be defined as part of the CWA.

59 Index 1. Project Team 2. Introduction 3. Support for a Dynamic Observatory 4. A Multilingual Observatory 5. Roles involved 6. Interoperability 7. Additional Functionality 8. Population 9. Technical support 10. Hosting 11. CWA 12. Timeline

60  Key dates (year 2003): 1. March/april (Q1 meeting) 2. July (Q2 meeting) 3. October (Q3 meeting) 4. December (Q4 meeting) Timeline (i)

61  By Q1 meeting: First prototype of the administration tool for the general administrator. First prototype of the observatory (English UI version). Timeline (ii)

62 Timeline (iii)  By Q2 meeting: Fully functional version of administration tools for:  General administrator  Observatory administrator  Local administrator Second version of the observatory (fully functional version of the dynamic contents/structure and 50% of additional functionalities (forum, news, etc.) completed. First draft of CWA Filling the repository (English content) Establisment of contact with standardization bodies

63  By Q3 meeting: Fully functional version of the observatory. Transfer to a commercial ISP. Second version of the CWA. Request for comments/suggestions. Request for additional language versions (translations of labels for the UI to be provided by the WS) Timeline (iv)

64  By Q4 meeting: Final CWA delivery. Final version of the observatory (additional language versions implemented) Timeline (v)

65  Please send your comments to Thanks VIGO