Tutorial: CorpusQueryLanguage (CQL)

Version: 1.0
Autor: Hannes Pirker/ACDH-CH-ÖAW
Zuletzt geändert: 2022-01-26

Abstract

Zur Verwendung der SketchEngine (SKE), insbesondere der Abfragesprache CorpusQueryLanguage (CQL)

Inhalt

Zweck und Aufbau dieses Dokuments

Dieser Text dient als kompakter Überblick zur Suche in der SketchEngine (SKE), insbesondere zur Verwendung der CorpusQueryLanguage (CQL).

Die Erklärungen über die CQL sind „allgemeingültig“, einige Beispiele sind allerdings explizit auf die Verwendung mit dem Austrian Media Corpus (amc, Version 3) abgestimmt.

Zuerst wird dargestellt, welche Informationen in der SKE für das amc vorhanden sind, und wie diese intern organisiert sind.
Danach wird gezeigt, wie nach diesen Informationen gesucht werden kann.

Am Ende des Dokuments finden sich weiterführende Links, insbesondere sei die offizielle Dokumentation der SketchEngine empfohlen.

Grundlagen: Token vs. Strukturen

Prinzipiell wird in der SKE und der CQL zwischen Token und Strukturen unterschieden.

Token

Token sind das Ergebnis des sog. Tokenisierungsprozesses – d.h. der Zerlegung des Eingangstexts in linguistisch sinnvolle Einheiten. Das klingt nun komplizierter als es ist: in der Regel entspricht ein Token einem orthographischen Wort. Die simpelste Tokenisierungsstrategie wäre: alles was zwischen 2 Leerzeichen steht, ist ein Token. Diese „primitive“ Regel muss freilich um die Berücksichtigung von Satzzeichen ergänzt werden: Satzzeichen sollen vom vorangehenden Wort abgetrennt werden und bilden separate Token. Verkompliziert wird diese Aufgabe durch die Existenz von Abkürzungen: zum Beispiel sind die Punkte in z.B. natürlich keine Satzzeichen, dürfen daher nicht abgetrennt werden, denn z.B. sollte als ein Token behandelt werden.

Kürzer und vereinfacht gefasst: Token sind die einzelnen Wörter, Satzzeichen oder Zahlen im Text.

Anmerkung: Wie bei allen automatisierten Verarbeitungsschritten erfolgt die Tokenisierung bisweilen nicht fehlerfrei. So ist bei der Suche nach Token, die Satz- oder Sonderzeichen enthalten, zu berücksichtigen, dass evtl. die Tokenisierung diese Zeichen miss-interpretiert hat und daher das Wort fälschlicherweise in mehrere Token aufgeteilt wurde.

Token-Attribute

Die Informationen die jedem Token zugeordnet werden, werden in der SKE Attribute genannt.

Einige der Token-Attribute im amc wären

  • word : Das einfachste Attribut beinhaltet die orthographische Form des Wortes.
  • lemma : hier steht die Grundform des Wortes (wie es von einem Lemmatisierungsprogramm ermitteln wurde).
  • lc : eine lower cased Version des Wortes. Die Suche in CQL ist case sensitiv, lc kann verwendet werden, um case insensitiv zu suchen. D.h. eine Suche [word="Ciao"] findet nur genau „Ciao“. Die Suche [lc="ciao"] findet ciao, Ciao, CIAO, CiAo etc.
  • posTT : part-of-Speech tags nach dem STTS-Tagset, wie sie vom PoS tagger TreeTagger vergeben wurden.
  • pos : part-of-Speech tags, wie sie vom PoS tagger RFTagger vergeben wurden: zusätzlich zur Wortart werden auch morphologische Informationen angegeben.

Tipp: Die Liste aller Attribute eines Korpus lässt sich immer einfach unter dem Menüpunkt Corpus info oder auch — völlig äquivalent — durch Anklicken des Korpusnamens anzeigen. Dort finden sich dann unter den Links Corpus description und v.A. unter Tagset summary auch noch weiterführende Informationen.

Strukturen

Die Token sind in hierarchische Strukturen eingebettet.

Zum besseren Verständnis dieses Konzepts hier ein Beispiel, wie für den Import in die SKE vorbereitete Textdaten aufgebaut sind.

