ApplicationProfiles/EvaluierungELAN

KIM-AG-IM,DCUB  KIM-intern

= Evaluierung ELAN =

KIM-Zertifizierung
Ziel der KIM-Zertifizierung ist es, die Interoperabilität zwischen Metadatenanwendungen zu unterstützen, indem die KIM-Arbeitsgruppe Interoperable Metadatenprofile (KIM-AG IM) Anwendungsprofile aus dem deutschsprachigen Raum nach Prinzipien der Konformität mit Interoperabilitätsmodellen prüft und bewertet. Für die KIM-Zertifizierung dient als Interoperabilitätsmodell der sog. "Singapore Framework", der die Komponente eines Anwendungsprofils und dessen Basis im Dublin Core Abstract Model (DCAM) und Resource Description Framework (RDF) beschreibt. Best-Practice Exemplare eines Anwendungsprofils in diesem Sinne sind das Dublin Core Collections Application Profile (DCCAP) und Eprints Application Profile.

Die hier vorliegende Evaluierungsrichtlinie dient dazu, die Gutachten zu systematisieren und macht transparent, welche Anforderungen KIM an ein Anwendungsprofil hat und worauf die Entscheidungen der Gutachter beruhen.

Der Evaluierungsprozeß gestaltet sich in folgender Reihenfolge:


 * 1) Auf der Grundlage der hier vorliegenden Evaluierungsrichtlinie wird ein Anwendungsprofil von den Mitgliedern der KIM-AG IM geprüft.
 * 2) Die KIM-AG IM erstellt ein Gutachten, in dem sie darlegt, inwieweit die Evaluierungskriterien in dem Anwendungsprofil umgesetzt wurden.
 * 3) Die KIM-AG IM erstellt eine Empfehlung hinsichtlich der Zertifizierung,
 * 4) * in der sie diese Empfehlung begründet,
 * 5) * in der sie ggf. weitere Empfehlungen zur Verbesserung des AP ausspricht.
 * 6) Die KIM-AG IM gibt Gutachten und Empfehlungen an die KIM-Geschäftsstelle weiter.
 * 7) Die KIM-Geschäftsstelle zertifiziert das Anwendungsprofil oder informiert die "Antragsteller" das und warum das vorgelegte Profil nicht zertifiziert wurde.
 * 8) Im Falle der Zertifizierung eines Anwendungsprofils, werden Gutachten und Empfehlungen auf den KIM-Seiten veröffentlicht. Wird das Profil nicht zertifiziert, so werden Gutachten und Empfehlung nur an die "Antragsteller" weitergegeben, um diesen die Möglichkeit zu geben, zu den Ausführungen der Gutachter Stellung zu beziehen und ggf. die vorgeschlagenen Änderungen vorzunehmen.

= Gegenstand der Evaluierung =

Im Rahmen der KIM-Zertifizierung ist ein Anwendungsprofil ein Dokument (oder ein Paket aus mehreren Dokumenten), das eine spezifische Metadatenanwendung detailliert beschreibt, damit die Metadaten auch außerhalb der lokalen Anwendung (z.B. in anwendungsübergreifenden Portalen) wiederverwendet werden können. Ein gutes Profil spezifiziert die Wiederverwendbarkeit vom Standpunkt:


 * eines "Informationsanbieters", der Metadaten unterschiedlichen Ursprungs in seine lokale Anwendung einbinden will,


 * eines Entwicklers, der auf der Grundlage eines vorliegenden Profils weitere Anwendungen erstellen will.

Eine detaillierte Dokumentation setzt sich aus den folgenden Komponenten zusammen:


 * Beschreibung der Zielsetzung und des Geltungsbereichs der Anwendung,


 * Beschreibung der funktionellen Anforderungen der Anwendung,


 * Darstellung der Entitäten, die im Rahmen der Anwendung beschrieben werden, in Form eines Datenmodells,


 * Beschreibung der verwendeten Elemente in Form eines Beschreibungssatzprofils,

Diese Komponente müssen in sich und untereinander schlüssig sein. Empfohlene und verpflichtende Merkmale werden unterschieden; verpflichtende Merkmale sind eine unumgänglich Voraussetzung für die Zertifizierung.

= Evaluierung: "ELAN Application Profile" =

Zielsetzung und Geltungsbereich des Anwendungsprofils
Zielsetzung und Geltungsbereich eines Anwendungsprofils sollen beschrieben werden. Folgende Fragen betreffen verpflichtende Merkmale:


 * Ist der Kontext beschrieben, in dem das Anwendungsprofil verwendet wird oder verwendet werden kann?

Ja, z.B. Seite 7 "Ein minimales Kernset an Metadaten, sowohl auf der Ebene des Kurses als auch auf der Ebene der Contents (Vorlesungsskripte, Übungszettel, Videos etc.), kann helfen, in Zukunft die heterogenen verteilten Metadatensammlungen im Hochschulbereich über ein gemeinsames Such-Interface zusammenzuführen." "Auf der Basis des ELAN Application Profiles ist der landesweite Nachweis und die Recherche über alle Lehr- und Lerneinheiten über ein gemeinsames ELAN Portal garantiert."

