Learning Object Metadata - CiteSeerX

4 downloads 0 Views 690KB Size Report
In MACE, a network of learning objects for education in architecture, a LOM application profile has been defined that adds non-LOM metadata fields such as the ...
Learning Object Metadata: Opportunities and Challenges for the Middle East and North Africa Jehad Najjar, Stefaan Ternier, Erik Duval Katholieke Universiteit Leuven B-3001 Leuven, Belgium +32.16.327060 {Jehad.Najjar, Stefaan.Ternier, Erik.Duval}@cs.kuleuven.be

Mohamed Amine Chatti RWTH Aachen University, Informatik 5 Ahornstr. 55, D-52056 Aachen Germany [email protected] Abstract: This paper briefly analyses the requirements for “share and reuse” of learning objects in Middle East and North Africa. We propose a framework that can be used to connect Learning Object Repositories of the Middle East and North Africa with networks of repositories

worldwide;

through

the

services

of

the

ARIADNE

Foundation

(http://www.ariadne-eu.org/) and the GLOBE consortium (http://globe-info.org).

1. Introduction “Share and Reuse” of learning objects enables more effective and efficient creation of learning material [Wiley, 2000; Rehak and Mason, 2003]. Authors, teachers and learners can use Learning Object Repositories (LORs) to share their materials. By integrating LORs with applications like Learning Management Systems (LMSs), authoring environments (like MS Office and others) and query tools, barriers to share and reuse are removed [Verbert et al., 2005].

Title

However, creating instructional material from learning objects on a large scale requires access to large collections of learning objects. Metadata are used to describe learning objects in order to enable finding relevant content, using metadata schemas (like the IEEE Learning Object Metadata standard – LOM [IEEE, 2002]). Metadata schemas also enable the exchange of learning object metadata between repositories. Repositories that conform to the same common metadata schema can exchange metadata instances between them. In this way, it becomes possible to create a course on, for example, ‘Global Warming’ by combining objects (e.g., images, narrative texts, slides and audio and video clips) from more than one repository.

Currently, within the GLOBE consortium, several networks of LORs are inter-connected. This enables ARIADNE users to access learning objects in repositories anywhere within the GLOBE network; so that resources from MERLOT (http://www.merlot.org/) (USA), NIME (http://www.nime.ac.jp/en/) (Japan), KERIS (http://www.keris.or.kr/) (Korea), LACLO (http://www.laclo.espol.edu.ec/) (Latin-America), LORnet (http://www.lornet.org/) (Canada), COSL (http://cosl.usu.edu/ including the MIT OCW consortium material) (USA) or of EdNa (http://www.edna.edu.au/) (Australia) are all available in a seamless way.

To our knowledge, non of the LORs in the Middle East and North Africa are inter-connected with other LORs worldwide. In this paper, we briefly discuss the requirements for creating interoperable LORs. This includes (1) creating learning object metadata application profiles (section 2), (2) connecting learning object repositories using federated search or harvesting (section 3). Another relevant issue that is discussed in the paper is facilitating the provision of metadata through automatic metadata generation (section 3), to reach a critical mass of learning object metadata.

2. Metadata Application Profiles When developing a learning object repository, the first step to be taken is defining a metadata application profile. Metadata designers typically create an application profile by customizing a base schema to fit the needs of local users [Heery and Patel, 2000]. The designers need to select the metadata elements that will be included in the profile and that will be used to describe learning objects in their repository. This selection is based on the needs and context of the served environment. In addition, the valid values and the obligation status (optional, mandatory, etc.,) of every selected metadata elements need to be defined. 2.1 Building an Application Profile In this section, we first (in subsection 2.1.1) discuss how metadata elements of application profiles are selected from base schemas. Then (in subsection 2.1.2), we explain how values of those elements are also selected from values of a base schema. Afterwards, we discuss how designers, in application profiles, assign the obligation status (mandatory, optional, etc.) and multiplicity (one or multiple value entries) for the elements of their application profiles; in subsections 2.1.3 and 2.1.4 respectively. 2.1.1 Data Elements

The first task in building an application profile is the selection of data elements, based on the needs, requirements and policies of the community of practice. For instance, consider a profile P that represents a cultural heritage learning object repository in the United Arab Emirates, where decision makers are concerned about the historical period each particular object relates to. A representative profile of this domain should include, within its element set, an element that captures information about the historical period coverage. Another

Title

example, a repository that collects learning material of schools should include within its element set a metadata element that captures the age group of students that a learning object is intended to be learned by.

Application profiles may include all the elements (complete set) of the base schema, include only a subset of the base schema or include elements from more than one base schema.

In this subsection, we have discussed the selection of application profile elements from elements of a base schema(s); the values of those elements have not been selected yet. The next section focuses on assigning values for data elements of application profile; values may also be selected from one or more base schemas.

2.1.2 Value Domains

In the previous subsection, the selection of the metadata elements is discussed. Here, the goal is to select a range of possible values that every selected metadata element in the profile may have. As an example: we may restrict the metadata element Coverage to accept only ‘Umayyad 7th Century’, ‘Abbasid 8th Century’ and ‘Fatimid 10th Century’ as valid values.

Value domains may be of different forms. First, an enumerated value domain is a list of vocabulary values that a data element may have. In an application profile, it is possible to mix values of a base schema with new values created by application profile designers that do not belong to the base schema. The second form of value domain is descriptive values, this value domain is defined as a pattern to which values must conform [Loshin, 2003]. For instance, values of an element that captures a telephone number of an author of a book may

be restricted, for example, to one of the patterns ‘(DDD) DDD-DDDD’ or ‘DDD-DDDDDDD’, where D represents a digit from 0-9.

2.1.3 Obligation Status

Another issue to be defined is the obligation status of the element in the application profile, which can be mandatory, recommended, conditional or optional. Some profiles may keep the obligation status as in the base schema while others may decide to make it more strict. As an example: in the cultural heritage application profile, suppose that decision makers of the application have a policy that prevents any learning object to be indexed into the system unless information related to the coverage period is provided. This implies that the obligation status of the element coverage in profile needs to be mandatory, even if the element is optional in the base schema.

As another example: in the education context, a university in the United Kingdom may choose to make the language element optional in their application profile, because all learning material in their systems is English. On the other hand, a university in the United Arab Emirates may decide to make the language element mandatory, because the university teaches courses in more than one language (e.g. Arabic, English) and teachers in the undergraduate courses want their students to only access, for example, Arabic material.

Application profiles need to satisfy the rules of their base schemas [Duval, et al., 2006]. As an example, an element that has a mandatory status in the base schema is not allowed to be changed to optional in the application profile. That is to maintain high interoperability level with the other repositories that conform to the same base schema. Table 2.1 presents the modifications that may be made on the obligation status of a base schema data element in the

Title

application profile. As can be seen in the table, application profiles may impose higher restrictions on an element, but are not allowed to relax its status.

Table 2.1: Possible modifications on obligation status of data elements

2.1.4 Multiplicity Designers of an application profile need to define the number of values allowed for every metadata element. One of the following multiplicity levels (M) may be assigned to a data element: • Zero Multiplicity: in this case, an element of a base schema is excluded from the application profile. • N Multiplicity: the number of data element value entries that can appear in a metadata instance is limited to n. • ∞ Multiplicity: in this context M = ∞, which means that an element can have any number of value entries. At the technical level, the binding defines how metadata instances are syntactically represented in, for instance, XML, RDF or SQL tables. Namespaces are used to identify the origin of elements and values in application profiles, and also, to uniquely identify every element and value [Heery, 2002]. In this way, metadata designers avoid duplication of elements and values when creating an application profile.

Nevertheless, applying the above steps does not ensure semantic interoperability between systems, which concerns the meaning of the information represented in application profile instances. The interoperability level between repositories may decline in situations were different communities have different meanings and interpretations for the data elements and their associate values. However, this issue is beyond the scope of this paper.

In this section, we discussed the creation of metadata application profiles, which enable producing interoperable learning object metadata instances. In the next section, we discuss the requirements for creating application profiles for the Middle East and North Africa context.

2.1 Middle East and North Africa Community As mentioned earlier, each community has its requirements that need to be taken into consideration when building an application profile. The three most relevant requirements for the Middle East and North Africa community are, in our opinion:

• Multilingual: several languages (e.g., Arabic, English, French, etc.) of learning are used in this region. Therefore, the application profiles should support describing learning objects in different languages. In addition, an application profile needs to include a metadata element (like 1.3 Language LOM) that enables retrieving learning objects by language. For example, consider customizing an application profile of IEEE LOM for an educational repository in the Middle East and North Africa. IEEE LOM supports different languages but does not impose the use of its elements; all elements of LOM are optional. For an institution that wants to classify and retrieve learning objects by their language, there is a need to make the 1.3 Language LOM

Title

element recommended or mandatory in its application profile. This is similar to what the ARIADNE Foundation has done in the (also multi-cultural) European context. • Multicultural: the Middle East and North Africa region has a diverse cultural context. An application profile of an institution in this region should enable representing the cultural perspectives of the described learning object when relevant. For example, it would be required in such context to include in the application profile an element (like 1.6 Coverage in IEEE LOM) that represents the culture, geography or region to which the object applies. • Customization: In addition to the above two main requirements, countries of this region have different curricula and use different categorizations of education levels and scientific topics. This leads to a requirement to enable customizing, for example, the LOM value domain of relevant elements (such as 5.6 Context which takes the values “school”, “higher education”, “training”, “other”) to accept new values that represent the educational system in the served community.

There can be other requirements to be taken into consideration in this region. Further detailed analysis is needed to identify the specific requirements for specific communities. The above requirements can guide the building and customization of learning object application profiles.

The next section introduces approaches that may be used to access metadata instances available in different repositories.

3. Connecting Learning Object Repositories Enabling large scale reuse requires the availability of a vast amount of learning objects. In this section, we present work that underpins our developments in GLOBE, a worldwide

consortium that provides access to many learning object repositories. In GLOBE, we have connected a large network of learning object repositories through standards such as SQI [Simon et al., 2005] and OAI-PMH [Lagoze and Van de Sompel, 2001]. • The Simple Query Interface (SQI) is a CEN ISSS standard that enables transporting queries to a repository. This standard was designed so that it can deal with different query languages and metadata application profiles. • The Open Archives Protocol for Metadata Harvesting (OAI-PMH) enables harvesting metadata records. Through extracting these records from a repository, a local search index can be set up. All repositories that participate in GLOBE have implemented the GLOBE metadata application profile. This profile gives a mandatory status to the following LOM elements: • Lom.general.title. Most partners in GLOBE provide a search interface. After a search has been issued, all results are displayed with their title. • Lom.general.description. Besides a title, a (brief) description of the learning object gives the user an impression of the search result. • Lom.technical.location. The values of this field have been restricted to URLs that enable retrieving the learning object. When access to the learning object is restricted, the URL resolves to a splash page that indicates how the learning object can be accessed. • Last_modification_date. For repositories that implement a harvesting interface, this field enables harvesters to select only those LOM instances that were modified. • Lom.general.identifier uniquely identifies results and sometimes enables the deletion of doubles.

Title

Figure 3.1: The GLOBE network Figure 3.1 depicts the GLOBE network at the time of writing. At the bottom of the picture, repositories provide access to their LOM metadata either through a search interface that is represented by a triangle or through a square, which is a harvest interface. When repositories provide a harvest interface, a search index is required for federated search. For example in the MACE network (http://www.mace-project.eu/), all metadata are checked for modifications daily through the OAI-PMH protocol. For every LOM instance that was added or modified, a corresponding instance in the MACE index is altered. This search index offers search functionality to the GLOBE network through an SQI target.

Many LORs in GLOBE provide an SQI interface and can thus be searched directly. ARIADNE has implemented a federated search engine [Ternier et al., 2005] that can accept queries from search tools such as the ARIADNE finder [Neven et al., 2003] and is able to forward these queries into the GLOBE network. The federated search engine aggregates all results it receives from the different repositories and returns this aggregate results list to the search client. As all GLOBE repositories support the GLOBE metadata application profile, a GLOBE search client can rely on the existence of at least these mandatory metadata fields.

Note

that

networks

like

MACE

(http://www.mace-project.eu/),

ARIADNE

(http://www.ariadne-eu.org/), CGIAR (http://www.cgiar.org/) and MELT (http://meltproject.eu/) have implemented different metadata application profiles that are much richer then the GLOBE profile. In MACE, a network of learning objects for education in architecture, a LOM application profile has been defined that adds non-LOM metadata fields such as the GPS coordinate of a building or that, for example, restricts LOM vocabularies to certain thesauri (e.g. the getty thesaurus [Getty, 2008]) that are relevant in architecture. As a result, we support various degrees of interoperability. MACE users build on the MACE metadata application profile to issue queries using query features that are relevant for expressing architectural needs. However, these MACE specific queries can not be sent to GLOBE repositories in general as these do not offer support for all metadata fields in the MACE application profile. On the other hand, GLOBE clients can interoperate with MACE repositories as the MACE application profile offers support for all mandatory fields in the GLOBE application profile.

When building a metadata application profile for the Middle East and North Africa world, we suggest creating the application profile so that it conforms to the GLOBE metadata

Title

application profile. If such a Middle East and North Africa repository offers search access through a standard such as SQI, its content will be accessible in GLOBE. Such connections are relevant for the Middle East and North Africa world, as its learning objects (for instance, its cultural heritage) become accessible at a global level; and the users of these repositories will be able to benefit from all the learning objects that are already available in GLOBE.

So far, we discussed the creation of application profiles and the inter-connection of learning object repositories. However, generating the metadata of learning objects in learning object repositories by humans is time consuming and error prone [Duval and Hodgins, 2003]. In the next section, we present approaches that can be used to automatically generate metadata instances of learning objects.

4. Automatic Generation of Metadata Most authors agree on the fact that dealing with metadata cannot be a human task [Duval and Hodgins, 2004]. There are several reasons why users often do not create metadata for their learning resources. First, expert metadata creators are considered too expensive to be employed in most educational institutions. Second, the current tools available for metadata creation are not user friendly. Most tools directly relate to some standard (such as IEEE LOM) and present that standard to the users. The user has to fill in a substantial number of electronic forms [Najjar et al., 2003; Duval and Hodgins, 2003]. A possible solution to this problem is the automatic creation of learning object metadata. Automatic metadata generation extracts relevant information from learning objects and the context they are stored or used in [Cardinaels et al., 2005]. Automatic metadata generation is broken down into four aspects: content analysis, context analysis, usage analysis and structure analysis. While in content analysis, information is extracted from the learning object itself (e.g. keyword, language),

context analysis involves the environment the object is used in (e.g., a course on Human Computer Interaction in E-TQM College in UAE). A learning object context provides extra information about the learning object that can be used to generate the metadata. A usage analysis for example evaluates the time spent reading a document or solving exercises [Najjar, et al., 2006]. Consequenly, conclusions regarding specific metadata elements can be drawn. A structure analysis involves relationship amongst objects. For example, one slide in a slide show often gives relevant context about the content of the next slide [Cardinaels et al., 2002; Cardinaels and Duval, 2003; Cardinaels et al., 2005].

In the following sections, we focus on two frameworks for automatic metadata generation, namely AMG; the automatic metadata generation framework developed at the Katholieke Universiteit Leuven, Belgium and ALOA; the web services driven framework for automatic learning object annotation developed at RWTH Aachen University, Germany, with active support from the Katholieke Universiteit Leuven (K.U.Leuven), Belgium in the framework of the PROLEARN project (http://www.prolearn-project.org/).

4.1 The AMG Framework

[Cardinaels et al., 2005] and [Ocha et al., 2005] describe a framework to set up an automatic metadata generation system as a web service called AMG. The overall structure of this framework is depicted in Figure 4.1. The framework consists of two major groups of software classes that generate the metadata, namely Object-based indexers and Context-based indexers. The object-based indexers generate metadata based on the learning object itself, isolated from any other learning object or learning management system. The second class of indexers uses a context to generate metadata. The framework also has some Extractors that

Title

for example extract the text and properties from a PowerPoint-file, and a MetadataMerger that can solve conflicts between indexers and the combine the results of the different indexers into one resulting metadata record for the learning object.

Figure 4.1: Overall Structure of AMG 4.2 The ALOA Framework

Rather than interoperability and cooperation between metadata generation systems, the primary focus of the ALOA system has been on the flexibility and extensibility of the framework, such that new metadata generation services/modules can easily be plugged into the basic system. The ALOA system already implements different modules and is capable of generating a substantial part of the IEEE LTSC LOM metadata from different types of learning objects (e.g. HTML, PDF, PPT, Word). The goal of flexibility was achieved by providing a public Web Services API that can be used by third party applications. A Service Oriented

Architecture (SOA) makes it possible to extend the framework with new

components. Figure 4.2 depicts an abstract view of the ALOA system. The main components of ALOA are Extractors and Generators. An extractor is responsible for extracting text information from a learning object along with more properties about the learning object. ALOA implements different extractors for different learning object types (e.g. html, pdf, ppt,

word). Only one extractor can be defined for each learning object type. A generator is responsible for the actual metadata generation. It uses the output of an extractor and applies data mining techniques to generate one or parts of the metadata. ALOA implements several generators such as the “Topicalizer” (http://www.topicalizer.com/) generator for keywords, summary, language and difficulty level, the “LingPipe” (http://www.alias-i.com/lingpipe/) generator for person names, and “Tagthe” (http://www.tagthe.net) generator for keywords. ALOA has a flexible architecture that enables everyone to easily create a new extractor/generator and plug it into ALOA via the configuration management interface.

Figure 4.2: Abstract View of ALOA The ALOA system is able to generate metadata in different languages. Currently, ALOA supports six languages namely English, German, Arabic, French, Spanish, and Korean. Figure 4.3 shows the result of the generation of the LOM “summary” metadata from the MIT

Title

course “Database Systems” in these languages. ALOA is using Google Translate (http://books.google.com/translate_t) for its translation service.

Figure 4.3: ALOA Language Support The ALOA framework adopts a slightly modified version of the Web Service Definition Language (WSDL) developed at K.U.Leuven in order to standardize the communication between a federated AMG engine and different matadata generation systems (called SAmgI installations [Meire, et al., 2007]). Consequently, ALOA and AMG can complement each other in two different ways. On the one hand, ALOA can be viewed as a new SAmgI installation that can be used by the federated AMG engine. On the other hand, AMG can be implemented as a new component of ALOA (i.e. extractor or generator).

5. Conclusions and Future Work In this paper, we presented the steps involved in building application profiles of learning object repositories. The requirements for creating application profiles for the Middle East and North Africa were briefly discussed. We also presented an approach to connect heterogeneous learning object repositories, in order to access large amounts of learning objects distributed worldwide. As far as the indexing of learning objects is concerned, we presented two frameworks for creating the metadata of learning objects automatically.

The goal of this paper is to briefly present the opportunities for building interoperable learning object repositories for the Middle East and North Africa. Furthermore, we discussed approaches that may be used to connect those repositories with networks of repositories worldwide through the services of the ARIADNE Foundation (http://www.ariadne-eu.org/) and the GLOBE consortium (http://globe-info.org).

As future work, we believe that there is a need for building a community of interest around learning objects in the Middle East and North Africa region. This community can further analyse the requirements for developing learning object repositories that serve the need of the local community while maintaining the interoperability with the external networks of repositories. Such work will enable repositories in the Middle East and North Africa to access large number of learning objects distributes worldwide, and vice versa.

References [ARIADNE, 2006] ARIADNE foundation for the European knowledge pool (2006), Retrieved September 6, 2007 from http://www.ariadne-eu.org/. [Cardinaels and Duval, 2003] K. Cardinaels and E. Duval, Composite learning objects: exposing the components, in Proceedings of the 3rd Annual ARIADNE Conference, pages 7, 2003.

Title

[Cardinaels et al., 2002] K. Cardinaels, E. Duval and H. Olivié, Issues in Automatic Learning Object Indexation, in Proceedings of ED-MEDIA World Conference on Educational Multimedia, Hypermedia and Telecommunications, pages 239-240, 2002. [Cardinaels et al., 2005] Cardinaels, K., Meire, M. and Duval, E., (2005). Automating Metadata Generation: the Simple Indexing Interface. Proc. of the 14th Int. Conf. on World Wide Web. Chibo, Japan. [Cardinaels, 2007] K. Cardinaels, Dynamic learning object life cycle and its implications for automatic metadata generation, PhD thesis, Faculteit Ingenieurswetenschappen, Katholieke Universiteit Leuven, 2007. [Dublin Core, 2003] Dublin Core metadata element set v1.1, 2003, Retrieved September 6, 2007, from http://dublincore.org/documents/2003/02/04/dces/. [Duval and Hodgins, 2003] E. Duval, and W. Hodgins, A LOM Research Agenda, WWW2003 Conference, 20-24 May 2003, Budapest, Hungary. [Duval and Hodgins, 2004] Duval, E., Hodgins, W. (2004). Metadata matters. Proc. of DC2004, Shanghai, China. [Duval, et al., 2002] E. Duval, W. Hodgins, S. Sutton, S. Weibel, Metadata principles and practicalities, D-Lib Magazine, vol. 8, no.3, 2002. [Duval, et al., 2006] E. Duval, N. Smith, and M. Van Coillie, Application profiles for learning, Proceedings of the IEEE International Conference on Advanced Learning Technologies (ICALT), pp. 242-246, 2006. [Getty, 2008] Getty Thesaurus of Geographic Names, http://www.getty.edu/research/conducting_research/vocabularies/tgn/.

retrieved

from

[Heery and Patel, 2000] R. Heery, M. Patel. Application profiles: mixing and matching metadata schemas, Ariadne Magazine, issue 25, pp. 2004-3, 2000. [Heery, 2002] R. Heery, Application profiles: interoperable friend or foe?, TEL Milestone Conference, The European Library, pp. 34-39, 2002. [IEEE, 2002] 1484.12.1 IEEE LTSC Draft Standard for Learning Object Metadata (2002), Retrieved August 17, 2007, from http://ltsc.ieee.org/wg12/files/LOM_1484_12_1_v1_Final_Draft.pdf. [Lagoze and Van de Sompel, 2001] Lagoze, C. and Van de Sompel, H. (2001). The open archives initiative: building a low-barrier interoperability framework. In JCDL ’01: Proceedings of the 1st ACM/IEEE-CS joint conference on Digital libraries, pages 54–62, New York, NY, USA. ACM.

[Loshin, 2003] D. Loshin, Data value domains, The Data Administration Newsletter, issue 24, 2003. [Meire, et al., 2007] M. Meire, X. Ochoa, and E. Duval, SAmgI: Automatic Metadata Generation v2.0, Proceedings of World Conference on Educational Multimedia, Hypermedia and Telecommunications, pp. 1195-1204, 2007. [Najjar, et al., 2003] J. Najjar, S. Ternier, and E. Duval, The actual use of metadata in ARIADNE: an empirical analysis, Proceedings of the ARIADNE Conference, pp. 1-6, 2003. [Najjar, et al., 2006] J. Najjar, E. Duval, and M. Wolpers, Towards effective usage-based learning applications: Track and learn from user experience(s), Proceedings of the IEEE International Conference on Advanced Learning Technologies (ICALT), pp. 1022-1024, 2006. [Neven et al., 2003] Neven, F., Duval, E., Ternier, S., Cardinaels, K., and Vandepitte, P. (2003). An open and flexible indexation- and query tool for Ariadne. In Proceedings of the ED-MEDIA 2003 World Conference on Educational Multimedia, Hypermedia, and Telecommunications, pages 107–114. AACE, AACE. [Ochoa et al., 2005] Ochoa, X. et al. Frameworks for the Automatic Indexation of Learning Management Systems Content into Learning Object Repositories. Proc. of ED-MEDIA 2005, Montreal, pp. 1407-1414. [Rehak and Mason, 2003] D. Rehak and R. Mason, Keeping the learning in learning objects, Reusing Online Resources: a sustainable approach to elearning, Kogan Page, London, 2003. [Simon et al., 2005] Simon, B., Massart, D., van Assche, F., Ternier, S., Duval, E., Brantner, S., Olmedilla, D., and Miklos, Z. (2005). A Simple Query Interface for Interoperable Learning Repositories. In Proceedings of the 1st Workshop on Interoperability of Web-based Educational Systems, pages 11–18. [Ternier et al., 2005] Ternier, S., Olmedilla, D., and Duval, E. (2005). Peer-to-Peer versus Federated Search: towards more Interoperable Learning Object Repositories. In -, pages 1421–1428. AACE, AACE. [Verbert, et al., 2005] K. Verbert, J. Jovanovic, D. Gasevic, and E. Duval, Repurposing learning object components, Lecture Notes in Computer Science, pp. 1169-1178, 2005. [Wiley, 2000] D. Wiley, Learning Object Design and Sequencing Theory, PhD Thesis, Birgham Young University, 2000.

Title

About the Authors: Jehad Najjar

Jehad Najjar is a researcher in the Hypermedia and Databases research group – Computer Science Department – of the Katholieke Universiteit Leuven, Belgium. His research interests are technology enhanced learning, learning objects, metadata, attention metadata, interoperability, application profiles, evaluation of the actual use of learning object metadata, usability engineering and human computer interaction in general. He co-authored the Contextualized Attention Metadata (CAM) specifications; a schema and framework for tracking and managing data about user attention and interest across systems and contexts. He is also co-ordinating the CAMA international workshop on contextualized attention metadata. Furthermore, he is involved with the MACE and MELT eContent+ projects.

Stefaan Ternier

Stefaan Ternier is a research and teaching assistant at the research unit on hypermedia and databases, part of the computer science department of the Katholieke Universiteit Leuven. His research interests are in architectures for learning objects and interoperability. In that respect he coordinated the development of a services oriented architecture for the ARIADNE Knowledge Pool System. Furthermore, he is involved with the MACE and MELT eContent+ projects, GLOBE (an international consortium that provides a distributed network of learning objects) and CEN/ISSS where he co-authored the Simple Query Interface (an accredited standard for search interoperability).

Mohamed Amine Chatti

Mohamed Amine Chatti has a diploma degree in Computer Science from the Technical University of Kaiserslautern, Germany. Currently, he is working as a research assistant and PhD student at the Chair of Computer Science 5 – Information Systems, RWTH Aachen University, Germany. His research interests include learning and knowledge management, learning objects metadata, collaborative adaptive learning, communities and networks, social software and social network analysis.

Erik Duval

Erik Duval is a professor in the research unit on hypermedia and databases, at the computer science department of the Katholieke Universiteit Leuven. Erik teaches courses on HumanComputer Interaction, Multimedia, Problem Solving and Design. His current research interests are metadata in a wide sense, learning object metadata in particular, and how they enable finding rather than searching; a global learning infrastructure based on open standards; human-computer interaction in general, and in a learning or digital repository context in particular, so that we can "hide everything but the benefits"; the application of information and communication technology in education and training. Erik serves as president of the ARIADNE Foundation, technical editor for the standard on Learning Object Metadata, coordinator of the work on learning objects, metadata and interoperability within the ProLearn Network of Excellence, a member of the Scientific and Technical Council of the SURF Foundation. Erik is a fellow of the AACE, a member of ACM, and the IEEE computer society.

Suggest Documents