<doc id="APA_20170101_APA0001" datum_full="2017-01-01T00:11:16Z" 
     datum="2017-01-01" bibl="APA-Meldungen digital  vom 2017-01-01" 
     docsrc_name="APA-Meldungen digital" 
     region="agesamt" 
     mediatype="print" 
     Tokens="180" 
     ressort2="chronik ausland unzuordenbar" 
     autor="fre" 
  >
<p>
<s>
Maschine    N.Reg.Nom.Sg.Fem        NN     Maschine-n
mit         APPR.Dat                APPR   mit-i
mehr        PRO.Indef.Attr.-.*.*.*  ADV    mehr-r
als         CONJ.Comp.-             KOKOM  als-c
hundert     CARD                    CARD   hundert-m
Menschen    N.Reg.Dat.Pl.Masc       NN     Mensch-n
an          APPR.An                 APPR   an-i
Bord        N.Reg.Dat.Sg.Neut       NN     Bord-n
sollte      VFIN.Mod.3.Sg.Past.Subj VMFIN  sollen-v
nach        APPR.Dat                APPR   nach-i
Mexiko      N.Name.Dat.Sg.Neut      NE     Mexiko-n
fliegen     VINF.Full.-             VVFIN  fliegen-v
...
</s>
</p>
...
</doc>

Dieses Datenformat nennt sich (in der SKE-Terminologie) „Vertikale“: Strukturen sind mithilfe von Spitzklammern ausgezeichnet (wie aus XML bekannt), dazwischen finden sich in je einer separaten Zeile die schon bekannten Token mit ihren in Spalten organisierten Attributen wie z.B. Lemma- und Part-of-Speech-Informationen.

In diesem Beispiel ist zu erkennen, dass die Strukturen als XML-artige Annotationen die Token ergänzen.
Typische Strukturen sind Dokumente, Paragraphen (Absätze) und Sätze, die im amc als <doc> <p> und <s> ausgezeichnet werden.

Die Strukturen können Zusatzinformationen in Form von Attributen enthalten.
Typischerweise finden sich in den Attributen des <doc>-Elements die Metadaten zum entsprechenden Dokument.
Im amc entspricht der Inhalt eines <doc>-Elements einem Zeitungsartikel.
An Metadaten sehen wir im Beispiel Attribute wie id, datum, autor, src, ressort2, etc.

Schnelleinstieg: Suche mit „Simple query“

Die einfachste Form der Suche ist die (nomen est omen) „Simple query“.

Diese kann in der SKE an zwei verschiedenen Orten aufgerufen werden:

  • im Suchfeld links oben auf der SKE Maske
  • über den Menüpunkt: Search — Feld: Simple query

Gibt man hier ein Wort ein, so sucht die SKE

  • dieses Wort (und zwar case-insensitiv, d.h. ohne Berücksichtigung von Groß- und Kleinschreibung. Die Eingabe SMS findet SMS, sms, Sms etc.)
  • entspricht die Sucheingabe auch einem Lemma, dann auch alle Flexionsformen dieses Lemmas. (D.h. eine Suche nach Haus findet Haus, Hauses, Hause, Häuser, Häusern.)

Mehrwort-Suche

Es kann auch eine Abfolge mehrerer Wörter angegeben werden, die SKE sucht dann nach genau dieser Abfolge.

z.B. ein schönes Haus

Anmerkung: da bei der Simple query wie erwähnt auch nach den Wortformen eines Lemmas gesucht wird, findet eine Suchanfrage schön Haus auch alle Paarungen der Wortformen des Lemmas schön und der Wortformen des Lemmas Haus, also z.B. schönes Haus, schönsten Hauses, Schöneren Häusern etc.
Anmerkung : das Lemma für definite Artikel ist übrigens die, für indefinite ist es eine. D.h. die Abfrage die schön Haus oder eine schön Haus liefert die entsprechenden Kombinationen in allen Kasus und Numeri.

Wildcards

In der Simple query ist die Verwendung des Wildcards (Jokerzeichen) * möglich: es steht für beliebig viele (auch 0!) beliebige Zeichen.

