Difference between revisions of "ApplicationProfiles/EvaluierungElanKurz"
Jump to navigation
Jump to search
| Line 57: | Line 57: | ||
== Beschreibungssatzprofil: "E-Learning Kurs" == | == Beschreibungssatzprofil: "E-Learning Kurs" == | ||
=== Beschreibungen der Entitäten des Domain Models === | |||
=== Aussagen über die jeweiligen Entitäten === | |||
=== Einschränkungen === | |||
=== Verwendete Terme === | |||
=== Extern definierte Terme === | === Extern definierte Terme === | ||
Revision as of 13:21, 29 June 2008
ELAN Application Profile[edit]
"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: 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.
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.
Zielgruppe[edit]
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[edit]
Who is developing?
Modell der beschriebenen Entitäten[edit]
Ja, Entitäten sind E-Learning-Kurs und E-Learning-Content
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"[edit]
Beschreibungen der Entitäten des Domain Models[edit]
Aussagen über die jeweiligen Entitäten[edit]
Einschränkungen[edit]
Verwendete Terme[edit]
Extern definierte Terme[edit]
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[edit]
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[edit]
[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[edit]
[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"[edit]
Extern definierte Terme[edit]
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[edit]
[Siehe oben.]
Extern definierte Wertevokabulare und Kodierungsschemas[edit]
*Datum, Format, Identifizierung, Sprache und Schlagwort wie unter Kurs (s. oben) geloest. *Klassifikation (externe) und Herausgebende Einrichtung kommen beim Content nicht als Eigenschaft zur Verwendung.
Profilspezifische Wertevokabulare und Kodierungsschemas[edit]
Review Keßler:
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-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: ------------ Wie unter Kurs (s.o.). Ob das gleiche Vokabular fuer isolierte 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[edit]
[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?