Folgende Fragen betreffen Merkmale, die nur "empfohlen" sind:

[Rühle, Frodl, Hörmann] Ja, allerdings sehr knapp. S. Seite 5: "... Empfehlungen erarbeiten, die Lehrende zur Beschreibung virtueller und multimedialer Lerneinheiten verwenden können." (Seite 5) Eindeutig benannt in Kapitel 4.2: Studierende, (Verwaltung von Universitäten), Lehrende. Allgemein beschrieben in Kapitel 2: "Ziel von ELAN ist es, den Hochschulen des Landes Niedersachsen Unterstützung beim Umbau bestehender und beim Aufbau neuer Strukturen zum Einsatz von Multimedia ... zu geben ..." (S. 5) Leicht widersprüchliche Aussage dazu auf Seite 47: "Die oben beschriebenen Metadatenelemente sind für die (zentrale) Recherche im ELAN Portal gedacht und sollen nicht lokale Katalogisierungsformate ersetzen."
 * Ist die Zielgruppe, die das Anwendungsprofil nutzen soll, benannt und beschrieben?

Ja, Organisationen und Individuen werden auf Seite 52 aufgezählt.
 * Sind die Organisationen und Individuen identifiziert, die an der Entwicklung des Profils beteiligt waren?


 * Sind Absprachen, Richtlinien oder Absichten, die die zukünftige Entwicklung und Pflege des Profils betreffen, genannt?

[Rühle, Frodl, Hörmann] nein

Funktionelle Anforderungen der Anwendung
Die Dokumentation muss die Funktionen beschreiben, die die Anwendung im Hinblick auf Benutzerbedürfnisse erfüllt. Diese funktionellen Anforderungen sollten als allgemeine Funktionen (wie Finden, Identifizieren, Auswählen ...) formuliert werden, können aber auch als spezifischere Funktionen detaillierter beschrieben werden. Folgende Fragen betreffen verpflichtende Merkmale der funktionellen Anforderungen:


 * Sind die funktionellen Anforderungen genannt?

[Rühle, Frodl, Hörmann] ja Allgemein Seite 6: "Die ELAN Arbeitsgruppe "Metadaten" hat das Ziel, ein gemeinsames, minimales Kernset an Metadaten (ELAN Application Profile) zu definieren, die Nachweis und der Recherche von Lehr- und Lerninhalten über ein zentrales ELAN Portal dienen soll". "Die frühe Verständigung auf einige minimale Standards in dem Bereich Metadaten erleichtert in Zukunft die Zusammenführung der E-Learning Angebote auf regionaler/lokaler sowie nationaler und internationaler Ebene." Spezifischer Seite 7: "Darüber hinaus erlauben bestimmte Metadatenfelder weitere Optionen wie Ranking-Mechanismen, Filter- und Sortierfunktionen oder die Eingrenzung der Suchmenge." "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." Schließlich Nutzerszenarien auf Seite 8 als Beispiele für funktionelle Anforderungen.

Sollte diese Frage nicht auf der Grundlage der genannten funktionellen Anforderungen von den Kolleginnen und Kollegen geprüft werden, die die einzelnen Terme überprüfen?
 * Entspricht das Beschreibungssatzprofil den genannten funktionellen Anforderungen?

Modell der beschriebenen Entitäten
Das Anwendungsprofil muss ein (wenn auch einfaches) Datenmodell bereitstellen, das die zu beschreibenden Entitäten und die Beziehungen zwischen diesen Entitäten beschreibt. Das Datenmodell kann in graphischer Form (z.B. als ein oder mehrere UML-Klassen-Diagramme) oder als Text dargestellt werden. Das Anwendungsprofil kann auch auf ein extern formuliertes Datenmodell als Basis verweisen. In Hinblick auf das Datenmodell muss folgendes festgestellt werden:


 * Sind die Entitäten, die beschrieben werden sollen, benannt?
 * Bietet das Profil ein schlüssiges Datenmodell?
 * Falls das Anwendungsprofil auf einem extern formulierten Datenmodell basiert, müssen folgende Fragen mit "ja" beantwortet werden:
 * Wird das externe Datenmodell, das verwendet wird, genannt?
 * Sind Abweichungen des Profils von dem zitierten externen Datenmodell genannt?

[Rühle, Frodl, Hörmann] 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"
Im Beschreibungssatzprofil werden die im Anwendungsprofil verwendeten Terme und Wertevokabulare genannt und deren Verwendung wird beschrieben. Die verwendeten Terme und Wertevokabulare müssen mit den funktionellen Anforderungen der Anwendung in Einklang stehen (siehe oben) und ausreichend dokumentiert sein. Terme und Wertevokabulare können neu deklariert oder aus bereits vorhandenen Vokabularen übernommen werden. In beiden Fällen besteht eine ausreichende Beschreibung minimalerweise aus:


 * URI des Terms
 * Definition des Terms
 * Beschaffenheit des Terms: Terme werden der im DCAM anerkannten RDF-basierten Typologie von Eigenschaften und Klassen zugeordnet ("DCAM-konformität"). Terme und Wertevokabulare müssen DCAM-konform sein. Die Konformität wird anhand eines Metadaten-Term-Entscheidungsbaums [8] geprüft.