z.B.:

  • Haus*: alle Wörter, die mit der Buchstabenfolge Haus beginnen: Haus, Hauses, Hausmaus, Haussa, Hausbesorgerin … aber auch alle Wortformen von Lemmata die mit Haus beginnen. Es wird also z.B. auch Häusern gefunden.
  • *aus : alle Wörter, die mit der Buchstabenfolge aus enden: aus, Maus, Haus, Schildlaus …
  • Ha*s: alle Wörter, die mit Ha beginnen, und mit s enden: Has, Haus, Hass, Handelsabschluss, Hafenmeistergattinenpendlerbus etc. Wegen der beiden speziellen Eigenschaften case-insensitiv und Lemma-Suche wird aber auch z.B. haltlos (case-insensitv) und haltlose gefunden (Ergebnis einer Lemma-Suche, obwohl die Wortform gar nicht auf s endet!)

Ein weiteres Beispiel für den case-insensitiven Chrakter der Simple query: deutsch* findet: deutsch, deutsche, deutsches … aber auch: Deutschlands, Deutschmatura …

„Vollsuche“ mit der Corpus Query Language (CQL)

Wie wir gesehen haben, kann in der Simple query nur nach Token und dabei auch nur nach Wortformen gesucht werden, oder exakter ausgedrückt: es kann nach Werten im Attribut word gesucht werden (wobei implizit intern zusätzlich die Attribute lc und lemma zur Suche herangezogen werden).
Im Gegensatz hierzu bietet die CQL weit mehr Möglichkeiten: Die Suche in beliebigen Attributen, die Suche in Strukturen, die Suche mit regulären Ausdrücken etc.

Suche auf der TOKENEBENE in CQL

Suchanfragen mit der CQL werden unter dem Menüpunkt Search im Feld CQL eingegeben. (Sollte nach Auswahl von Search ausnahmsweise einmal nur das Suchfeld für Simple query aufscheinen, kann durch Auswahl des Links Query type die volle Liste der Query-Möglichkeiten aufgeklappt werden.)

In der Suche mit CQL wird jedes Token durch eckige Klammern bezeichnet.
Innerhalb dieser Klammern können die Bedingungen angegeben werden, welche die Attribute dieses Token erfüllen müssen:

  • [ word="Haus" ] Alle Einträge mit der Buchstabenfolge „Haus“
  • [ lemma="Haus" ] Alle Einträge mit dem Lemma „Haus“ – also „Haus“ „Hauses“ … „Häusern“
  • [ posTT="NN" ] Alle Nomen
  • [] (KEINE Bedingungen) : diese Suche findet ALLE Token

Diese Bedingungen können auf mehrere Worte ausgedehnt werden:

  • [ posTT="ADJA" ] [ lemma="Haus" ] : alle Token mit der Wortart (attributives) Adjektiv, gefolgt von einem Eintrag mit dem Lemma „Haus“
    also z.B. schönes Haus, hohe Häuser, niedrigen Häusern…

Anmerkung zu Leerzeichen: Leerzeichen werden in CQL Abfragen ignoriert, es macht also nur in einen Unterschied in der Lesbarkeit und nicht im Suchergebnis ob man [ posTT="ADJA" ] [ lemma="Haus" ] oder [posTT="ADJA"] [lemma="Haus"] schreibt.

Reguläre Ausdrücke

In der CQL können sogenannte reguläre Ausdrücke verwendet werden, womit die Ausdrucksmächtigkeit und Flexibilität der Suche stark erhöht wird.

Die wichtigsten „Bausteine“ bei der Zusammenstellung eines regulären Ausdrucks sind:

„.“ : Ein Punkt steht für jedes beliebige Zeichen

z.B. [word="Ha.s"] findet „Haus“ „Hass“ „Hals“ …

„*“ : steht für 0, 1 oder beliebig viele Wiederholungen des vorhergehenden Zeichens oder Ausdrucks.

z.B.

  • [word="Hurra*"] findet „Hurr“ „Hurra“ „Hurraa“ … „Huraaaaaaaaaaa“ …

Anmerkung: Beachten Sie den Unterschied zur Wirkungsweise des * in der Simple query: dort steht * schon für 0, 1, oder beliebig viele beliebige Zeichen.
In einem regulären Ausdruck bezieht sich * immer auf den linken Nachbarn : die Suchanfrage Haus* liefert in der Simple query bekanntlich alle Wörter, die mit „Haus“ beginnen, in der CQL jedoch „Hau“, „Haus“, „Hauss“, „Haussss“ etc., also „Hau“ gefolgt von 0, 1, oder beliebig vielen s, da sich der „*“ in der CQL auf das vorhergehende Element – hier ein „s“ – bezieht.
Will man ein Suchverhalten wie in der Simple query erreichen, muss die Abfrage in der CQL wie folgt lauten: [word="Haus.*"]

