Performs a collocation analysis for the given node (or query) in the given virtual corpus.
# S4 method for KorAPConnection
collocationAnalysis(
kco,
node,
vc = "",
lemmatizeNodeQuery = FALSE,
minOccur = 5,
leftContextSize = 5,
rightContextSize = 5,
topCollocatesLimit = 200,
searchHitsSampleLimit = 20000,
ignoreCollocateCase = FALSE,
withinSpan = ifelse(exactFrequencies, "base/s=s", ""),
exactFrequencies = TRUE,
stopwords = append(RKorAPClient::synsemanticStopwords(), node),
seed = 7,
expand = length(vc) != length(node),
maxRecurse = 0,
addExamples = FALSE,
thresholdScore = "logDice",
threshold = 2,
localStopwords = c(),
collocateFilterRegex = "^[:alnum:]+-?[:alnum:]*$",
minObservedExpectedRatio = 1,
queryMissingScores = FALSE,
missingScoreQuantile = 0.05,
vcLabel = NA_character_,
cacheAs = NULL,
...
)A tibble where each row represents a candidate collocate for the requested node. Columns include (depending on the selected association measures):
node, collocate, vc, label: identifiers for the query node, collocate, virtual corpus, and optional label.
Frequency and contingency information such as frequency, O, O1, O2, E, leftContextSize, rightContextSize, and w.
Association measures (e.g. logDice, ll, mi, ...), one column per requested scorer.
Per-labelled association scores produced by multi-VC comparisons using the pattern <measure>_<label>.
Ranks per label/measure with the pattern rank_<label>_<measure> (1 is best) and the corresponding percentile ranks percentile_rank_<label>_<measure>.
Pairwise contrasts for two-label comparisons, e.g. delta_<measure>, delta_rank_<measure>, and delta_percentile_rank_<measure>.
Summary columns describing the strongest labels per measure (winner_*, runner_up_*, loser_*, and max_delta_*), including winner/loser webUIRequestUrl columns. In multi-VC comparisons, missing per-label concordance URLs are derived from another available row URL for the same node/collocate by replacing the cq parameter with the target label's virtual corpus. Unsuffixed winner_webUIRequestUrl and loser_webUIRequestUrl columns are populated only when the score-based URL choices agree.
imputed_<label>: whether the score for that label was imputed rather than observed (see missingScoreQuantile). n_imputed counts them, and imputed is n_imputed > 0: it describes the node/collocate pair across all labels, not the label of the row it stands in. A row can therefore carry imputed = TRUE while its own scores are perfectly attested, because the pair is missing from some other virtual corpus - use imputed_<label> for the row itself. Filter with dplyr::filter(!imputed) to keep only collocates attested in every compared virtual corpus.
Optional helper columns such as query, example, or url when example retrieval is requested.
KorAPConnection() object (obtained e.g. from KorAPConnection()
target word or query as a single character string
character vector describing the virtual corpus or corpora in which the query should be performed. An empty string (default) means the whole corpus, as far as it is license-wise accessible.
if TRUE, node query will be lemmatized, i.e. x -> [tt/l=x]
minimum absolute number of observed co-occurrences to consider a collocate candidate
size of the left context window
size of the right context window
limit analysis to the n most frequent collocates in the search hits sample
limit the size of the search hits sample
logical, set to TRUE if collocate case should be ignored
KorAP span specification (see https://korap.ids-mannheim.de/doc/ql/poliqarp-plus?embedded=true#spans) for collocations to be searched within. Defaults to base/s=s.
if FALSE, extrapolate observed co-occurrence frequencies from frequencies in search hits sample, otherwise retrieve exact co-occurrence frequencies
vector of stopwords not to be considered as collocates
seed for random page collecting order
if TRUE, node and vc parameters are expanded to all of their combinations
apply collocation analysis recursively maxRecurse times
If TRUE, examples for instances of collocations will be added in a column example. This makes a difference in particular if node is given as a lemma query.
association score function (see association-score-functions) to use for computing the threshold that is applied for recursive collocation analysis calls (only applied when maxRecurse > 0)
minimum value of thresholdScore function call to apply collocation analysis recursively (only applied when maxRecurse > 0).
Note that the default score, logDice, expresses how salient a pair is
rather than how surprising, so that a frequent collocate can pass it while
co-occurring less often than expected. minObservedExpectedRatio keeps
those out. See the "Salience versus surprise" section of
association-score-functions.
vector of stopwords that will not be considered as collocates in the current function call, but that will not be passed to recursive calls
allow only collocates matching the regular expression
minimum ratio of observed to expected co-occurrence
frequency a collocate must reach. Defaults to 1, which keeps only collocates
that occur at least as often as expected by chance, corresponding to a
non-negative pmi. Without it, frequent words can end up among the top
collocates by logDice although the node does not attract them at all (see
the "Salience versus surprise" section of
association-score-functions). Raise it to demand a stronger
contrast, e.g. 2 for collocates occurring at least twice as often as
expected, or set it to 0 to switch the filter off and obtain the unfiltered
result of earlier versions, e.g. in order to study repulsion.
if TRUE, attempt to retrieve corpus-based association scores for vc/collocate combinations that would otherwise be imputed, by re-querying the KorAP backend without applying the collocate frequency threshold
lower quantile (evaluated per association measure over the pooled result set) that anchors the adaptive floor used for imputing missing scores between virtual corpora; a robust spread is subtracted from this anchor so the imputed values stay at or below the weakest observed scores. Imputed cells are marked in the imputed* columns; see the section on interpreting multi-VC comparisons below
optional label override for the current virtual corpus (used internally when named VC collections are expanded)
path to an RDS file to keep the result in. If the file exists and records the same call, it is read back instead of contacting the server; otherwise the query is run and its result stored there. Unlike the connection's cache, this file belongs to the caller, which is what keeps an analysis reproducible once the corpus has grown or the scores have changed. Defaults to NULL (no file).
The analysis parameters are stored alongside the result. If they differ from
those of the current call, the cached result would not be the one that was
asked for, so it is recomputed and the file overwritten, with a warning
naming the parameters that differ. Pass a different cacheAs file name
to keep an existing analysis. Cache files written by RKorAPClient 1.3.0 do
not contain the parameters yet and are used as they are.
more arguments will be passed to collocationScoreQuery()
The comparison columns produced when vc holds more than one virtual corpus
are experimental: their names and semantics may still change in a future
release without a deprecation cycle. Code that has to keep working across
versions should select the columns it needs explicitly.
They are an exploration aid, not a significance test. When reading them, keep three properties in mind.
Imputed scores describe presence/absence, not contrast. A collocate
that passes the minOccur and topCollocatesLimit thresholds in one virtual
corpus but not in another has no observed score for the latter. Such cells are
imputed from a floor derived from the pooled result set (see
missingScoreQuantile), so the corresponding delta_* and max_delta_*
values measure the distance to that floor rather than an attested difference.
The imputed, n_imputed and imputed_<label> columns mark these rows;
dplyr::filter(!imputed) restricts the result to collocates attested
everywhere, and queryMissingScores = TRUE replaces most imputed cells with
scores actually retrieved from the backend. Mind what imputed is about: the
pair, not the row. It is TRUE as soon as one label lacks the collocate, and
stays TRUE on the rows of the labels where it is attested, which is what
makes dplyr::filter(!imputed) drop the pair as a whole. Whether the row at
hand rests on an imputed score is what imputed_<label> says.
Per-label columns carry syntactic names. The label in
<measure>_<label>, rank_<label>_<measure> and imputed_<label> is the one
the caller gave, put through make.names(), so that the result stays a well
formed data frame: a virtual corpus named 1976-1980 appears as
logDice_X1976.1980. The label column and the winner_* / loser_*
columns keep the name as it was given, so mapping between the two means
applying the same transformation, e.g.
stats::setNames(make.names(labels), labels).
Imputed values are relative to one analysis. The floor is computed from the scores present in the result at hand. Analysing a node on its own and analysing it together with other nodes therefore yield different imputed values, and deltas involving imputed cells are not comparable across separate calls. Deltas between observed scores are unaffected.
Winners carry no uncertainty. Unlike ci(), which attaches
confidence intervals to relative frequencies, the winner_* / loser_*
columns simply order point estimates. A collocate wins by a hair on six
occurrences exactly as decisively as one that wins by a wide margin on
thousands. Consult the observed frequencies (O, O1, O2) and the
webUIRequestUrl concordance links before drawing conclusions from a
small difference.
Note also that rank_<label>_<measure> and
percentile_rank_<label>_<measure> are computed within each label, over that
label's own candidate set. Candidate sets usually differ in size between
virtual corpora, so rank-based deltas compare positions in populations of
different sizes.
The collocation analysis is currently implemented on the client side, as some of the functionality is not yet provided by the KorAP backend. Mainly for this reason it is very slow (several minutes, up to hours), but on the other hand very flexible. You can, for example, perform the analysis in arbitrary virtual corpora, use complex node queries, and look for expression-internal collocates using the focus function (see examples and demo).
To increase speed at the cost of accuracy and possible false negatives, you can decrease searchHitsSampleLimit and/or topCollocatesLimit and/or set exactFrequencies to FALSE.
Note that some outdated non-DeReKo back-ends might not yet support returning tokenized matches (warning issued). In this case, the client library will fall back to client-side tokenization which might be slightly less accurate. This might lead to false negatives and to frequencies that differ from corresponding ones acquired via the web user interface.
Other collocation analysis functions:
association-score-functions,
collocationScoreQuery,KorAPConnection-method,
synsemanticStopwords()
if (FALSE) {
# Find top collocates of "Packung" inside and outside the sports domain.
KorAPConnection(verbose = TRUE) |>
collocationAnalysis("Packung",
vc = c("textClass=sport", "textClass!=sport"),
leftContextSize = 1, rightContextSize = 1, topCollocatesLimit = 20
) |>
dplyr::filter(logDice >= 5)
}
if (FALSE) {
# Identify the most prominent light verb construction with "in ... setzen".
# Note that, currently, the use of focus function disallows exactFrequencies.
KorAPConnection(verbose = TRUE) |>
collocationAnalysis("focus(in [tt/p=NN] {[tt/l=setzen]})",
leftContextSize = 1, rightContextSize = 0, exactFrequencies = FALSE, topCollocatesLimit = 20
)
}
Run the code above in your browser using DataLab