The justifier package offers a flexible compromise that
enables thorough documentation that is both human- and machine-readable.
This allows learning from the decisions taken in one or multiple
projects, and making clear where decisions were based on strong versus
weak justifications. What exactly comprises a strong or weak
justification is of course greatly dependent on domain and context, and
justifier provides for this. Justification frameworks for
two specific cases have been provided in the vignettes ‘justifier in
behavior change intervention development’ and ‘justifier in study
design’. This vignette provides a general introduction to
justifier.
In justifier, four types of information are
distinguished:
source: A source is a document or other
resource the contains more information about something. Commonly,
sources will be journal articles, books, or reports, but
they can be anything really.assertion: An assertion is a statement
that something is the case. An assertion will, if possible,
be based on one or more sources. In justifier,
an assertion is very similar to assertions in
the nanopublication
ontology, in which case one could compare the
assertion’s description plus the referenced
sources or other justifer elements as its
provenance.justification: A justification is a
justification of something or other. Generally,
justifications will be used to justify
decisions, but sometimes, you may want to justify something
without it being tied to a specific decision.decision: A decision is an explicit choice
between one or more implicit or explicitly listed options. A
decision should have one or more
justifications which are each ideally based on one or more
assertions that each reference one or more
sources.These justifier elements are specified in YAML fragments
in plain-text files, that as convention have the extension
jmd (‘justifier markdown’). This enables including
justifications right in one’s minutes or meeting notes without having to
use dedicated software - the only constraint this introduces is that one
has to use Markdown for those minutes or notes. Markdowns combination of
using a plain text format while allowing embedding of basic markup
metadata (and the ability to extend that using HTML), and its popularity
to produce reproducible reports and literature prorgamming documentation
using the R Markdown framework, make Markdown an obvous choice for
documentation if one desires to adhere to Open Science principles.
The justifier package offers functions to extract and
load these YAML fragments. This, of course, in itself doesn’t have any
added value. This added value is introduced by parsing the
justifier elements in a specific context where, for
example, the types of decisions can be organised hierarchically, and
types of evidence can be ranked, to provide insight into the decisions
in different phases or a process or in different projects in an
organisation.
To this end, justifier work with the concept of
justification frameworks. These frameworks provide the
context for the decisions and justifications. The
justification frameworks, therefore, enable one to extend
the justifier format to attach context to decisions, for
example in terms of which part of a process they pertain to, or in terms
of what part of the world they relate to. These contexts or domains are
hierarchically structured within the
justification framework. In addition to their position in
the wider framework, each context can specify constraints for decisions
in that context. When justifier processes a set of
justifications in this framework, it will notice violations of this
specification. Such values can achieve additional attributes, such as
scores, ranks, or strings with comments. These attributes can then be
aggregated for all justifications in a domain, or collapsed to lower
levels of the context tree. This makes
justification frameworks ‘judgemental’, where
justifications in themselves are not judgemental; they simply document.
However, when placed in a context, such justifications can be
categorized as better or worse using the metadata provided by the
justification framework.
For example, imagine a social activity committee at a faculty at a
university somewhere in the world. Since social cohesion is an important
factor in staff happiness, it would make sense that such a vital organ
as the social activity committee would decide to document their minutes
using justifier, after all. In a meeting, they could decide
to organise the next annual faculty outing as a bowling match, and to
not include dinner, but include lunch. The underying reasoning could be
that last year, there was a non-sporty activity, and the dinner got
quite out of hand. These choices therefore cater to people’s perceived
need for variation and hopefully avoid embarrassing (but fun) scenarios
like those witnessed last year.
By imposing a justification framework, one could, for
example, attach a ‘decision quality’ value to these decisions. Imagine a
framework for a faculty that values democracy very highly. In this
framework, decisions’ justifications pertaining to the context of
‘activity’ have to have one of three values: ‘survey under staff’,
‘discussion at staff meeting’, or ‘internally generated’. It is then
possible to easily generate overview of types of justifications in
different meetings. For example, it could, hypothetically, turn out to
be the case that decision bodies at higher levels make more internally
generated decisions, whereas decisions at lower levels are more often
based on discussions with staff members.
Two examples of such frameworks are provided in the ‘justifier in behavior change intervention development’ and ‘justifier in study design’ vignettes.
For example, when designing an empirical study, some form of data will often be gathered. In the design phase, therefore, decisions are taken as to the amount of data that will be required. These decisions share a role in the study design process, and once such context is clear, further specification of the decisions becomes possible. For example, for quantitative studies in psychology, a decision could pertain to whether sample size calculations are based on a frequentist approach, such as on null hpothesis significance testing, accuracy in parameter estimation, or a Bayesian approach.
For example, a framework could contain a context called
study type that specifies that decisions in that context
can only have one of two values: “confirmatory” or “exploratory”.
In addition, the relative contextual information enables collapsing the justifi
Justification frameworks can be specified in three ways. First, using YAML stored in a local file; second, using a spreadsheet stored in a local file; and third, using a spreadsheet loaded from Google Sheets. Of these,
In justification frameworks, common metadata specifications are the following:
These specifications can pertain either to justifier
specifications within a given domain, but they can also hold for all
justifier specifications that are loaded in a project. For
example, it is possible to specify that all sources must
have a type, and that that type must always be
team belief, expert consensus,
target group consultation, qualitative study,
quantitative study, or research synthesis.
justifier will then flag deviations.
When specifying something for multiple justifications, the eponymous
justifier element can be used, making that the fifth
justifier element. Contents of a justifier
element pertain to all other elements in a file
(scope: local), or in a project directory
(scope: global), or all files that are read by the
justifier package in a project
(scope: universal).
For example, to specify that the justification framework
is stored in file justifier-framework-specification.jmd,
and that this framework should be applied to all justifications in this
directory that do not have another framework attached:
---
justifier:
framework: justifier-framework-specification.jmd
scope: global
---To specify that all justifications in this file are produced at date the sixth of March 2019:
---
justifier:
date: 2019-03-06
scope: local
---The type metadata can be used to impose more constraints
by providing conditions. For example, to specify that all decisions in
the project of the type “global_design” must have either “experimental”
or “observational” as value, one would use:
---
justifier:
scope: universal
condition:
element: decision
type: global_method
values: ["experimental", "observational"]
---justifier will then check the type of all
decisions in the project. If a decision has the type “global_design”,
justifier will check whether whether it has a value and
whether the value is “experimental” or “observational”; if not,
justifier will indicate this.
It is also possible to attach additional attributes to these values, such as scores or weights, by including another vector:
---
justifier:
scope: universal
condition:
element: decision
type: global_method
values: ["experimental", "observational"]
scores: [1, 2]
---