„+“ : steht für 1 oder beliebig viele Wiederholungen des vorhergehenden Zeichens oder Ausdrucks.

z.B.

  • [word="Hurra+"] findet „Hurra“ „Hurraa“ … „Huraaaaaaaaaaa“ … aber nicht „Hurr“

D.h., ein Zeichen vor ‚*‘ ist optional, ein Zeichen vor ‚+‘ hingegen ist obligat!

„?“ : steht für 0 oder genau 1 Wiederholung des vorhergehenden Zeichens oder Ausdrucks, d.h. es steht für Optionalität, aber nicht für Wiederholungen.

z.B.

  • [word="das?"] findet genau „da“ und „das“

Kombination mit .: Üblich ist es, *, +, ? mit . (dem beliebigen Zeichen) zu kombinieren.

  • [word=".?und"] findet und, Mund, Hund, wund, rund, …
  • [word="Hunde.+"] findet Hundehütte, Hundkuchen, Hundefriseur aber natürlich auch Hunderttausend …
  • [pos="N.Reg.*Pl.*"] findet alle Nomen im Plural

Wiederholungen

Alternativ zu *, +, ? kann mit dem ranges Operator nicht nur festgelegt werden, ob ein Ausdruck 0, 1 oder „öfter“ wiederholt werden soll, sondern es kann eine genaue Mindest- und Maximalzahl spezifiziert werden.

Die Syntax dafür ist:

{minimal number, maximal number}

{0,1} minimal 0 maximal 1 (entspricht ?)

z.B.

  • [word=".{10}"] genau 10 Wiederholungen von „.“ – also alle Wörter oder Zahlen mit Länge 10
  • [word=".{10,}"] mindestens 10 Wiederholungen von „.“ , keine Angabe der Maximalzahl: also alle Wörter oder Zahlen mit Mindestlänge 10
  • [word=".{10,15}"] mindestens 10, maximal 15 Wiederholungen
  • [posTT="ADJ."]{2,} Abfolge von mindestens 2 Adjektiven (ADJ. findet sowohl ADJA als auch ADJD, d.h. attributive und prädikative/adverbiale Adjektive)

Logische Verknüpfungen

Es stehen die logischen Operatoren & (logisches UND) und | (logisches ODER) zur Verfügung.

A | B logisches oder : es muss zumindest Bedingung A oder Bedingung B erfüllt sein.

  • [word="Das|das"] finde alle Das oder das Token
  • [pos="ADJA|ADJD|ADV"] finde alle Ajdektive oder Adverben

A & B logisches und : es muss sowohl Bedingung A als auch Bedingung B erfüllt sein.

  • [word="schön" & posTT="ADV" & pos="ADV.*"] finde „schön“, wenn sowohl der TreeTagger (posTT) als auch der RFTagger (pos) es als Adverb markiert haben.

Gruppierung mit ( )

In regulären Ausdrücken können einzelne Komponenten mit ( ) zu Unterausdrücken zusammengefasst werden, die dann wiederum mit * ? + | & kombiniert werden können.

  • [word="(Das|das)"] finde alle Das oder das Token
  • [word="(D|d)as"] finde alle Das oder das Token
  • [word="(Das|das)+"] finde alle Wiederholungen von Das oder das Token: Das, das, DasDas, dasdas, …

Vergleichsoperatoren

Der häufigste Vergleichsoperator ist = (‚equalitiy‘) den wir bereits in allen bisherigen Beispielen verwendet haben.
Darüberhinaus gibt es aber auch negation != und die arithmetischen Vergleiche <= (kleiner gleich) und >= (größer gleich)

  • [word="Haus" & posTT != "NN"] Alle Fundstellen für „Haus“, die vom TreeTagger nicht als Nomen markiert wurden.

Regex auch auf Token-Ebene

Die Operatoren für reguläre Ausdrücke können nicht nur auf den Inhalt von Token-Attributen angewendet werden, sondern auch auf ganze Token oder Abfolgen von Token:

[word="ein"] [pos="ADJ.*"]* [word="Haus"] findet „ein“ und „Haus“ mit beliebig vielen optionalen Adjektiven dazwischen: ein Haus, ein schönes Haus, ein schönes großes Haus …

[lemma="schön"] []{0,4} [word="Haus"] findet „schön“ gefolgt von Haus – in einem Abstand von maximal 4 Token. (Zur Erinnerung: ein [] passt auf jedes beliebige Token.)

([lemma="schön"]|[lemma="groß"]) [lemma="Haus"] findet „schön“ oder „groß“ + „Haus“. (und ist äquivalent zur Anfrage [lemma="schön|groß"] [lemma="Haus"])

Gleichzeitiges Suchen im linken und rechten Kontext: meet und union

Bisher konnten wir nur entweder im linken oder im rechten Kontext suchen. Mit meet kann in beiden Kontexten gesucht werden:

(meet [TokenA] [TokenB] -linker_context rechter_context)

Sucht nach [TokenA] in deren linken oder rechten Nachbarschaft ein [TokenB] zu finden ist. Was als „Nachbarschaft“ gilt, wird dabei über die Zahlen in -linker_context und rechter_context bestimmt.

z.B.: Suche nach dem Lemma „Hund“ in dessen linken oder rechter Umgebung — im maximalen Abstand von 5 Token, die Lemmas „beißen“ oder „bissig“ stehen.

(meet [lemma="Hund"] [lemma="(beißen|bissig)"] -5 5)

Suche auf STRUKTUREBENE in CQL

Sowohl bei der Simple query als auch bei den bisherigen Beispielen der CQL blieben Informationen auf der Strukturebene (Dokumente, Absätze, Sätze) unberücksichtigt. Hier wird nun gezeigt, wie auf und mit Strukturinformationen gesucht werden kann.

Wie oben gezeigt, werden Struktur-Informationen in den Input-Daten für die SKE mithilfe von XML-Elementen kodiert.

In HTML und XML gelten die folgenden Notationskonventionen:

  • <s> Beginn-tag einer Struktur „s“ (also eines Satzes)
  • </s> End-tag einer Struktur
  • <s/> Die gesamte Stuktur von Beginn bis Ende.

Mit dieser Kodierung arbeiten wir auch in der Suchabfragesprache CQL.

  • <doc /> Findet alle (Zeitungs)Artikel
  • <doc> Findet alle Artikelanfänge
  • <doc> [] Findet das erste Token jedes Artikels
  • [] </doc> Findet das letzte Token jedes Artikels

Strukturen können wie folgt nach Attributwerten gefiltert werden:

  • <doc id="xxx"/> Artikel mit der id „xxx“
  • <doc docsrc="STANDARD" & year="2017"/> Artikel aus der Zeitung „Der Standard“ aus dem Jahr 2017
    (beachten Sie, dass ein logisches & verwendet werden muss)

Und auch hier können in den Abfragen wiederum reguläre Ausdrücke verwendet werden, auf gleiche Weise wie es oben für den Inhalt von Token-Attributen demonstriert wurde:

  • <doc year="199."/> alle Artikel aus den 1990ern
  • <doc year="199(8|9)"/> alle Artikel aus 1998 oder 1999

within / containing

Mit containing und within können Bedingungen auf Strukturen und auf Token miteinander kombiniert werden:

containing : wird verwendet um Einschränkungen auf Strukturen auszudrücken: es wird nach Strukturen gesucht, die bestimmte „Dinge“ enthalten.

z.B. alle Sätze, aber nur, wenn sie das Wort „Haus“ beinhalten:

< s/> containing [word="Haus"]

within : wird verwendet um Einschränkungen auf Token auszudrücken: es wird nach Token gesucht, die sich in bestimmten Strukturen finden.

z.B. alle Fundstellen für „Haus“, aber nur, wenn sie in einem Artikel des „STANDARD“ stehen, der 2010 oder später erschienen ist.

[word="Haus"] within <s docsrc="STANDARD" year>="2010"/>

Aber auch die Verwendung von Negation (not) ist möglich:

z.B. finde ‚Haus‘ aber nicht im STANDARD des Jahres 2017:

[word="Haus"] not within <s docsrc="STANDARD" year="2017"/>

Tipps & Tricks

Vereinfachte Schreibweise

