October 2006 Volume 9 Number 4

More documents

Recommendations

Info

set of descriptive elements that support cross-domain discovery. Where domain specific communities want to extend the Dublin Core set, they develop what are known as Application Profiles for their community (DCMI, 2003). Given that governments, museums and galleries, and other sectors use DC metadata for information sharing, AccessForAll aims to take advantage of the interoperability of DC descriptions. DC metadata also has the advantage that it is used in many countries for resources that are created in many different languages and so can be used for cross-language discovery. DC metadata is for describing resources and does not support rich descriptions of people but as people are not described in the learner needs and preferences profile, this is not a problem. It would be necessary, however, for there to be DC usable descriptions of learners’ needs and preferences but, as stated above, these need not be Dublin Core descriptions although, as argued elsewhere, they could be DC-style descriptions and described as DC resources to allow for their discovery (Nevile, 2005). Interoperability across Information Models DC Metadata and IEEE LOM and IMS LIP metadata belong to very different information models. DC metadata has a ‘flat’ structure with a set of ‘tags’ that can be applied individually or collectively to resources. IEEE LOM, and therefore IMS LIP, models are very different. IEEE LOM (and IMS LIP) structure is deeply hierarchical. The difficulty of matching information from ‘flat’ to ‘heirarchical’ models, and the reverse, has separated the two communities for some time. Recently there have been agreements to work towards a common structure in the future, and some attempts to find suitable temporary solutions for the present. The DC and IEEE LOM communities do share the use of standard syntax including HTML, XHTML, eXtensible Markup Language (XML), in particular, and the more narrowly defined Resource Description Framework XML (RDF). Both XML and RDF are extensible, however, so that they are used by two systems does not necessarily mean very much in terms of functional interoperability. On the other hand, it is this extensibility that makes it possible for the best attempts at interoperability. In summary, AccessForAll needs to interoperate with a number of other relevant metadata specifications and standards. The History of the AccessForAll Interoperability Efforts Originally, the AccessForAll descriptions were developed for an in-house application. The original prototype Inclusive Learning Exchange (TILE), was a system that chose among a set of resource components according to the learner’s needs and preferences. The resources were treated at the atomic level, each image and chunk of text, such as text articles, captions for other rich media resources, and so on, being separately stored and described. The learner’s needs and preferences information was set within the system and variable at any time the system was being used. The descriptive information was related in a hierarchical decision-tree that allowed for different levels of detail appropriate for the circumstances. The resource components in the learning system were described so that their potential for matching was available to the application that chose and assembled the components to be delivered as the resource. There was no need for interoperability with other systems in this case as the system was in-house and contained all the resources, components and user profiles. The original specifications for TILE were adopted by the IMS Global Learning Project with the aim that they would become interoperable by extending the IEEE LOM and the IMS LIP in a consistent way. They were dependent upon their common expression in an XML binding, inherited from TILE, for interoperability. The IMS Accessibility Special Interest Group sought permission to work towards an open standard with participation from others (including the DCMI Accessibility Working Group) in order to increase the opportunities for widespread adoption and interoperability. This collaboration led to the deconstruction of the original AccessForAll model and a new construction, without loss of particulars, as an abstract model (see below). During this process, it was crucial to the success of the outcome that it would not compromise its relationship with the LIP or the LOM. Before the adoption by DCMI of AccessForAll as a recommendation to the DC users community, and in anticipation of a revised, interoperable IMS version of the AccLIP and AccMD, the IMS specifications were forwarded to the International Standards Organisation (ISO JTC1 SC36) for adoption as a multi-part 221
international standard. The ISO process involves the support and participation of a range of nations and helps foster international adoption of the specifications. According to the agreement by which the specifications were contributed by IMS, unlike many of the ISO standards, they will be free to those who want to use them. Enabling Interoperability with Abstract Models Between them, IEEE LOM and DC metadata describe many of the resources that are of interest in education. Some educational systems use LOM-based metadata sets to describe their resources but others use DC-based sets and others use a combination or different metadata. Although it is not clear how many do what, there has been careful analysis of the use of IEEE LOM and it is clearly an important player as is DC metadata, particularly as the latter is often used for government or document-type resources (Godby, 2004). It makes sense that these two communities should be able to exchange metadata records about their resources so they can, in fact, share their resources. To do this, they need to be able to transform metadata from one specification to the other. There is an activity, started in 2001 by the production of a joint article (Duval et al, 2002) that aims to bring the two sets of specifications into harmony. It cannot be done easily because LOM and DC metadata are based on very different information models. In 2004, to clarify the nature of DC metadata, the DCMI developed an abstract model of DC metadata (DCAM) that was adopted in early 2005. The model defines the scope and functions of DC metadata that enables its implementation using a range of syntaxes without loss. Where the syntax is standard, as where standard XML or RDF is used, both the structure (defined in the abstract model) and the syntax will be interoperable across all DC metadata applications. Such applications are formally known as application profiles (CWA14855). Once abstract models are agreed, it is relatively easy to develop information models (instantiations of the abstract model) and to create the syntax for representation of the information and then it is up to the community to agree on the terms to be used (semantics) for complete technical interoperability. The DCMI community developed their abstract model ten years after their information model, but fortunately for them, had a relatively simple information model. The IEEE LOM information model is extensive and complex and so far there is no corresponding abstract model for it. DCMI introduces its abstract model as follows: This document specifies an abstract model for DCMI metadata. The primary purpose of this document is to provide a reference model against which particular DC encoding guidelines can be compared. To function well, a reference model needs to be independent of any particular encoding syntax. Such a reference model allows us to gain a better understanding of the kinds of descriptions that we are trying to encode and facilitates the development of better mappings and translations between different syntaxes. (DCMI, 2005) In order to be recommended by the DC Usage Board for general adoption by the DC community, AccessForAll metadata needed to be explained in DC terminology. In effect, by late 2005, this meant it had to comply with the DC Abstract Model. As AccessForAll did not have an abstract model, developing one seemed like a good exercise. In the end, it was a very constructive exercise. The AccessForAll Abstract Model Developing abstract models is not easy when what they are to represent is already defined but in the case of AccessForAll, there was the opportunity to redefine the AccessForAll information model concurrently with developing its abstract model. The main problem was finding an abstract way to define AccessForAll that would maintain interoperability with all the relevant information models (structure), syntax (easier), semantics (relatively simple), and encourage systemic adoption. The AccessForAll Framework includes, significantly, both the user’s needs and preferences profile and the resource profile. In presenting its abstract model, DCMI provides a set of definitions and rules followed by a diagram expressed in a formal graphical representation format known as Unified Modeling Language (UML). The AccessForAll abstract model is now similarly described. 222
Page 1 and 2:
October 2006 Volume 9 Number 4
Page 3 and 4:
Guidelines for authors Submissions
Page 5 and 6:
How Does Educational Technology Ben
Page 7 and 8:
Adaptivity is one of the most impor
Page 9 and 10:
3. Ease of editing and updating: wh
Page 11 and 12:
Accessible and personalized Learnin
Page 13 and 14:
From this definition, we figured ou
Page 15 and 16:
Verifying contents Figure 3. The pa
Page 17 and 18:
Figure 7. The ISA on line interface
Page 19 and 20:
Adaptive Technology Resource Centre
Page 21 and 22:
World Wide Web Consortium (1999a).
Page 23 and 24:
guiding and supporting environment
Page 25 and 26:
As an example, to improve the acces
Page 27 and 28:
option). Although this finding migh
Page 29 and 30:
of eLearning content and enhance th
Page 31 and 32:
Hodgings, W. & Duval, E. (2002). IE
Page 33 and 34:
the entire course of study. This sy
Page 35 and 36:
information useful for the contextu
Page 37 and 38:
Nr of student 25 20 15 10 5 0 a - w
Page 39 and 40:
Vincenzo, a second year student, ne
Page 41 and 42:
Evaluation Recently embodied conver
Page 43 and 44:
The interaction may be performed on
Page 45 and 46:
Poggi, I., Pelachaud, C., & de Rosi
Page 47 and 48:
Lanzilotti, R., Ardito, C., & Costa
Page 49 and 50:
quality in use, which is measured b
Page 51 and 52:
process of designing high quality c
Page 53 and 54:
eLSE methodology Designers and eval
Page 55 and 56:
Execution phase Execution phase act
Page 57 and 58:
on the inspection process and, cons
Page 59 and 60:
Piccinini, N., & Scollo, G. (2006).
Page 61 and 62:
Answers and reinforcement A.1: Use
Page 63 and 64:
potential project ideas (from pure
Page 65 and 66:
For each column in Table 2, the sum
Page 67 and 68:
educational goals and the various r
Page 69 and 70:
A new computerized Records Manageme
Page 71 and 72:
eflected in artifacts and other str
Page 73 and 74:
any distributed community include b
Page 75 and 76:
message in order to obtain a respon
Page 77 and 78:
Figure 3. Social network after intr
Page 79 and 80:
increased face-to-face collaboratio
Page 81 and 82:
References Bogenrieder, I. (2002).
Page 83 and 84:
Donoghue, S. L. (2006). Institution
Page 85 and 86:
contemplate part-time, rather than
Page 87 and 88:
espective institutions. The primary
Page 89 and 90:
greater flexibility in course selec
Page 91 and 92:
Cost-benefit One distinct benefit o
Page 93 and 94:
Resources The development of online
Page 95 and 96:
courses where it is has little pote
Page 97 and 98:
A fellowship programme, such as the
Page 99 and 100:
Moore, M.G. (1998). Introduction. I
Page 101 and 102:
Software reuse has two dimensions,
Page 103 and 104:
Courseware development process mode
Page 105 and 106:
Didactics analysis This phase consi
Page 107 and 108:
Process didactics design We focus o
Page 109 and 110:
The repository is organized into co
Page 111 and 112:
the analysis and the design phase o
Page 113 and 114:
Figure 12. Weaving content and dida
Page 115 and 116:
complete user-specific (author, ins
Page 117 and 118:
References ADL (Advanced Distribute
Page 119 and 120:
Bender, D. M., & Vredevoogd, J. D.
Page 121 and 122:
(see Figure 2). The incorporation o
Page 123 and 124:
Figure 4: Example of Summary Image
Page 125 and 126:
The competitive nature of design cl
Page 127 and 128:
Dias, L. B. (1999, November). Integ
Page 129 and 130:
materials built into the system. Th
Page 131 and 132:
This theory of multimedia learning
Page 133 and 134:
E-Tutor (with video). Two weeks aft
Page 135 and 136:
empirically tested in TML environme
Page 137 and 138:
Rieber, L. P., (1990). Animation in
Page 139 and 140:
Appendix B The following 44 items r
Page 141 and 142:
Appendix C A Sample of Exam Questio
Page 143 and 144:
Appendix D Perceived Usefulness Que
Page 145 and 146:
Kirkpatrick, and Peck (2001) have a
Page 147 and 148:
2001). The system thus aims to assi
Page 149 and 150:
a strong agreement between the two
Page 151 and 152:
of the dynasty. 3. Information on
Page 153 and 154:
Comparing works designed using the
Page 155 and 156:
Tselios, N., Stoica, A., Maragoudak
Page 157 and 158:
strategies during their interaction
Page 159 and 160:
P(B|D) is the probability of a netw
Page 161 and 162:
Online help adaptation using Bayesi
Page 163 and 164:
AUSM that will return the most prob
Page 165 and 166:
direct experimentation with a new s
Page 167 and 168:
Figure 7. An example of use of the
Page 169 and 170:
Cooper, J. & Herskovits, E. (1992).
Page 171 and 172:
Goldberg, A. K., & Riemer, F. J. (2
Page 173 and 174:
In addition to convenience, propone
Page 175 and 176: members increased flexibility. They
Page 177 and 178: Oppenheimer, T. (1997, July). The c
Page 179 and 180: The basis of reform in science educ
Page 181 and 182: technology and are not confident in
Page 183 and 184: participants that learning as a gro
Page 185 and 186: A hierarchy of Systems Identifying
Page 187 and 188: the change agents to recognize the
Page 189 and 190: Nonis, A. S., & O’Bannon, B. (200
Page 191 and 192: maintaining the interest levels of
Page 193 and 194: Focus group interviews with our stu
Page 195 and 196: course and again at the end of the
Page 197 and 198: second phase of valuing, commitment
Page 199 and 200: Kinzie, M. B., Whitaker, S. D., Nee
Page 201 and 202: Although this work is based on a st
Page 203 and 204: Website Design The MTP website (www
Page 205 and 206: Researchers, for review and coding
Page 207 and 208: quality that are the focus of the M
Page 209 and 210: Kelley, M. A., Whitaker, S. D., Nee
Page 211 and 212: or underserved populations. For exa
Page 213 and 214: 2004 Baruch College Computer Center
Page 215 and 216: professional-level tools and resour
Page 217 and 218: Third, with the exception of the Om
Page 219 and 220: Hepp, P., Hinostroza, E., Laval, E.
Page 221 and 222: The AccessForAll strategy complemen
Page 223 and 224: of people with special needs, or di
Page 225: (including where their search for r
Page 229 and 230: information will be expressed using
Page 231 and 232: DC Metadata Terms: http://dublincor
Page 233 and 234: Choquet, C., & Corbière, A. (2006)
Page 235 and 236: TEL Standards, Specifications and P
Page 237 and 238: The Resources Management Process ma
Page 239 and 240: Step 1: Instantiation of the enterp
Page 241 and 242: Step 5: Instantiation of the techno
Page 243 and 244: correlation of the different viewpo
Page 245 and 246: Hummel, H., Manderveld, J., Tatters
Page 247 and 248: Karagiannidis, C. (2006). Book revi
Page 249 and 250: Glenn, L. (2006). Book review: Visu
show all

October 2006 Volume 9 Number 4

Create successful ePaper yourself

Delete template?

Save as template?