Component Registry
7. Komponenten
Auswahl
Analog zu der Darstellung von Profilen kann die Übersicht über Komponenten in der Component Registry im Browse-Modus über den Tab Components ausgewählt werden. Sobald eine Komponente durch Anklicken ausgesucht wurde, wie beispielsweise die Komponente GeneralInfo (s. Abb. 13), erscheint unterhalb der tabellarischen Übersicht eine Detailansicht dieser Komponente (s. Abb. 13).
Der Ausschnitt der Detailansicht für die Komponente GeneralInfo in Abb. 13 zeigt nur die enthaltenen Datenkategorien (d.h. Elemente) dieser Komponente, die jedoch auch noch weitere, in der Abbildung nicht sichtbare Komponenten einbindet. Die Darstellung der Komponenten erfolgt nach dem bereits in Inhaltspunkt 6 erläuterten Prinzip (d.h. die Komponentennamen sind je nach Veröffentlichungsstatus farbig umrandet und können durch Anklicken expandiert werden) und wird daher an dieser Stelle nicht erneut aufgegriffen. Ebenso beziehen sich die Erklärungen auf die Ansicht im View-Modus. Die bereits eingeführte XML-Ansicht, die sich vor allem durch die zusätzliche Angabe der PID auszeichnet, wird im Falle von abweichenden Benennungen oder Darstellungsoptionen im jeweiligen Zusammenhang erörtert.
Datenkategorien
Die Detailansicht einer Komponente im View-Modus stellt dem Nutzer verschiedene Informationen zum Inhalt einer Komponente dar, zu denen neben weiteren eingebundenen Komponenten die Datenkategorien zählen.
Name
Für Datenkategorien wird zuerst der Name der jeweiligen Datenkategorie angegeben (z.B. ResourceName, s. Abb. 13). Die Benennung einer Datenkategorie spielt in CMDI nur eine untergeordnete Rolle. Entscheidend ist die Angabe des Links zu ISOcat (s. im folgenden Unterpunkt Concept Link), welcher die PID (Persistent Identifier) der Datenkategorie enthält. So können Elemente trotz unterschiedlicher Benennungen in CMDI auf dasselbe Konzept verweisen. Dennoch sei es zur Einhaltung der Konsistenz empfohlen, bei der Verwendung bereits existierender Komponenten in der Component Registry oder definierter Datenkategorien in ISOcat die bestehenden Benennungen der Datenkategorien auch für eigene Verwendungszwecke zu übernehmen.
Datentyp
Zusammen mit dem Namen wird der zugehörige Datentyp aufgeführt (d.h. im Fall von ResourceName ist der Inhaltstyp des Elements ein beliebiger String). Neben Strings können auch andere Datentypen für Elemente, wie z.B. boolean, date, gYear oder anyURI, gewählt werden (für weitere Datentypen und Erläuterungen s. http://www.w3.org/TR/xmlschema-2/, Punkt 3.2: Primitive Datatypes).
Kontrolliertes Vokabular
Wenn bei einer Datenkategorie explizit kein zugehöriger Datentyp angegeben ist, liegt eine Einschränkung vor: es darf nur kontrolliertes Vokabular für den Inhalt der Datenkategorie verwendet werden. Dies bedeutet, dass dem Nutzer eine Auswahl an gültigen Begriffen präsentiert wird, aus denen der für die jeweilige Datenkategorie einer Metadateninstanz zutreffende Wert ausgewählt werden kann.
Dazu wird im View-Modus der Component Registry eine interaktive Darstellung in Form einer sogenannten Picklist dargeboten. Beispiele für kontrolliertes Vokabular sind in Abb. 13 bei den Datenkategorien ResourceClass und LifeCycleStatus zu sehen. Durch Anklicken des nach unten gerichteten Pfeils der Picklist (s. Abb. 14, unten) wird diese expandiert und der Nutzer kann durch Scrollen die zulässigen Werte einsehen und auswählen (s. Abb. 14, oben). So können z.B. für die Datenkategorie ResourceClass u.a. die Werte Lexicon, Corpus, Tool, Experiment oder Grammar ausgesucht werden. Beim Erstellen einer Metadateninstanz in CMDI ist dabei zu beachten, dass für Datenkategorien, die über Listen von kontrolliertem Vokabular verfügen, nur die darin definierten Begriffe zulässig sind. Wenn ein nicht in der Liste enthaltener Begriff in der Metadateninstanz verwendet wird, ist diese Instanz nicht mehr gegen das zugehörige Schema valide.
In der XML-Struktur (s. Abb. 15) für kontrolliertes Vokabular wird die bereits im View-Modus illustrierte Ansicht (s. Abb. 14) folgendermaßen dargestellt:
Das in Abb. 15 aufgelistete kontrollierte Vokabular für den Inhalt des Elementes ResourceClass enthält das Containerelement <ValueScheme>...</ValueScheme>, das in den mit item betitelten Elementen die möglichen Elementinhalte von ResourceClass auflistet. Positioniert wird dieses Containerelement innerhalb der entsprechenden Datenkategorie, die in der XML-Struktur mit <CMD_Element ....>....</CMD_Element> beginnt.
Attribute
Anzumerken sei an dieser Stelle außerdem, dass im Component Browser nicht nur für kontrolliertes Vokabular von Elementen Gebrauch von Picklisten gemacht wird, sondern auch für Attributwerte von Komponenten oder Elementen. Ein Beispiel hierfür zeigt die in Abb. 16 dargestellte Komponente Prerequisite, die über das Attribut type verfügt.
Nach dem Namen und der Beschreibung der Komponente ist in der Ansicht in Abb. 16 die Attribute List angegeben, die den Namen des Attributes (d.h. type) und eine Picklist für die Attributwerte umfasst (z.B. kann als Wert software ausgewählt werden). In der XML-Ansicht wird eine solche Liste von vorgegebenen Attributwerten folgendermaßen dargestellt:
Die in Abbildung 17 illustrierte XML-Struktur für Attributwertlisten beginnt mit dem Element <AttributeList>...</AttributeList>, welches als Container fungiert und beliebig viele Attribut-Elemente (<Attribute></Attribute>) beinhalten kann. Letztere dienen ebenfalls als Containerelement für die XML-Elemente <Name>...</Name>, welches den Namen des Attributes festlegt (s. type in Abb. 16), und <ValueScheme>...</ValueScheme>, das eine Aufzählung der zugelassenen Attributwerte enthält (s. software und hardware in Abb. 17).
Concept Link
Zurückkehrend zur Ausgangsbeschreibung der Datenkategorien innerhalb einer Komponente ist es notwendig, neben den bereits thematisierten Aspekten wie dem Elementnamen und Datentyp sowie dem kontrolliertem Vokabular für Elementinhalte und Attributwerte weitere Angaben im Component Browser zu erläuterten. Dazu zählt beispielsweise die Angabe des ConceptLink für Elemente (s. Abb. 18).
Diese im View-Modus gewählten Angaben (s. Abb. 18, z.B. Elementname, Datentyp, ConceptLink, etc.) werden in der XML-Struktur einer Komponente als Attributwertpaare dargestellt. Beispielsweise handelt es sich bei ConceptLink um den Namen des Attributes und beim angegebenen Link um den zugehörigen Wert. Dieser Link verweist auf die Dokumentation der entsprechenden Datenkategorie, die durch die interaktive Beschaffenheit des View-Modus durch ein Anklicken des dokumentierten Links in einem neuen Fenster geöffnet werden kann. Die Dokumentation ist extern in ISOcat gespeichert (Data Category Registry for ISO TC 37, s. http://www.isocat.org), dem Verzeichnis für Datenkategorien.
In diesem Verzeichnis besitzt jede Datenkategorie einen Persistent Identifier (PID), der auch in der Component Registry in den angegebenen Links der Datenkategorien auf ISOcat verzeichnet ist. Der Vorteil dieses Prinzips ist, dass die Benennung der Datenkategorien in CMDI nur eine nebensächliche Rolle spielt. Relevant ist lediglich die Angabe des Links zu ISOcat, der die PID der Datenkategorie enthält. Somit können auch unterschiedliche Benennungen von Elementen in verschiedenen CMDI-Metadateninstanzen auf dasselbe Konzept in ISOcat verweisen.
Display Priority
Für Datenkategorien kann in der Component Registry außerdem ihre Anzeigepriorität (s. Display Priority, Abb. 18) bei der Verarbeitung mit externen Tools angegeben werden. Wenn ein Element zuerst angezeigt werden soll, setzt man den Wert von Display Priority gleich 1, wodurch das Element in der Anzeige höchste Priorität erhält. Soll eine Datenkategorie hingegen in der Anzeige nicht automatisch erscheinen, setzt man den Wert gleich 0. Gute Kandidaten für eine hohe Anzeigepriorität sind beispielsweise der Name, Titel oder die Klasse einer Ressource (s. Abb. 18).
Number of Occurrences
Des Weiteren wird für jede Datenkategorie mit Number of Occurrences die zugelassene Anzahl ihrer Verwendung in einer Metadateninstanz definiert. Die erste Zahl gibt dabei immer das minimale und die letzte Zahl das maximale Auftreten einer Datenkategorie an. Ein Element ist optional, wenn das minimale Auftreten mit Null gleichgesetzt ist (s. z.B. Element ResourceName, Abb. 18). Wenn die Kardinalität 1-1 gewählt wurde, darf ein Element nur genau einmal gebraucht werden. Um eine unendliche Verwendung erzielen zu können, muss die maximale Kardinalität mit unbounded gleichgesetzt werden. In der XML-Ansicht einer Komponente oder eines Profils werden für diese Definitionen der Kardinalität die Attribute CardinalityMax und CardinalityMin verwendet (s. Abb. 17).
Multilingual (xml:lang)
Die letzte Anzeigeinformation für Datenkategorien im Component Browser betrifft die Angabe zur Multilingualität. Ausgenommen von Elementen, deren Inhalte über kontrolliertes Vokabular verfügen, wird dieses Attribut für jedes Element zur Identifikation der Mehrsprachigkeit angegeben. Diese Information dient der Sprachidentifikation in den Metadateninstanzen, in denen durch die Verwendung des Attributs xml:lang die Sprache eines Elementinhaltes spezifiziert werden kann. Wenn Multilingual den Wert true besitzt (s. Abb. 18), kann das Attribut xml:lang in der Metadateninstanz verwendet werden. Somit kann beispielsweise der Titel einer Ressource in verschiedenen Sprachen dokumentiert werden, da das Element durch die zugelassene Mehrsprachigkeit beliebig oft verwendet werden und bei jeder Verwendung des Elements das Attribut xml:lang einen anderen Wert für die jeweilige vorliegende Sprache erhalten kann. In der Component Registry wird nach momentanem Entwicklungsstand beim Vorliegen einer erlaubten Multilingualität die maximale Kardinalität eines Elementes automatisch als unbounded definiert, sofern nicht zuvor ein maximal einmaliges Auftreten festgelegt war. Jedoch ist die Verwendung des Attributes xml:lang in einer Metadateninstanz nicht zulässig, wenn Multilingual mit dem Wert false gleichgesetzt ist.
Komponenten innerhalb von Komponenten
Die bisher erläuterten Details zur Darstellung der Datenkategorien treffen zum Teil ebenso auf die Illustration von Komponenten zu, die selbst weitere Komponenten einbinden können (s. Abb. 19).
Für die innerhalb der Komponente Access (s. Abb. 19) eingebundenen Komponenten DeploymentToolInfo, Contact und Descriptions wird jeweils der genannte Name sowie die Kardinalität der Komponente angegeben. Des Weiteren besteht die Möglichkeit, Komponenten durch Anklicken des Namens zu expandieren (s. Profile), um weitere Informationen über ihre Inhalte zu erhalten.
Download
Eine weitere Funktionalität der Component Registry betrifft die Möglichkeit, Komponenten als XML-Dateien herunterzuladen. Dies ist beispielsweise für die lokale Erstellung von Komponenten von Nutzen. Um zu diesen Downloadoptionen zu gelangen, kann der Nutzer die entsprechende Komponente in der Übersichtstabelle auswählen und bekommt per Rechtsklick auf den Namen der gewählten Komponente ein Fenster mit weiteren Bearbeitungsoptionen angezeigt (s. Abb. 20). Durch die Auswahl der dargebotenen Option Download als XML... kann die Komponente im XML-Format gespeichert werden. Die weiteren Bearbeitungsfunktionalitäten werden im folgenden Inhaltspunkt genauer erläutert.