In der Suchmaske steht neben dem Feld CQL die Angabe eines Default attribute. Bei Abfragen auf dieses Attribut kann die Schreibweise [attribut="value"] zu "value" vereinfacht werden. Dabei ist „word“ quasi der Default des Defaults. Es gilt also:

  • statt [ word="Paradeiser" ] gilt vereinfacht: "Paradeiser" (die doppelten Hochkomma bleiben aber verpflichtend!)

Bei einfachen Abfragen ist das eine willkommene Schreiberleichterung. Bei komplexeren Suchen, bei denen auf mehr als nur ein Attribut getestet werden soll, muss dann aber wieder auf die „Langform“ zurückgegriffen werden.

CQL Builder

Unter dem Eingabefeld für CQL findet sich auch ein Link namens CQL builder – ein Tool, das bei der Formulierung von CQL-Anfragen helfen kann. Es kann durchaus sinnvoll sein, mit diesem Tool mit dem bisher erworbenen Wissen zu experimentieren, auch um weitere Funktionen zu entdecken, für deren Erläuterung auf die offiziellen Hilfeseiten der SketchEngine verwiesen werden muss.

Escaping von Sonderzeichen

Da die Zeichen . + * & | ( ) [ ] in den CQL Abfragen eine Sonderbedeutung als Bestandteile regulärer Ausdrücke haben, müssen sie speziell gekennzeichnet werden, wenn man buchstäblich nach Ihnen suchen will.
Dieses Aufheben der Sonderbedeutung nennt man escapen eines Zeichens, und passiert durch Voranstellen eines ‚\‘ (backslash)

D.h.

  • [word="etc."] hier steht „.“ für jedes beliebige Zeichen
  • [word="etc\."] hier steht „.“ tatsächlich für einen Punkt (.)
  • [word="..."] findet daher alle Token mit 3 Zeichen
  • [word="\.\.\."] findet „punktipunktipunkti“

Tokensuche ignoriert Strukturgrenzen!

Standardmäßig werden Strukturgrenzen in der Suchanfrage vollständig ignoriert! Wenn sie nicht explizit angegeben werden, bleiben Strukturen für die CQL also quasi unsichtbar.

