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
- Grundlagen
- Schnelleinstieg: Suche mit “Simple query”
- Vollsuche: Die Corpus Query Language (CQL)
- Tipps & Tricks
- Weiterführende Links & Referenzen
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
findetSMS
,sms
,Sms
etc.) - entspricht die Sucheingabe auch einem Lemma, dann auch alle Flexionsformen dieses Lemmas. (D.h. eine Suche nach
Haus
findetHaus
,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 mitHaus
beginnen. Es wird also z.B. auchHä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) undhaltlose
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 sowohlADJA
als auchADJD
, 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 alleDas
oderdas
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
- Concordance Introduction https://www.sketchengine.co.uk/user-guide/user-manual/concordance-introduction/
- Regular Expressions https://www.sketchengine.co.uk/user-guide/user-manual/concordance-introduction/regular-expressions
- Corpus Querying https://www.sketchengine.co.uk/documentation/corpus-querying/
- CQL Basics https://www.sketchengine.co.uk/documentation/cql-basics/
speziell zum amc
Tagsets
Kompakte Übersicht
- Stuttgart-Tübingen-PoS-Tagset (STTS) wie es im PoS-attribut
posTT
verwendet wird- https://www.ims.uni-stuttgart.de/forschung/ressourcen/lexika/germantagsets
(dieser Link findet sich auch in der SKE selbst unterCorpus info -> Tagset Description
)
- https://www.ims.uni-stuttgart.de/forschung/ressourcen/lexika/germantagsets
- Tagset des RFTaggers wie es im PoS-attribut
pos
verwendet wird:
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:
- „A Brief Introduction to the TIGER Treebank“
- http://www.ims.uni-stuttgart.de/forschung/ressourcen/korpora/TIGERCorpus/annotation/tiger_introduction.pdf
- Note: die minimalen Adaptionen des STTS Tagsets finden sich im Appendix Appendix A2 A.2 Deviation from STTS in the TIGER Treebank
- „TIGER Morphologie-Annotationsschema“ : Beschreibung der kombinierten PoS plus Morphoplogie-tags in
pos
: