Difference between revisions of "ApplicationProfiles/EvaluierungElanKurz"

From MPDLMediaWiki
Jump to navigation Jump to search
 
(6 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= ELAN Application Profile =
= ELAN Application Profile =


"ELAN Application Profile", Version 1.0, bietet in "minimales Kernset an Metadaten" an, um Lehr- und Lernmaterialien an niedersächsischen Hochschulen zu beschreiben, damit sie durch eine metadatenbasierte Suche im Portal des eLearning Academic Network Niedersachsen (ELAN) besser gefunden werden.
"ELAN Application Profile", Version 1.0, bietet ein "minimales Kernset an Metadaten" an, um Lehr- und Lernmaterialien an niedersächsischen Hochschulen zu beschreiben, damit sie durch eine metadatenbasierte Suche im Portal des eLearning Academic Network Niedersachsen (ELAN) besser gefunden werden.


"ELAN Application Profile: Metadaten für elektronische Lehr- und Lernmaterialien", Version 1.0, wurde von zwei Arbeitsgruppen -- der AG "Metadaten für Multimedia-Objekte" der Deutschen Initiative für Netzwerkinformation e.V. (DINI) und der AG "Metadaten" des eLearning Academic Network Niedersachsen (ELAN) -- entwickelt und Oktober 2005 in der Reihe DINI-Schriften veröffentlicht.
== Zielgruppe, Anforderungen, Nutzungsszenarien ==


Der Profil bietet ein "minimales Kernset an Metadaten", um Lehr- und Lernmaterialien im Hochschulbereich zu beschreiben, damit heterogene Ressourcen, die über mehrere Hochschulen landesweit verteilt sind, durch eine Metadatenbasierte Suche in einem zentralen ELAN-Portal abgerufen werden.  Je nach lokalen Verhältnissen kann der Profil als Ziel für die automatische Konvertierung bereits existierender Metadaten dienen oder durch Studierende, Lehrende und Aminidstration für die Beschreibung eigener Ressourcen eingesetzt werden.  Die frühe Verständigung auf diese minimalen Standards soll längerfristig die Integration der Metadaten über Lehr- und Lernmaterialien mit Bibliothekskatalogen und mit E-Learning Angeboten auf nationaler und internationaler Eben erleichtern.
Die Metadaten im Portal sollen Studierenden und Lehrenden an den Hochschulen sowie deren Administration helfen, sich über virtuelle Lehrveranstaltungen oder die Verfügbarkeit von eLearning-Materialien zu bestimmten Themen zu informieren.  "ELAN Application Profile" spezifiziert zugleich ein Zielformat für die automatische Konvertierung bereits existierender Metadaten und die Basis für verteilt verfasste Kurzbeschreibungen.  Der Einsatz internationaler Standards im Metadatenprofil soll längerfristig die Integration der Metadaten mit Bibliothekskatalogen und mit eLearning Angeboten auf nationaler und internationaler Ebene erleichtern.


== Zielgruppe ==
Zielgruppe: Studierende (virtuelle Seminare oder Lernmaterialien zu finden), Universitätsverwaltung (Verfügbarkeit virtueller Angebote zu überblicken), Lehrende (Verfügbarkeit digitaler Lehrmaterialien in bestimmten Bereichen.
"Um diesen Content möglichst einheitlich mit bibliographischen
und anderen Metadaten beschreiben und in die lokalen
Bibliothekskataloge importieren zu können, ist ein
einheitliches und standardisiertes Metadatenmodell, das ELAN
Application Profile, entwickelt worden."
== Funktionelle Anforderungen ==
Who is developing?
== Modell der beschriebenen Entitäten ==
== Modell der beschriebenen Entitäten ==


Ja, Entitäten sind E-Learning-Kurs und E-Learning-Content
Zwei Entitäten werden in den Metadaten beschrieben: E-Learning Kurse (Lehrveranstaltungen wie Seminare, Vorlesungen u.a.) und E-Learning-Content (Materialien wie Visualisierungen, Bilder, Videos, Skripte und Übungszettel).   
Detailliert beschrieben auf Seite 10 in Kapitel 5
Allgemein Kapitel 3, letzter Absatz, S. 7: E-Learning-Materialien, Ebene Kurs, Ebene Content.
[Baker]
Zwei Entitäten werden beschrieben:
-- E-Learning Kurse (die Dozent, Zielgruppe, ECTS-Punkte, Kursdauer... haben)
-- E-Learning Content (Materialien wie Visualisierungen, Bilder, Videos,  
    Skripte, Übungszettel...)
Die zwei Entitäten können einen präsizen Bezug zueinander haben:
-- E-Learning Kurs    "enthält"      E-Learning Content
-- E-Learning Content  "ist-Teil-von"  E-Learning Kurs
Diese Beziehungen sollen mit URIs präsize identifiziert werden.
Es ist jedoch eine andere Frage, ob die Beschreibungen von Kurse und
Content im gleichen Beschreibungssatz untergebracht werden müssen.
"Im gleichen Beschreibungssatz untergebracht" hieße, man wollte die
zwei Entitäten im gleichen "Record" beschreiben.
Im ELAN-AP scheint es vielmehr der Fall zu sein, daß man entweder
eine Beschreibung von einem Kurs oder eine Beschreibung von Content
machen will.  Wenn das der Fall ist, dann handelt es sich hier um
zwei Beschreibungssätze mit jeweils einer Beschreibung -- nicht um
einen Beschreibungssatz mit zwei Beschreibungen.
Dieser Review geht davon aus, daß "ELAN Application Profile"
eigentlich zwei Beschreibungssatzprofile enthält.  In den
folgenden Abschnitten werden diese Beschreibungssatzprofile
einzeln evaluiert.
 
== Beschreibungssatzprofil: "E-Learning Kurs" ==
 
=== Extern definierte Terme ===
 
DCAM-Konformität: Die externen Terme sind nicht DCAM-konform, es fehlen Angaben zu URIs.   
Beschreibung: Definition und Beschaffenheit sind für alle Terme beschrieben; URIs sind angegeben.
Semantik: Ja
Anmerkung: Hier wird davon ausgegangen, dass unter "DCAM-Konformität" geprüft werden soll, ob die Terme im vorliegenden AP
DCAM-konform definiert sind und unter "Beschreibung" geprüft wird, ob die Terme in den Vokabularen, aus denen sie stammen,
adäquat beschrieben sind.
 
=== Profilspezifische Terme ===
 
Prüfung profilspezifischer Terme (Baker, Haslhofer)
Allgemeine Bemerkungen
----------------------
Die Eigenschaften im ELAN-Profil werden nirgendwo explizit als
Eigenschaften bezeichnet und sind nicht mit URIs identifiziert.
In diesem Sinne sind diese Terme also nicht DCAM-konform.
Im Falle der verwendeten Eigenschaften aus DC Version 1.1
(Type, Subject...), ließen sich URIs nachträglich spezifizieren
und auch die Tatsache, daß es sich um "Eigenschaften" handelt.
Für die profilspezifischen Eigenschaften fehlt aber ein URI
für ELAN Metadata Terms und, wie unten erläutert wird, es  ist
in manchen Fällen unklar, ob es sich eigentlich um Eigenschaften
oder Vocabulary Encoding Schemes handelt.
Einzelne Terme
--------------
Folgende profilspezifische Eigenschaften kommen in den zwei
Beschreibungssatzprofilen vor:
-- ELAN-Klassifikation
    -- Zitiert in den Statement Templates auf Seiten 16, 31
    -- Die Frage der Anwendung von Wertevokabularen wird auf
      Seite 44 diskutiert
    -- Die Eigenschaft wird implizit als rdfs:subPropertyOf
      dc:subject bezeichnet
    -- Unter "Defined by" steht: "ELAN Metadata Terms".
      Man kann das als vermeintlichen Namensraum auffassen,
      etwa http://elan.org/terms/ bzw.
      http://elan.org/terms/elanClass.
-- ELAN-Dokumenttyp
    -- Zitiert im Statement Template auf Seite 20
    -- Wertevokabular (Zeichenketten als Value String) Seite 43-44 aufgelistet
    -- Label: "typeelancontrol1 und typeelancontrol2"
    -- "Defined by" sagt: "Dublin Core 1.1 (DC.Type) bzw. ELAN Metadata
      Terms (ElanControl1, ElanControl2)".  Das sind drei
      Eigenschaften.  Wird hier beabsichtigt, daß diese
      drei Eigenschaften (dc:type, elan:elanControl1, und
      elan:elanControl2) separat in den Metadaten (d.h. in
      drei separaten Statement Templates) verwendet werden?
      Oder sind die zwei kontrollierten Werte-Listen auf Seiten
      43-44 eigentlich als Vocabulary Encoding Schemes gemeint
      (d.h., elan:ElanControl1 und elan:ElanControl2), die ggf.
      mit dc:type verwendet werden?  Beide Variante sind möglich.
-- Zielgruppe
    -- Zitiert in den Statement Templates auf Seiten 24, 37
    -- Drei Wertevokabulare (Zeichenketten als Value Strings?) werden
      auf Seiten 45-46 aufgelistet: Audience.Target, Audience.Degree,
      Audience.Structure.  Wie im Falle "ELAN-Dokumenttyp" ist es
      nicht klar, ob es sich um drei vermeintlichen Eigenschaften
      (elan:audienceTarget, elan:audienceDegree, elan:audienceStructure)
      handeln soll, oder eher drei Vocabulary Encoding Schemes
      (elan:AudienceTarget, elan:AudienceDegree, elan:AudienceStructure),
      die in Zusammenhang mit dcterms:audience verwendet werden sollen.
      Wie im anderen Fall würde die Vergabe von URIs und eine eindeutige
      Zuordnung dem Term-Typ Klarheit verschaffen.
      Wenn man die Eigenschaft dcterms:audience näher
      betrachtet [1], stellt man jedoch fest, daß
      dcterms:audience den Range dcterms:AgentClass hat.
      dcterms:AgentClass definiert sich wie folgt: "A group of
      agents.  Examples of Agent Class include groups seen as
      classes, such as students, women, charities, lecturers."
      Vergleicht man diese Definition mit den Entitäten der drei
      kontrollierten Vokabulare, stellt man fest, daß AudienceTarget
      richtig ist (Schüler, Studierende...), die anderen zwei jedoch
      möglicherweise semantisch außerhalb der Definition liegen.
 
      Bei Audience.Degree hat man "Bachelor, Diplom...".
      Falls sie semantisch als "Bachelor-Studierende,
      Diplom-Studierende..."  aufzufassen sind, dann handelt
      es sich wirklich um Werte, die unter dcterms:AgentClass
      zu verstehen sind.  Falls die akademischen Titel jedoch
      selber gemeint sind, dann könnte man sie nicht als
      Instanzen der Klasse dcterms:AgentClass verstehen und
      die Vocabulary Encoding Scheme elan:AudienceDegree
      wäre nicht geeignet, in Verbindung mit dcterms:Audience
      verwendet zu werden.  Falls dcterms:audienceDegree jedoch
      als separate Eigenschaft gemeint ist, dann könnte man
      möglicherweise eine solche Eigenschaft definieren,
      aber man täte vielleicht besser, einen anderen Namen
      dafür zu wählen und die Eigenschaft wäre keine richtige
      rdfs:subPropertyOf dcterms:audience.
      Bei Audience.Structure geht es genauso wie mit
      Audience.Degree -- "Aufbaustudium" wäre als "Personen,
      die ein Aufbaustudium absolvieren" aufzufassen.
      Dabei muß bemerkt werden, daß diese Zweideutigkeit
      oder Mißverständnis der Semantik von dcterms:audience
      auch in anderen Anwendungsprofilen vorkommt - es ist
      ein häufiger Fehler.
-- ECTS-Punkte
-- Version
-- Voraussetzungen
-- Systemvoraussetzungen
    -- Zitiert in den Statement Templates auf Seite 24, 25, 28, 38
    -- Sind vermutlich Eigenschaften - sonst unproblematisch.
 
Sonstige Bemerkungen (außerhalb der Konformitätsprüfung an sich)
----------------------------------------------------------------
Im Statement Template wird in den "Best Practice" Guidelines
empfohlen, die Anzahl der ECTS Punkte in Form von String-Literalen
(z.B.: "7.5 ECTS-Punkte") anzugeben. Falls dies wirklich so gewünscht
ist, könnte dies ein zukünftige Maschinenverarbeitbarkeit (z.B.:
Berechnung der ECTS Punkte mehrere Module eines Studiengangs) deutlich
erschweren. Die Verwendung numerisch-typisierter Literale (z.B.:
"7.5^xsd:float) könnte dieses Problem lösen. Ansonsten wird empfohlen,
die Guidelines entsprechend anzupassen.
Für Versionsnummern gilt das gleiche wie für ECTS-Punkte. Werden
Versionen mit Value-Strings, z.B. der Form "Version 4.0", ausgedrückt,
erschwert dies die Maschinenverarbeitbarkeit.
[1] http://dublincore.org/documents/dcmi-terms/#audience
[2] http://dublincore.org/documents/dcmi-terms/#classes-AgentClass
 
=== Extern definierte Wertevokabulare und Kodierungsschemas ===
 
[Traugotts Kommentar]
*Datum:
-------
Fuer die Datum-bezogenen Eigenschaften wird das syntax
encoding scheme W3CDTF benutzt, das ein Profil von ISO 8601
ist. Es wird auch fuer "Kursdauer" benutzt, obwohl das Profil
keine Angaben zum Ausdruecken einer Zeitperiode macht.
*Herausgebende Einrichtung:
---------------------------
Bei dieser Eigenschaft wird zwar kein encoding scheme angegeben,
unter Mapping zu Pica aber die Gemeinsame
Koerperschaftsdatei (GKD) erwaehnt.
*Klassifikation (optionale Eigenschaft):
----------------------------------------
Die Ausfuehrungen zu ELAN-Klassifikation gelten entsprechend.
Name: Auch diese Klassifikationsangaben gehoeren semantisch
unter DC Subject, auch wenn hier andere Schemata genutzt
werden. Wie unten gezeigt, soll es nicht fuer jedes Schema
ein eigenes Label geben.  Defined by: Fuer ACM und die
meisten anderen Schemata gibt es keine eigene Terms. Der Text
kuendigt ELAN Metadata Terms dafuer an, was aber nirgends,
weder in diesem Anwendungsprofil noch in einer eigenen
Webseite bzw. einem RDF Schema, niedergelegt ist.
MeSH ist ein Subject Heading System, keine Klassifikation.
Die Texte von Definition und Comment unterscheiden sich nicht inhaltlich.
Wie sollen diese Klassifikationen fuer die Funktionalitaeten gemeinsamer
Suche, Ranking, Filtern, Sortieren, 
Eingrenzen (S.7) genutzt werden, wenn sie isoliert nebeneinander stehen
und dem Nutzer auch unklar ist, 
wieviele und welche Objekte mit jedem System abgedeckt sind?
*Schlagwort:
-------------
Welche Schlagworte werden von den lokalen Partnern benutzt?
Koennte es eine geeignete Liste geben?
*Identifizierung:
URI, DOI, URN, DOI etc.
*Sprache: ISO 639-2
*Nutzungsbedingungen: CC, andere?
Alle schemes fuer die drei Eigenschaften sind acceptable Loesungen.
 
=== Profilspezifische Wertevokabulare und Kodierungsschemas ===
 
[Review Keßler, Koch hier.]
Review Keßler:
DCAM-Konformität der profilspezifischen Vokabulare:
Die Vokabulare zu "ELAN-Dokumenttyp" und "Zielgruppe"
sind nicht DCAM konform, es fehlen Angaben zu URIs. Für
"ELAN-Klassifikation" liegt bisher kein kontrolliertes
Vokabular vor, daher nicht prüfbar.
adäquate Beschreibung der profilspezifischen Vokabulare:
Die Deskriptoren sind nicht näher beschrieben oder definiert.
 
[Kommentare von Traugott hauptsaechlich zum zweiten Kriterium]:
[starke Ueberlappung mit den Kommentaren unter Kurs:profilspezifische Terme]
* ELAN-Klassifikation (S. 16):
------------------------------
Eigenschaftsname sollte (DC) Subject sein, wg. der Interoperabilitaet
mit anderen Subject Angaben.
Uebrigens ist Name und Label durchgehend vertauscht,
verglichen mit einer standardisierten Anwendung.
Das ELAN Schema hat kein URI.
Definition: Studienfaecher-Klassifikation
Die ELAN-Klassifikation existierte nicht zum Zeitpunkt der
Erstellung des Beschreibungssatzprofils.
 
Ist sie in der Zwischenzeit geschaffen worden?
In 5.3.2 werden zwar verschiedene Alternativen (und
ihre Nachteile) beschrieben, wenn auch bei weitem nicht
erschoepfend (CRIS, Schwedische, Hollaendische, Englische
usw.), doch ohne speziellen Bezug auf die funktionalen
Anforderungen, besonders die Arten der Nutzung und
moeglichen Nachnutzung. Es bleibt sogar unklar, ob nicht eine
existierende externe Klassifikation (z.B. Variante von DDC)
genutzt werden wird.
Das Profil ist fuer eine zentrale (S. 47), spaeter gar
internationale (S. 6 ?) Recherche entwickelt worden.  Darauf,
was sich daraus fuer die Wahl eines vocabulary encoding
schemes ergibt und auf die methodische Frage, ob lokale
Klassifikationsangaben ignoriert, uebernommen (welche werden
von den Partnern benutzt?) oder auf das neue kontrollierte
Vokabular gemappt werden sollen, wird nicht eingegangen.
Best practice: es fehlen Angaben zu Klassifikationsregeln,
z.B. wieviele verschiedene Klassifikationen fuer einen  Kurs
empfohlen werden.
 
* ELAN-Dokumenttyp:
-------------------
Name: sollte DC Type sein, wegen moeglicher Interoperabilitaet.
 
Label: control1 bzw. 2 sind nichtssagende Labels. Das
Label der Eigenschaft sollte nicht mit dem des Vokabulars
uebereinstimmen.
 
Die Schemata haben weder URI's noch Definitionen.
 
Definition: ist eine Tautologie. In der Definition
bleibt unklar, was der/die "Dokumenttyp/en" eines Kurses
ist/sind. Dokumente wuerde man als Teile des Content erwarten,
wo gar keine Typ Eigenschaft vorkommt (nur Format)!
Best practice: Regeln ueber die Kombination der zwei Vokabulare fehlen.
Da zwei verschiedene Vokabulare angeboten werden,
bleiben Angaben zur Obligation und Repeatability unklar.
Ist Control1 mandatory, Control2 recommended, oder eins von
beiden mandatory? Welche Vokabulare koennen wiederholt werden
(die Konzepte von Control2 schliessen sich gegenseitig
aus, waehrend das bei Control1, auf einen Kurs bezogen,
nicht der Fall ist.  Fuer die Dokumentation im A.P. ist zu
empfehlen, zwei verschiedene Blocks fuer die Eigenschaft
(Kurs)-Type zu erstellen, mit je eigenem Vokabularsystem und
Regeln. (vgl. auch die Diskussion unter Kurs:profilspezifische
Terme)
 
* Zielgruppe:
-------------
Label: Label (eigentlich: Name) soll ein einziger Term sein,
der im Metadatensatz die Eigenschaft eindeutig bezeichnet. Das
muss in englischer Sprache geschehen und unter Nutzung des
standardisierten Terms, der als einziger das Zusammenfuehren
unterschiedlicher Daten unter einer interoperablen Eigenschaft
(z. B. DC Type oder DC Title) bewerkstelligen kann. Die
Tatsache, dass mehrere Vokabulare fuer die Werte dieser
Eigenschaft benutzt werden, hat dabei keine Bedeutung. Der
Schemaname benutzter Vokabularsysteme wird in Metadaten an
anderer Stelle angegeben (unter http z.B. als scheme=).
 
Name: semantisch ist der Inhalt dieser Eigenschaft mit
DC Audience equivalent und sollte diesen Namen tragen.
Die Schemata haben weder URI's noch Definitionen.  Fuer best
practice, obligation, repeatability gelten die gleichen
Kommentare wie oben unter ELAN-Dokumenttyp.  Hier ist eher zu
empfehlen, drei Eigenschaften (subelements von DC Audience)
zu schaffen, mit je eigenem Vokabular und Regeln. (vgl. auch
die Diskussion unter Kurs:profilspezifische Terme)
 
In 5.3.3 wird nicht beschrieben, in welchem Aussmass
existierendes Vokabular benutzt wurde, was sehr zu empfehlen
waere wg. Interoperabilitaet auf allen Ebenen (zukuenftigem
Mapping).  Zu jedem Vokabular waere herauszufinden, ob
die Kategorien erschoepfend sind und sich gegenseitig
ausschliessen (was u.a. unterschiedliche Regeln zur Folge
haette).
 
== Beschreibungssatzprofil: "E-Learning Content" ==
 
=== Extern definierte Terme ===
 
Review Keßler:
DCAM-Konformität: Die externen Terme sind nicht DCAM-konform, es fehlen Angaben zu URIs. 
Beschreibung: Definition und Beschaffenheit sind für alle Terme beschrieben; URIs sind nicht angegeben.
Semantik: Ja


=== Profilspezifische Terme ===
== Die Beschreibungen ==


  [Siehe oben.]
Kurse und Content werden jeweils mit etwa zwanzig Eigenschaften beschrieben. Für den Großteil dieser Eigenschaften werden Standards wie Dublin Core wiederverwendet. Allerdings werden die Eigenschaften im ELAN-AP nicht mit ihren URIs explizit angegeben. Einige profilspezifische Terme werden verwendet (z.B. "ECTS-Punkte"), jedoch auch nicht mit URI und ohne eine explizite Bezeichnung als "Eigenschaft" oder "Codierungsschema", was an manchen Stellen zur Zweideutigkeit des Modells führt.


=== Extern definierte Wertevokabulare und Kodierungsschemas ===
Kurse und Content sollen anscheinend mit separaten Metadatensätzen beschrieben werden.  In diesem Sinn beinhaltet "ELAN Application Profile" eigentlich zwei verwandte Anwendungsprofile.  Kurse und Content können jedoch aufeinander bezogen werden: ein Kurs kann Content enthalten, und Content kann Teil von einem Kurs sein. Die Beziehung zwischen Kurs und Content wird über die Eigenschaften "Relation Enthält" und "Relation ist Teil von" hergestellt. Beide Eigenschaften sind verpflichtend. Somit ist es nicht möglich, Kurse ohne Beziehung zu einem Content zu beschreiben und vice versa. Dieser Sachverhalt wird allerdings nicht explizit benannt, sondern ergibt sich implizit aus der Obligation der beiden Eigenschaften.


*Datum, Format, Identifizierung, Sprache  und Schlagwort wie unter Kurs (s. oben) geloest.
== Kontext ==
*Klassifikation (externe) und Herausgebende Einrichtung kommen beim Content nicht als Eigenschaft zur Verwendung.


=== Profilspezifische Wertevokabulare und Kodierungsschemas ===
"ELAN Application Profile: Metadaten für elektronische Lehr- und Lernmaterialien", Version 1.0, wurde gemeinsam von zwei Arbeitsgruppen -- der AG "Metadaten für Multimedia-Objekte" der Deutschen Initiative für Netzwerkinformation e.V. (DINI) und der AG "Metadaten" des eLearning Academic Network Niedersachsen (ELAN) -- entwickelt und Oktober 2005 in der Reihe DINI-Schriften veröffentlicht.


Review Keßler:
== Ergebnis der Evaluierung ==
DCAM-Konformität: Für "ELAN-Klassifikation" nicht prüfbar, da
bisher keine eindeutigen Empfehlungen für ein Vokabularsystem
gegeben werden. Für Term "Zielgruppe" liegt keine Angabe eines
URIs vor.  adäquate Beschreibung: Es liegt keine adäquate
Beschreibung der Vokabulare für "ELAN-Klassifikation" vor, da
bisher keine eindeutigen Empfehlungen für ein Vokabularsystem
gegeben werden. Für "Zielgruppe" werden die Descriptoren
nicht näher definiert oder beschrieben.


[Traugotts Kommentar zum zweiten Kriterium]
"ELAN Application Profile" konnte wie vorgelegt nicht zertifiziert werden weil:
*ELAN-Klassifikation (S. 31):
-----------------------------
Die ELAN Klassifikation lag zum Zeitpunkt der Erstellung des
Profils noch nicht vor. Es bleibt etwas unklar, ob das die
gleiche Klassifikation sein soll, die auch fuer die Kurse
Verwendung findet. Es ist aeusserst zweifelhaft, ob die
gleiche Studienfach-Klassifikation sowohl die inhaltlichen
Schwerpunkte eines ganzen Kurses, als auch die einzelner
Content-Objekte sinnvoll beschreiben kann; ueber die
Relation zwischen Kurs-Beschreibung und Content-Objekten
werden ja die gleichen Klassifikationen vererbt (wie
funktioniert das genau, wenn ein Content Objekt mehreren
Kursen zugeordnet werden kann, S. 36?). Inwieweit es Sinn
macht, einzelne Visualisierungen, Bilder, Simulationen usw.,
die unabhaegig von Kursen stehen, auch nur ueber eine grobe
Studienfach-Klassifikation zu erschliessen, darf stark
bezweifelt werden.


*Zielgruppe:
* die verwendeten Eigenschaften nicht mit URIs identifiziert und als "Eigenschaften" bezeichnet werden, was an manchen Stellen zu Zweideutigkeiten im Modell führt,
------------
* profilspezifische Terme nicht explizit deklariert werden,
Wie unter Kurs (s.o.). Ob das gleiche Vokabular fuer isolierte
* die Modellierung und Semantik einiger Beschreibungselemente an manchen Stellen unklar ist.
Objekte, die keinem Kurs zugehoeren, Sinn macht, muesste
genauer durchdacht werden. Dann ist diese Eigenschaft
gar obligatorisch. Ueber eine eventuelle Vererbung von
kursbezogenene Angaben an alle zugehoerigen Content-Objekte
wird nichts ausgesagt.


== Sonstige Kommentare ==
[[Category:Application Profiles|Evaluierung Elan Kurz]]
[Rühle, Frodl, Hörmann]
Seite 10: "Kurs und Content werden über die Metadatenelemente
"Relation Enthält Content" und Relation ist Teil von Kurs"
miteinander verknüpft. - Ist dies Teil der funktionellen
Anforderungen oder Teil des Datenmodells?
Seite 44: Begriffe / Werte auch als Entitäten ansehbar? Wo
fängt die Entität an und wo hört sie auf?

Latest revision as of 10:00, 5 January 2011

ELAN Application Profile[edit]

"ELAN Application Profile", Version 1.0, bietet ein "minimales Kernset an Metadaten" an, um Lehr- und Lernmaterialien an niedersächsischen Hochschulen zu beschreiben, damit sie durch eine metadatenbasierte Suche im Portal des eLearning Academic Network Niedersachsen (ELAN) besser gefunden werden.

Zielgruppe, Anforderungen, Nutzungsszenarien[edit]

Die Metadaten im Portal sollen Studierenden und Lehrenden an den Hochschulen sowie deren Administration helfen, sich über virtuelle Lehrveranstaltungen oder die Verfügbarkeit von eLearning-Materialien zu bestimmten Themen zu informieren. "ELAN Application Profile" spezifiziert zugleich ein Zielformat für die automatische Konvertierung bereits existierender Metadaten und die Basis für verteilt verfasste Kurzbeschreibungen. Der Einsatz internationaler Standards im Metadatenprofil soll längerfristig die Integration der Metadaten mit Bibliothekskatalogen und mit eLearning Angeboten auf nationaler und internationaler Ebene erleichtern.

Modell der beschriebenen Entitäten[edit]

Zwei Entitäten werden in den Metadaten beschrieben: E-Learning Kurse (Lehrveranstaltungen wie Seminare, Vorlesungen u.a.) und E-Learning-Content (Materialien wie Visualisierungen, Bilder, Videos, Skripte und Übungszettel).

Die Beschreibungen[edit]

Kurse und Content werden jeweils mit etwa zwanzig Eigenschaften beschrieben. Für den Großteil dieser Eigenschaften werden Standards wie Dublin Core wiederverwendet. Allerdings werden die Eigenschaften im ELAN-AP nicht mit ihren URIs explizit angegeben. Einige profilspezifische Terme werden verwendet (z.B. "ECTS-Punkte"), jedoch auch nicht mit URI und ohne eine explizite Bezeichnung als "Eigenschaft" oder "Codierungsschema", was an manchen Stellen zur Zweideutigkeit des Modells führt.

Kurse und Content sollen anscheinend mit separaten Metadatensätzen beschrieben werden. In diesem Sinn beinhaltet "ELAN Application Profile" eigentlich zwei verwandte Anwendungsprofile. Kurse und Content können jedoch aufeinander bezogen werden: ein Kurs kann Content enthalten, und Content kann Teil von einem Kurs sein. Die Beziehung zwischen Kurs und Content wird über die Eigenschaften "Relation Enthält" und "Relation ist Teil von" hergestellt. Beide Eigenschaften sind verpflichtend. Somit ist es nicht möglich, Kurse ohne Beziehung zu einem Content zu beschreiben und vice versa. Dieser Sachverhalt wird allerdings nicht explizit benannt, sondern ergibt sich implizit aus der Obligation der beiden Eigenschaften.

Kontext[edit]

"ELAN Application Profile: Metadaten für elektronische Lehr- und Lernmaterialien", Version 1.0, wurde gemeinsam von zwei Arbeitsgruppen -- der AG "Metadaten für Multimedia-Objekte" der Deutschen Initiative für Netzwerkinformation e.V. (DINI) und der AG "Metadaten" des eLearning Academic Network Niedersachsen (ELAN) -- entwickelt und Oktober 2005 in der Reihe DINI-Schriften veröffentlicht.

Ergebnis der Evaluierung[edit]

"ELAN Application Profile" konnte wie vorgelegt nicht zertifiziert werden weil:

  • die verwendeten Eigenschaften nicht mit URIs identifiziert und als "Eigenschaften" bezeichnet werden, was an manchen Stellen zu Zweideutigkeiten im Modell führt,
  • profilspezifische Terme nicht explizit deklariert werden,
  • die Modellierung und Semantik einiger Beschreibungselemente an manchen Stellen unklar ist.

Application Profile

Uniform Resource Identifier

Arbeitsgruppe

Deutschen Initiative für Netzwerkinformation

Retrieved from "https://colab.mpdl.mpg.de/mw010/index.php?title=ApplicationProfiles/EvaluierungElanKurz&oldid=57807"