D.h.

  • [] [] findet alle benachbarten Token, selbst wenn dazwischen eine Strukturgrenze liegt.
  • [posTT="ADJ.*"] [posTT="NN] würde also alle Adjekiv-Nomen-Kombinationen finden, auch über Satz-, Paragraphen- und sogar über Dokumentgrenzen hinweg!

Abhilfe schafft hier nur die Verwendung von within :

  • [posTT="ADJ.*"] [posTT="NN] within <s/> beschränkt die Suche auf Fundstellen die sich innerhalb ein- und desselben <s/>, also innerhalb eines Satzes, befinden, was in den meisten Fällen wohl das erwünschte und sinnvolle Suchverhalten sein sollte.

Attribute mit „MULTIVALUE“

In der SKE können Attribute als MULTIVALUE definiert werden. Das bedeutet, das Attribut enthält potenziell mehrere Werte, die durch ein Trennzeichen (MULTISEP) voneinander abgegrenzt werden. Das ist im amc bei vielen Attributen des <doc>-Elements der Fall. So könnte z.B. kann das Attribut mutation eine Wert "Länder,Abend,Morgen" aufweisen: es ist ein MULTIVALUE-Attribut, das Kommas (‚,‘) als MULTISEP verwendet.

Für die Suche hat das die Konsequenz, dass der Inhalt des Attributs automatisch in seine Einzelwerte aufgegliedert und einfach nach den Einzelwerten gesucht werden kann, es bleibt aber auch der unveränderte Originalinhalt durchsuchbar.
Um beim Beispiel zu bleiben: ein <doc mutation="Wien,Abend,Morgen" .../> würde mit jeder der folgenden Suchanfragen gefunden werden:

  • mutation="Wien"
  • mutation="Abend"
  • mutation="Morgen"
  • mutation="Wien,Abend,Morgen"
  • mutation=".+,Abend,.+"

Anmerkung: Ein Nebeneffekt dieser automatischen Aufteilung von MULTIVALUE-Attributen in ihre Einzelwerte ist allerdings, dass es bei Frequenzauswertungen zu Mehrfachzuordnungen kommt.
Eine Auswertung der Anzahl der <doc> pro mutation liefert in unserem Beispiel:

  • Wien : 1
  • Abend : 1
  • Morgen : 1
  • Wien,Abend,Morgen : 1

Übersicht über die vorhandenen Attribute

Um sich einen Überblick über den Namen und den Inhalt der vorhandenen Attribute zu machen ist z.B.
der Menüpunkt Corpus info hilfreich. Hier werden nicht nur statistische Daten über das Korpus angezeigt, sondern auch die Namen der verfügbaren Token-Attribute, Strukturen und Struktur-Attribute.
Um zu den Struktur-Attributen zu gelangen, einfach auf den Namen der entsprechenden Struktur klicken.

Anzeige anpassen

Nach einer Suche kann im Punkt View Options die Anzeige angepasst werden. Hilfreich ist, dass hier die Anzeige einzelner Attribute oder Strukturen ein- oder ausgeblendet werden kann. So kann man z.B., um sich wieder einmal zu erinnern, wie die Werte des pos-Attributs bei Nomen aufgebaut sind, nach einem Nomen suchen, und dann in den View Options das Attribut pos auf sichtbar schalten. So kann man sich ein Attribut anhand exemplarischer Beispiele erschließen.

In View Options kann auch angegeben werden, ob die ausgewählten Attribute nur für den eigentlichen „Treffer“ (meist die beste Wahl) oder für alle Wörter der KWIC-Liste angezeigt werden sollen.

Weiters besteht die Option, die ausgewählten Attribute as tooltips, d.h. nur bei mouse over anzuzeigen.

Frequency lists

Nach einer erfolgten Suche können die Suchergebnisse unter dem Menüpunkt Frequency List übersichtlich(er) zusammengefasst werden. Das ist oft auch hilfreich, um die Korrektheit einer Suchanfrage zu überprüfen.
Bei der Analyse größerer Treffermengen kann es auch hilfreich sein, eine Frequenzliste des linken oder rechten Nachbarn des Suchworts erstellen zu lassen (Auswahl von 1L bzw. 1R). So lassen sich sehr oft „auffällige“ Muster gut isolieren. Zum Beispiel liefert eine Suchanfrage nach der informellen Grußform „baba“ ([lc="baba"]) ca. 10.000 Treffer. Erstellt man eine Frequenzliste der linken Nachbarn von „baba“, so sticht an erster Stelle das Wort „Ali“ mit ca. 1.800 Ergebnissen hervor, weil eben „Ali Baba“ eine hochfrequente Wortfolge ist, die so einfach aus dem Gesamtzählergebnis exkludiert werden, oder bei der Verfeinerung der Suchanfrage berücksichtigt werden kann.

Einschränkungen der Metadaten ohne CQL Struktursuche

Wir haben gesehen, dass in der CQL oft Strukturelemente einbezogen werden, um die Suche nach bestimmten Kriterien in den Metadaten einzuschränken.

z.B. [word="Haus"] within <s docsrc="STANDARD|PRESSE" year>="2010"/> („Haus“ in STANDARD- oder PRESSE-Artikeln, die 2010 oder später erschienen sind.)

Alternativ können einfache Einschränkungen auf Basis der Metadaten (also auf Basis der Strukturattribute des <doc>-Elements) auch im SKE user-interface vorgenommen werden.
Dazu dient in der Suchmaske der Unterpunkt Text Types, wo die Suche auf <doc> mit spezifischen Attributwerten eingeschränkt werden kann.
Abgesehen davon, ist die dortige Auflistung der Attribute und ihrer möglichen Werte auch bei der Formulierung von CQL-Anfragen durchaus hilfreich, wenn man gerade wieder einmal nicht weiß, wie die Attributnamen genau lauten und welche Werte sie annehmen können.

Weiterführende Links & Referenzen

allgemein zu SKE und Suche

speziell zum amc

Tagsets

Kompakte Übersicht

Detailierte Beschreibungen

De-facto wurden alle für das amc verwendeten PoS-Tagger auf dem TIGER Korpus trainiert.

https://www.ims.uni-stuttgart.de/forschung/ressourcen/korpora/tiger/

Ausführliche Dokumentationen der Annotations-Konventionen für das TIGER Korpus finden sich hier:
http://www.ims.uni-stuttgart.de/forschung/ressourcen/korpora/TIGERCorpus/annotation

Insbesondere relevant für das amc sind: