Zusammenfassung:
In diesem Abschnitt werden die Elemente und Attribute des Metadatenstreifens ausführlich beschrieben und ihre Anwendung an einem Beispiel erläutert.
Die Metadaten eines Learning Objects werden in die Tags <Metadata> und </Metadata> eingeschlossen.
Das Inhaltsmodell des Elements <MetaData> besteht aus den folgenden Elementen:
Unser Inhaltsmodell ist damit in zweierlei Hinsicht restriktiver als der Standard:
Element <General>
Das Inhaltsmodell dieses Elements besteht aus den folgenden Elementen:
Eine Elementinstanz wird durch die folgenden Attribute identifiziert / charakterisiert:
Structure: Hier muss man angeben, wie die durch die Metadaten beschriebe Lehreinheit strukturiert ist. Der Standard gibt die Werte {Atomic, Collection , Linear , Hierarchical , Networked} vor und definiert das Attribut wie folgt: "Underlying organizational structure of this learning object". Da die Beschreibung des Standards nicht weiter hierzu hergibt, haben wir uns dafür entschieden, auch weil es der Sache entspricht, unsere Lehreinheiten als "Linear" zu charakterisieren und unsere Grafiken als "Atomic". Als "Collection" könnte man eine LE bezeichnen, wenn die Lektüre eines Teils nicht die Lektüre eines anderen Teils voraussetzt.
Aggregation Level: Ein obligatorisches Attribut, das sehr wichtig für die Strukturierung einer Lehreinheit ist. Es sind vier, numerisch aufsteigend gekennzeichnete Level (1-->4) zugelassen.
Level 1: Hiermit werden "atomare" Elemente gekennzeichnet, z.B. Bilder, Tondateien, aber auch einzelne Textstücke.
Level 2: Elemente dieses Levels entsprechen in etwa einer Seite, also der Menge von Text etc. die gleichzeitig von einem Browser dargestellt werden sollen. Das lom2html-Skript erzeugt aus dem Inhalt des <Description>-Elements eine "Zusammenfassung" der Seite am Kopf dieser Seite.
Level 3: Elemente dieses Levels fassen eine geordnete Menge von Seiten oder Seitenmengen zusammen. Das lom2html-Skript erzeugt eine Leitseite, an deren Kopf eine Zusammenfassung steht (erzeugt aus dem >Element <Description>) gefolgt von Verweisen auf die Level2- oder Level3-Objekte, die durch dieses Objekt gebündelt werden.
Level 4, laut Standard "the largest level of granularity, e.g. a set of courses that lead to a certificate" sollte in MiLCA nicht verwendet werden.
Um den Unterschied zwischen der logischen Gliederung einer Lehreinheit und dessen organisatorischen Gliederung zu veranschaulichen, gehen wir von einer Lerneinheit aus, die k Abschnitte umfasst. Jeder Abschnitt umfasst p Unterabschnitte, jeder Unterabschnitt q Unterunterabschnitte und jeder Unterunterabschnitt umfasst r Seiten.
Organisatorisch bilden die Abschnitte, Unterabschnitte und Unterunterabschnitte alle Level3-Objekte. Das heißt vor allem, dass Level3-Objekte in Level3-Objekte geschachtelt werden. Jeder Unterunterabschnitt enthält Level2-Objekte ("Seiten"). Natürlich kann auch ein Unterabschnitt statt Unterunterabschnitte direkt "Seiten" enthalten.
Element <Identifier>
Der Identifier ist nun (dies ist eine Änderung im Standard) ein selbständiges Element ohne Inhalt, aber mit Attributen.
Das Element hat die folgenden Attribute:
Das Attribut hat den Datentyp "ID", d.h. das dieses Element der "eigentliche" Identifier des Learning Object ist. Wir empfehlen, als "Entry"-Namen einen das Lehrmodul möglichst genau charakterisierenden, aber nicht zu langen String zu verwenden. Der Identifier fungiert zum einen als Schlüssel, darf also nicht mehrfach vergeben werden. Zum anderen erzeugt das Transformationsskript "lom2html" aus diesem Identifier den Namen für die Ergebnisdatei.
Element <Title>
Titel des Learning Objects. Das lom2html-Skript übernimmt den hier eingetragenen Text in das "TITLE"-Element im HEADER des HTML-Dokuments und setzt den Inhalt dieses Elements außerdem als Hauptüberschrift ( <h1>) an den Anfang des Textkörpers ("body"-Element).
Element <Language>
Hier wird die Sprache bzw. werden die Sprachen angegeben, in der / denen die Lehreinheit verfasst ist. Eine Liste der Sprachenkürzel nach ISO 639 befindet sich am Anfang der DTD.
Element <Description>
Die "Description" erfüllt die folgenden Funktionen. Bei Level1-Objekten liefert sie eine Beschreibung des Inhalts dieses Objekts (z.B. Abbildung eines Kehlkopfs; kurzes A, gesprochen von einem mänlichen Sprecher mit schwäbischem Akzent). Bei Level2/3- Objekten liefert "Description" eine Zusammenfassung des Inhalts und lässt sich am ehesten mit einer Zusammenfassung / einem Abstract vergleichen. Als solche werden sie auch durch das lom2html-Skript verarbeitet.
Element <Keyword>
Der Inhalt dieses Feldes ist am ehesten vergleichbar mit der Verschlagwortung von Objekten in Bibliotheken. Im Moment fehlt eine projektweite Vereinheitlichung von Schlagwortlisten. Jedes TP sollte deshalb die Verwendung von Schlagwörtern selber prüfen und konsistent halten. Bei ILIAS wird darüber nachgedacht, ob man beim entsprechenden Datenfeld die Auswahl aus einer Liste / mehreren Listen implementieren soll.
Element <Coverage>
Mir ist unklar, was damit gemeint sein könnte (und die Beschreibung im Standard zu kryptisch). Das Element ist deshalb optional und dessen Inhalt wird bei der Weiterverarbeitung der Daten nicht verwendet.
Element <Lifecycle>
"This category describes the history and current state of this learning object and those who have affected this learning object during its evolution." [IEEE, 1977]
Soweit ich das verstehe, ist diese Kategorie von Metadaten also zunächst vor allem für die BearbeiterInnen interessant, die Material aus anderen Quellen übernehmen und für MiLCA adaptieren. Bei Neuerstellung ist die bisherige Lebensdauer des Materials noch zu kurz. Hoffen wir aber mal, dass auch die neu erstellten Materialien einen langen und erfolgreichen "LifeCycle" haben werden.
Man beachte, dass dieses Element optional ist.
Das Inhaltsmodell dieses Elements ist:
Eine Elementinstanz wird durch die folgenden Attribute identifiziert / charakterisiert:
Der Standard sieht eine Menge von Statuswerten vor: Draft, Final, Revised, Unavailable. Die Werte dürften selbsterklärend sein. "Unavailable" dürfte die Einstellung für den Fall sein, dass ein Objekt gerade "ausgecheckt" und in Arbeit ist.
Element <Version>
Es ist schwer, etwas Sinnvolles einzutragen, wenn man nicht mit einem System arbeitet, das automatisch Versionen verwaltet. Wir schlagen vor, während der Erstellung eine Versionsnummer < 1 zu vergeben, Version 1.x während und nach dem ersten Einsatz des Materials u.s.w.
Element <Contribute>
Hier werden die Personen erwähnt, die bei der Erstellung und Überarbeitung des Objekts eine Rolle gespielt haben.
Das Inhaltsmodell dieses Elements ist:
Eine Elementinstanz wird durch die folgenden Attribute identifiziert / charakterisiert:
Der Standard sieht eine Menge von Rollen vor, in denen die genannte "Entity" am Erstellungs- und Überarbeitungsprozess beteiligt sein kann: {Author , Publisher , Unknown , Initiator , Terminator , Validator , Editor , GraphicalDesigner , TechnicalImplementer , ContentProvider , TechnicalValidator , EducationalValidator , ScriptWriter , InstructionalDesigner, SubjectMatterExpert, Creator, Validator}. Die meisten dieser Rollen dürften selbsterklärend sein. Insgesamt ergibt sich eine m:n-Beziehung. Eine "Entity" kann in mehreren Rollen am Prozess beteiligt sein und eine Rolle kann von mehreren "Entities" wahrgenommen werden. Man beachte, dass die lezten beiden Werte der Liste nur in Abschnitt 3 der Metadaten - Meta-Metadata - verwendet werden sollten.
Element <Entity>
In aller Regel wird diese Entity eine Person sein. Die Daten dieser Person können informell charakterisiert werden (als freies #PCDATA Feld) oder formeller in Form einer "Visitenkarten". Die MiLCA DTD verwendet hierfür den "vCard" Standard RFC2426, s. vcard-Spezifikation). Im Teilprojekt COLEX verwenden wir die vCard-Spezifikation, da die Daten ja nur einmal ausgefüllt werden und dann in jeden Metadaten-Streifen übernommen werden können.
Element <Date>
Ein "Datum".In der MiLCA DTD werden keine Formatvorgaben gemacht (= #PCDATA). D.h., dass auch Zeiträume der Beteiligung angegeben werden können ("Autor" --> September - Dezember 2002).
Element <Meta-Metadata>
In diesem Teil der Metadaten werden die Metadaten selber beschrieben. Zentrale Beschreibungsgröße ist der Standard, dem das Metadatenschema folgt. Außderdem kann die "Entitiy" spezifiziert werden, die die Metadaten erstellt hat
Das Inhaltsmodell dieses Elements ist:
Eine Elementinstanz wird durch die folgenden Attribute identifiziert / charakterisiert:
Durch das Attribut MetadataScheme wird das verwendete Schema für Metadaten spezifiziert. Bei uns ist das immer LOM. Dies ist als Wert auf voreingestellt.
Durch das Attribut Language wird die in den Metadaten verwendete Sprache angegeben.
Element <Identifier>
Der "Identifier" sollte den Metadatensatz eindeutig identifizieren. Das ist wichtig für den Fall, dass die Metadaten getrennt von den Inhaltsdaten verwaltet werden müssen (z.B. in einem Katalog). Man sollte deshalb einen Schlüssel wählen, bei dem die Gefahr, dass er bereits für andere Metadaten gewählt wurde, minimal ist. Er könnte z.B. aus der ID für die jeweilige LO abgeleitet werden.
Element <Contribute>
Inhaltsmodell >siehe oben.
Eine Elementinstanz wird durch die folgenden Attribute identifiziert / charakterisiert:
Der Standard sieht hier die Rollen "Creator" und "Validator" vor, die Namen dürften selbsterklärend sein, alle anderen Werte des Attributs werden für das "Contribute"-Element in Abschnitt 2 ("Life Cycle") verwendet.
Element <Technical>
Hier werden einige technische Charakteristika der des Objekts und technische Voraussetzungen für dessen Einsatz spezfiziert.
Das Inhaltsmodell dieses Elements ist:
Hinweis: "Requirement" und "OrComposite" bilden eine ODER-Verknüpfung, die insgesamt optional und nicht iterierend ist. Für eine einfache Bedingung wähle man "Requirement" für komplexe Bedingungen wähle man das "OrComposite" Element.
Eine Elementinstanz wird durch die folgenden Attribute identifiziert / charakterisiert:
Für das Format der Lehreinheit wird ein Wert aus einer Liste von "MIME-Types" (RFC 2048) ausgewählt. Bei Level1-Objekten ist das offensichtlich (z.B. image-jpeg). Bei Level2 und Level3-Objekten ist das keineswegs so offensichtlich, das diese ja aus einer Mischung von Datentypen bestehen (können). Wir geben hier immer text-xml an, da die Daten anderen Typs ja als Level1-Objekte eingebettet sind.
Element <Size>
In der MiLCA DTD ist das Eingabeformat frei (#PCDATA). Es erscheint sinnvoll, die Größe des Objekts in Bytes anzugeben (so sieht es der Standard vor). Diese Information ist wichtig bei großen Objekten (Videos, Soundfiles, aufwändige oder große Grafiken). Diese Angabe kann natürlich bei Level3-Objekten mit sehr vielen Teilen sehr aufwändig werden. Ein automatisiertes Verfahren für das Zusammenzählen wäre sinnvoll.
Element <OrComposite>
Das Inhaltsmodell dieses Elements ist recht einfach:
Element <Requirement>
An dieser Stelle können (Mindest)Anforderungen an das Betriebssystem und den Browser des Rechners formuliert werden, der zur Darstellung der Inhalte des beschriebenen Objekts verwendet wird
Das Inhaltsmodell dieses Elements ist:
Element <Type>
An dieser Stelle wird spezifiziert, worauf sich die genannten Anforderungen beziehen.
Das Inhaltsmodell dieses Elements ist:
Element <OperatingSystem>
Das Inhaltsmodell dieses Elements ist leer.
Eine Elementinstanz wird durch die folgenden Attribute identifiziert / charakterisiert:
Für das Attribut Name stellt der Standard die folgenden Werte zur Verfügung: {PC-DOS , MS-Windows , MacOS , Unix , Multi-OS , None}. Bei unseren Anwendungen, die keine weiteren BS-spezifischen Zusatzprogramme benötigen, nehmen wir den Wert "Multi-OS". Was "None" in diesem Zusammenhang bedeutet, weiß ich nicht.
Element <Browser>
Das Inhaltsmodell dieses Elements ist leer.
Eine Elementinstanz wird durch die folgenden Attribute identifiziert / charakterisiert:
Für das Attribut Name stellt der Standard die folgenden Werte zur VErfügung: Any, NetscapeCommunicator, Mozilla, MS-InternetExplorer, Opera, Amaya. Bei unseren Anwendungen, die keine weiteren BS-spezifischen Zusatzprogramme benötigen, nehmen wir den Wert "Any". Bei den Browsern dürfte die Spezifizierung der Minimalversion eine größere Bedeutung zukommen als bei den Betriebssystemen.
Element <Location>
An dieser Stelle muss die URL ("Repertoire of ISO/IEC 10646-1" [IEEE, 1977]) angegeben werden, unter der das Objekt erreichbar ist. Dies ist besonders wichtig bei Level1-Objekten. Im lom2html-Skript werden diese Objekte per "HREF" Anchor, der auf diese URL zeigt (bei Texten) oder mit dem <IMG>-Tag (bei Grafiken, SRC-Wert ist ein Verweis auf die URL) eingebunden. Das Eingabeformat ist frei (= #PCDATA)
Element <InstallationRemarks>
Hinweise darauf, wie das Learning Object zu installieren ist, wenn solches erforderlich sein sollte. Attribut: Language.
Element <OtherPlatformRequirements>
Informationen über Anforderungen an Hard- und Software, die über das Übliche hinausgehen (z.B. über benötigte Plugins). Attribut: Language.
Element <Duration>
"Time a continuous learning object takes when played at intended speed." [IEEE, 1977] Die ist interessant für Videos und Soundfiles. Die Eingabe ist bei uns "frei" (#PCDATA). Der Standard sieht allerdings vor, dass man sich an den Angabeformaten nach ISO 8601:2000 orientiert. Erläuterung zum Format: Bei der Definition einer Duration steht immer ein P voran. T steht für Time und kann nur weggelassen werden, wenn keine Angaben zu Stunden, Minuten und Sekunden gemacht werden (z. B. wenn Duration 2 Jahre ist). Also: PT2H10M30S bedeutet: 2 Stunden, 10 Minuten und 30 Sek. P3Y1M bedeutet 3 Jahre und 1 Monat. Generell können die Buchstaben Y,M,D weggelassen werden, wenn der korrespondierende Wert 0 ist.
Element <Educational>
In diesem Abschnitt der Metadaten werden die pädagogischen Merkmale des Objekts beschrieben.
Das Inhaltsmodell dieses Elements ist:
Eine Elementinstanz wird durch die folgenden Attribute identifiziert / charakterisiert:
Für den InteractivityType stellt der Standard die folgenden Werte zur Auswahl: {Active , Expositive , Mixed}. Bei expositiven Lerneinheiten dominiert der Informationsfluss von der Lehreinheit (und damit indirekt vom Lehrenden) zum Lernenden, die Rolle der Lernenden ist weitgehend auf das Lesen (und Verstehen) beschränkt. Bei aktiven Lehreinheiten fließt auch Information vom Lernenden zur Lehreinheit. Man kann hierbei (auch) durch Handeln lernen. Simulationen sind ein Beispiel für diesen Typ von Lehreinheit. Der Rest ist selbsterklärend.
Für den LearningResourceType stellt der Standard die folgenden Werte zur Auswahl: Exercise , Simulation, Questionnaire, Diagram, Figure, Graph, Index, Slide, Table, NarrativeText, Exam, Experiment, ProblemStatement, SelfAssessment, Lecture. Die Liste erscheint mir etwas willkürlich "zusammengewürfelt" zu sein. Wir haben die Lehreinheiten in COLEX als "Lecture" oder als "Exercise" markiert. Grafiken sollte man sinnvollerweise als "Figure" oder "Graph" kategorisieren. Ob ein Examen eine "Learning Resource" ist, ist zweifelhaft. Der Typ "Table" ist ebenso zweifelhaft. "SelfAssessment" und "Exercise" könnten sich überschneiden (wenn ich Übungen zur Selbstkontrolle zur Verfügung stelle). Ob wichtige Typen fehlen wird die zukünftige Anwendung zeigen.
Für den InteractivityLevel stellt der Standard die folgenden Werte zur Auswahl: VeryLow, Low, Medium, High, VeryHigh.
Für die SemanticDensity stellt der Standard die folgenden Werte zur Auswahl: VeryLow, Low, Medium, High, VeryHigh. Die Skala ist dubios, weil m.E. nicht operationalisierbar. (Die offizielle Definition: "Amount of information conveyed by this learning object as compared to its size or duration" [IEEE, 1977] ist dies jedenfalls nicht). Man wird bei einer Gruppe von Annotatoren selten völlige Übereinstimmung bei diesem Wert finden. Wenn es keine weiteren Kriterien gibt, dann läuft das auf eine schwammige Unterscheidung zwischen "leicht zu verstehen" und "schwer zu verstehen" hinaus. Dementsprechend sollte man bei der Kategorisierung, wenn man sie denn vornimmt, vor allem bedenken, an welches Publikum man sich richtet (eher an Anfänger in der Materie oder eher an Fortgeschrittene) und danach den Wert bestimmen.
Für die IntendedEndUserRole stellt der Standard die folgenden Werte zur Auswahl: Teacher, Author, Learner, Manager. In unserem Fall dürfte fast immer der Learner der End User sein, es sei denn man erstellt Handreichungen. Diese Handreichung etwa richtet sich in erster Linie an Autoren. Man sollte überlegen, ob man Mehrfachnennung zulässt.
Für das Attribut "Context" stellt der Standard die folgenden Werte zur Auswahl: School, HigherEducation, Training, Other. Es bleibt abzuwarten, ob der DIN Ausschuss hierfür eine Liste erstellt, die den deutschen Verhältnissen gerecht wird.
Für das Attribut "Difficulty" stellt der Standard die folgenden Werte zur Auswahl: VeryEasy, Easy, Medium, Difficult, VeryDifficult}. Auch für dieses Attribut gilt das oben für die "semantic density" Gesagte.
Element <TypicalAgeRange>
Alter der Adressaten. Die Eingabe in dieses Feld ist frei (= #PCDATA). Elementinstanzen werden durch das Attribut "language" charakterisiert. Warum das so ist weiss ich nicht. Ich bin für die Abschaffung dieses Attributs.
Element <TypicalLearningTime>
Dauer, die der Erwerb der Inhalte durchschnittlich erfordert. Die Eingabe in dieses Feld ist frei (= #PCDATA). Man kann hier bei wochengetakteten Kursen die Wochenzeit für das Durcharbeiten eines Moduls oder auch, und vielleicht besser, die geschätzte oder durchschnittliche Stundenzahl angeben. Wird letzterer Wert gewählt, dann ermöglicht man es anderen Lehrenden, die Quantität der Lehrmaterialien auf die den Lernenden zur Verfügung stehende Zeit abzustimmen, bei Semesterseminaren, Blockkursen etc.
Element <Description>
"Comments on how this learning object is to be used"" [IEEE, 1977]. Mir fällt im Moment keine sinnvolle Art von Kommentar zu den Bedingungen der Nutzung ein. Es sei nur darauf hingewiesen, dass die Nutzung im Zusammenhang mit anderen Lehreinheiten in Teil 7 der Metadaten ("Relations") beschrieben wird. Der "educational use" einer Lehreinheit sollte in Abschnitt 8 der Metadaten beschrieben bzw. kommentiert werden.
Element <Language>
"The human language used by the typical intended user of this learning object" [IEEE, 1977]
Element <Rights>
Hier werden die Rechte und die Lizenzierungsbedingungen für das Objekt beschrieben.
Das Inhaltsmodell dieses Elements ist:
Eine Elementinstanz wird durch die folgenden Attribute identifiziert / charakterisiert:
Der Wertebereich beider Attribute ist "Yes/No". Das heißt insbesondere, dass die Höhe der Kosten nicht benannt werden kann und dass die Art der Rechte nicht benannt werden kann. Hier könnte der Standard ausführlicher sein.
Element <Description>
"Comments on the conditions of use of this learning object." [IEEE, 1977] Also ein Notnagel, um die Art der Rechte doch noch beschreiben zu können. Hier könnte man z.B. darauf hinweisen, dass die Benutzung von einzelnen Modulen an die Bedingung geknüpft ist, dass die AutorInnen in einer festgelegten Weise genannt werden müssen.
Element <Relation>
Hier werden die Abhängigkeiten des beschriebenen Objekts von anderen Objekten beschrieben.
Das Inhaltsmodell dieses Elements ist:
Eine Elementinstanz wird durch die folgenden Attribute identifiziert / charakterisiert:
Der Standard stellt für dieses Attribut die folgenden Werte zur Verfügung: IsPartOf, HasPart, IsVersionOf, HasVersion, IsFormatOf, HasFormat, References, IsReferencedBy, IsBasedOn, IsBasisFor, Requires, IsRequiredBy. Einige der Werte sind sicher einfach zu verstehen und nützlich. Einige, wie die Beziehung verschiedener Versionen zueinander, sind mir in ihrer Funktion unklar. Das "Relation" Feature ist, wenn es wirklich konsequent genutzt wird, ein interessanter Mechanismus, um die Verlinkung der der zu einem Kurs gehörenden Module untereinander transparent zu machen.
Element <Resource>
Hier wird das Zielobjekt der "Relation" beschrieben.
Das Inhaltsmodell dieses Elements ist:
Element <Identifier_>
Das Inhaltsmodell dieses Elements ist leer.
Eine Elementinstanz wird durch die folgenden Attribute identifiziert / charakterisiert:
Vergleiche auch das Inhaltsmodell von >Identifier
Die Attribute eröffnen die Möglichkeit, die Zielressource sowohl über den internen ID-Mechanismus >s. oben zu identifizieren, als auch über ihren Ort auf einem Server zu lokalisieren. Ein entsprechendes Programm könnte, wenn die Daten konsequent angegeben werden, für ein Learning Object zugleich alle die Objekte lokalisieren und evtl. mitliefern, von denen das beschriebene Objekt abhängig ist.
Das Element <Description> erlaubt es, die Zielressource weiter zu charakterisieren.
Element <Annotation>
Hier können Hinweise zum Einsatz des Lehreinheit in der Lehre gegeben werden.
Das Inhaltsmodell dieses Elements ist:
Es können in diesen Elementen die kommentierende Person ("Entity")und das Datum des Kommentars sowie der Kommentar selber gegeben werden. An dieser Stelle können z.B. Erfahrungen aus dem eigenen Umgang mit einem Lehrmodul im Lehrbetrieb beschrieben werden.
Element <Classification>
Hier kann beschrieben werden, wo die Inhalte des zu beschreibenden Objekts innerhalb einer gegebenen Klassifikation zu verorten sind. Da wir bisher für unser Fach keine verbindliche Klassifikation haben, dürfte es schwierig sein, dieses Abschnitt auszufüllen.
Das Inhaltsmodell dieses Elements ist:
Eine Elementinstanz wird durch die folgenden Attribute identifiziert / charakterisiert:
Der Standard stellt folgende Werte für dieses Attribut zur Verfügung: Discipline , Idea , Prerequisite , EducationalObjective , AccessibilityRestrictions , EducationalLevel , SkillLevel , SecurityLevel, Competency. Es handelt sich um den Grund der Klassifikation. Mit den Werten selber kann ich wenig anfangen.
Element <TaxonPath>
Hier kann der Pfad angegeben werden, über den in der hierarchischen Taxonomie dieser Stelle erreicht wird, an der das Objekt eingeordnet wird.
Das Inhaltsmodell dieses Elements ist:
In "Source" wird der Name der Taxonomie angegeben.
Element <Taxon>
In Taxon wird der Name des Knotens angegeben, bei dem das zu beschreibende Objekt verortet werden soll.
Das Inhaltsmodell dieses Elements ist:
Eine Elementinstanz wird durch die folgenden Attribute identifiziert / charakterisiert:
Element <Entry>
Die Eingabe in dieses Feld ist frei (= #PCDATA). Attribut ist "Language".
Element <Keyword>
"These are the keywords and phrases descriptive of the learning object relative to the stated Classification." [IEEE, 1977] Was der Nutzen bzw. Mehrwert zusaätzlich zu der Angabe von Keywords in Abschnitt 1 der Metadaten (s. oben) sein soll, ist mir nicht klar.
Dieser Abschnitt gehört zwar noch zu den Metadaten, nicht aber zu der von LOM vorgegebenen Kategorienmenge. Grund der Einführung dieses Abschnitts ist die Harmonisierung mit der von ILIAS verwendeten DTD.
Element <LayoutInformation>
Dieses Element wird benötigt, um die Darstellung der Daten in der ILIAS Plattform zu steuern.
Das Inhaltsmodell dieses Elements ist leer.
Eine Elementinstanz wird durch die folgenden Attribute identifiziert / charakterisiert:
Die Werte der ersten Attribute sind "Yes/No". Über diese Abttribute wird gesteuert, ob zwei unmittelbar aufeinander folgende Bilder nebeneinander oder untereinander dargestellt werden (yes = nebeneinander). Das dritte Attribut sollte einen Verweis auf ein CSS-Stylesheet enthalten (Typ: CDATA). Das MiLCA-Lieferpaket umfasst eine CSS-Stylesheet, das auf einem Server platziert und in den Objektdateien über dieses Attribut referenziert werden kann.
"VerticalAlign" kann die Werte: Top, Middle, Bottom annehmen. "HorizonalAlign" kann die Werte: Left, Center, Right annehmen. TargetFrame kann die Werte: Media, FAQ, Glossary annehmen. Die Angaben sind ILIAS-spezifisch.
>>