Best-Practice-Bespiele gut deklarierter Terme sind DCMI Metadata Terms, Dublin Core Collection Description Terms , and Eprints Terms. Terme sollen auch in RDF-Schemas deklariert werden --DCMI Metadata Terms und Dublin Core Collection Description Terms.

Extern definierte Terme
Es wird empfohlen, Terme aus bereits vorhandenen Vokabularen zu verwenden. Im Rahmen der Evaluierung werden folgende verpflichtende Merkmale geprüft:


 * Sind die extern definierten Terme DCAM-konform?


 * Sind diese Terme in den Vokabularen, aus denen sie übernommen wurden, adäquat beschrieben (minimalerweise mit URI, Definition und Beschaffenheit)?


 * Sind diese Terme im vorliegenden Beschreibungssatzprofil derart definiert und annotiert, dass die Semantik des Terms im vorliegenden Beschreibungssatzprofil der Semantik des Originalumfelds nicht widerspricht? (Die Nutzungsrichtlinien im vorliegenden Beschreibunssatzprofil dürfen den Geltungsbereich des Terms zwar semantisch verfeinern, aber nicht ausweiten.)

[ Review Keßler, Hörmann hier. ] 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 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
Können Terme nicht aus bereits vorhandenen Vokabularen übernommen werden, dann werden sie für die vorliegende Anwendung neu deklariert, minimalerweise in Form einer Webseite und eines RDF-Schemas, idealerweise mit beiden. Im Rahmen der Evaluierung werden folgende verpflichtende Merkmale geprüft:


 * Sind die neu deklarierten Terme DCAM-konform?


 * Sind die neu deklarierten Terme im vorliegenden Beschreibungssatzprofil adäquat beschrieben (minimalerweise mit URI, Definition und Beschaffenheit)?

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
Es wird empfohlen, Wertevokabulare und Kodierungsschemas aus bereits vorhandenen Vokabularen zu übernehmen. Im Rahmen der Evaluierung werden folgende verpflichtende Merkmale geprüft:


 * Sind die aus anderen Vokabularen verwendeten Wertevokabulare und Kodierungsschemas DCAM-konform?


 * Sind diese Wertevokabulare und Kodierungsschmas in den Vokabularen, aus denen sie übernommen wurden, adäquat beschrieben?


 * Sind diese Wertevokabulare und Kodierungsschemas im vorliegenden Beschreibungssatzprofil derart definiert und annotiert, dass die Semantik im vorliegenden Beschreibungssatzprofil der Semantik des Originalumfelds nicht widerspricht?

[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
Wertevokabulare und Kodierungsschemas, die nicht aus bereits vorhandenen Vokabularen übernommen werden können, werden für die vorliegende Anwendung neu deklariert. Im Rahmen der Evaluierung werden folgende verpflichtende Merkmale geprüft:


 * Sind die neu deklarierten Wertevokabulare und Kodierungsschemas DCAM-konform?
 * Sind die neu deklarierten Wertevokabulare und Kodierungsschemas im vorliegenden Beschreibungssatzprofil adäquat beschrieben?

[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).

Extern definierte Terme

 * Sind die extern definierten Terme DCAM-konform?


 * Sind diese Terme in den Vokabularen, aus denen sie übernommen wurden, adäquat beschrieben (minimalerweise mit URI, Definition und Beschaffenheit)?


 * Sind diese Terme im vorliegenden Beschreibungssatzprofil derart definiert und annotiert, dass die Semantik des Terms im vorliegenden Beschreibungssatzprofil der Semantik des Originalumfelds nicht widerspricht? (Die Nutzungsrichtlinien im vorliegenden Beschreibunssatzprofil dürfen den Geltungsbereich des Terms zwar semantisch verfeinern, aber nicht ausweiten.)

[Review Keßler, Hörmann hier.] 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

 * Sind die neu deklarierten Terme DCAM-konform?


 * Sind die neu deklarierten Terme im vorliegenden Beschreibungssatzprofil adäquat beschrieben (minimalerweise mit URI, Definition und Beschaffenheit)?

[Siehe oben.]

Extern definierte Wertevokabulare und Kodierungsschemas

 * Sind die aus anderen Vokabularen verwendeten Wertevokabulare und Kodierungsschemas DCAM-konform?


 * Sind diese Wertevokabulare und Kodierungsschmas in den Vokabularen, aus denen sie übernommen wurden, adäquat beschrieben?


 * Sind diese Wertevokabulare und Kodierungsschemas im vorliegenden Beschreibungssatzprofil derart definiert und annotiert, dass die Semantik im vorliegenden Beschreibungssatzprofil der Semantik des Originalumfelds nicht widerspricht?

[Traugotts Kommentar] *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

 * Sind die neu deklarierten Wertevokabulare und Kodierungsschemas DCAM-konform?


 * Sind die neu deklarierten Wertevokabulare und Kodierungsschemas im vorliegenden Beschreibungssatzprofil adäquat beschrieben?

[Review Keßler, Koch hier.] 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
[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?

= Referenzen =