GRHEM first steps (tutorial)
A generalized hyperevent is a time-stamped hyperedge that decomposes into any number of sub-hyperedges, comprising the nodes that occupy a certain event position. An example is given by the publication event of a scientific paper that binds several types of nodes in various positions: the authors of the paper, the cited references, its keywords, the journal in which it is published. Possibly we may also have information on the editor managing the reviewing process. It is plausible that some or all of these positions interact. For example, the references are selected by the authors, but their choice might also be dependent on the paper's keywords, or possibly on the journal or the editor.
Other examples for generalized hyperevents include typed and geo-located co-offending events, as analyzed in this paper. A single event links a group of co-offending actors (first event position), with a set of crime categories (second event position), and a postcode indicating the location of the crime event (third event position). In general, all three positions may interact since actors may have a tendency to commit different types of crime in different locations. Yet another, very different, example is given by scholarly migration events, where an academic (1st position) migrates from a source institution (2nd position) to a target institution (3rd position). It is plausible that such migration events depend on both institutions and their relations (e.g., prior migrations) but also on the academic herself (who may have, e.g., co-authorship or other relations with other academics at the target institution). In general, all positions may interact in explaining such events.
Generalized relational hyperevent models (GRHEM) provide a model family for such generalized hyperevents that can test and control for interactions among any number of event positions. This tutorial attempts to give a first intro to GRHEM. Functionality for GRHEMs is available starting from eventnet two that is, version 2.0 or later, currently available as a pre-release eventnet-2.0-pre-2.jar.
Eventnet two provides extended functionality to model such multi-mode hyperevents. Even if the core interest lies in explaining only one or two event positions, for example, the authors and/or references of published papers, the ability to deal with any number of positions allows to specify and test additional effects. For example, it is likely that papers cite other papers that share some of their keywords with higher probability, or there might be a preference to cite papers previously published in the same journal. However, GRHEM do not only allow to specify more effects explaining, e.g., the selection of authors and/or references, but can also be employed to explain any number of event positions simultaneously. For example, it might be unwarranted in general to assume that the keywords or journal of a paper are pre-determined and only then its authors or references are selected (partly dependent on these keywords or journal). A more realistic assumption is that nodes in all, or at least several, event positions are selected mutually dependent on each other. For example, the selection of references of a paper may depend on its authors, keywords, and journal - but the selection of the keywords, or the journal, may also depend on its authors and references. GRHEM allow to simultaneously explain the selection of nodes in any number of event positions, where these choices may be dependent on nodes selected into any combination of other event positions.
This tutorial provides a first introduction to GRHEM. It is recommended to first read, or be otherwise familiar with, three other RHEM tutorials, in particular: the RHEM first steps tutorial, the tutorial for directed RHEM, and the tutorial for the co-evolution of collaboration and reference networks. This tutorial uses a tiny made-up data set on generalized hyperevents representing paper publication and it illustrates the use of eventnet two with the graphical user interface (GUI). As before, it is also possible to execute eventnet with a given configuration file from the command line (as described here), without opening the GUI, and for larger data sets this is even the recommended way.
The example below uses a tiny made-up data set for generalized hyperevents (ghe_publications.csv), representing two publication events, and an example configuration (ghe_example_config.txt). The config file can be loaded into eventnet (file --> merge into current configuration). Ensure that eventnet is started from the directory containing the data (.csv) file.
To specify a sequence of generalized hyperevents, to be processed with eventnet, we need to extend CSV files by one additional column, giving the parent event id that binds the various sub-hyperedges constituting a generalized hyperevent. We illustrate this by a made-up data set on two paper publication events, each of which gives information on the paper's authors, references, keywords, and editor.
"parent.id","event.id","source","target","time","type"
"parent.id.1","parent.id.1","article.5","article.5","1","publication"
"parent.id.1","parent.id.1.author","article.5","scientist.2","1","author"
"parent.id.1","parent.id.1.author","article.5","scientist.3","1","author"
"parent.id.1","parent.id.1.ref","article.5","article.1","1","reference"
"parent.id.1","parent.id.1.ref","article.5","article.2","1","reference"
"parent.id.1","parent.id.1.ref","article.5","article.3","1","reference"
"parent.id.1","parent.id.1.key","article.5","key.1","1","keyword"
"parent.id.1","parent.id.1.key","article.5","key.2","1","keyword"
"parent.id.1","parent.id.1.key","article.5","key.3","1","keyword"
"parent.id.1","parent.id.1.key","article.5","key.4","1","keyword"
"parent.id.1","parent.id.1.editor","article.5","scientist.1","1","editor"
"parent.id.2","parent.id.2","article.6","article.6","2","publication"
"parent.id.2","parent.id.2.author","article.6","scientist.3","2","author"
"parent.id.2","parent.id.2.ref","article.6","article.1","2","reference"
"parent.id.2","parent.id.2.ref","article.6","article.2","2","reference"
"parent.id.2","parent.id.2.ref","article.6","article.4","2","reference"
"parent.id.2","parent.id.2.ref","article.6","article.5","2","reference"
"parent.id.2","parent.id.2.key","article.6","key.3","2","keyword"
"parent.id.2","parent.id.2.key","article.6","key.5","2","keyword"
"parent.id.2","parent.id.2.key","article.6","key.6","2","keyword"
"parent.id.2","parent.id.2.key","article.6","key.7","2","keyword"
"parent.id.2","parent.id.2.editor","article.6","scientist.2","2","editor"
The columns event.id, source, target, time, and type specify hyperevents as discussed in previous RHEM tutorials (there might also be a column, giving the event weights, which is however not used in this data). For example,
"parent.id.1","parent.id.1.author","article.5","scientist.2","1","author"
"parent.id.1","parent.id.1.author","article.5","scientist.3","1","author"
defines a hyperevent of type author that links the published article (article.5) to its two authors (scientist.2 and scientist.3). The three lines
"parent.id.1","parent.id.1.ref","article.5","article.1","1","reference"
"parent.id.1","parent.id.1.ref","article.5","article.2","1","reference"
"parent.id.1","parent.id.1.ref","article.5","article.3","1","reference"
define a hyperevent of type reference that links the published article (article.5) to its three references (article.1 through article.3). In the example, there are other types of hyperevents linking the published articles to their keywords and editors. Note that the event id (but not the parent event id) for the hyperevents of various types (e.g., author, reference) within a generalized hyperevent has to change with the type of these inner events (for example, those of type author have a different event id than those of type reference).
The additional column parent.id binds together those hyperedges that belong to the same generalized hyperevent. In the example above, there are two different parent event ids, parent.id.1 and parent.id.2, representing the two paper publication events of article.5 and article.6, respectively. The first row(s) for each new parent event id, that is, for each new generalized hyperevent, defines the type of the generalized hyperevent, in the example the generalized hyperevents all have the type publication. For example, the following row starts the first generalized hyperevent of type publication.
"parent.id.1","parent.id.1","article.5","article.5","1","publication"
Crucially, the row(s) indicating the start of a new generalized hyperevent must have an identical string for the event id and for the parent event id (in the row above, this is the string parent.id.1). This is how the parser for the input data recognizes that now starts a new GHE. All subsequent rows that define the inner hyperedges of different types (e.g., author, reference, keyword, editor) within the same GHE must have a different string for the event id and for the parent event id.
In the given example, the nodes representing the generalized hyperevents (that is the published articles article.5 and article.6) appear as the source node in each row with the respective parent event id, linking it to the varying target nodes. It is possible, but not necessary, to encode the data in this way. An alternative would be to represent, say, the authors and references of the paper in the same way as it has been explained for data that just contains information on authors and references of paper; compare this tutorial. In such a coding, the respective rows, replacing the former rows of type author and reference, could look like the following:
"parent.id.1","parent.id.1.ref","scientist.2","article.1","1","author-reference"
"parent.id.1","parent.id.1.ref","scientist.3","article.2","1","author-reference"
"parent.id.1","parent.id.1.ref","scientist.3","article.3","1","author-reference"
The authors (scientist.2 and scientist.3) and references (article.1 through article.3) of that generalized hyperevent would still be linked to the other nodes of the same generalized hyperevent, that is, to the published paper article.5, to its keywords, and to its editor, simply because they all have the same parent event id. It is not even necessary that there is any node representing a generalized hyperevent - although this is useful in the case of paper publication events, since the node representing a published paper becomes a possible reference for subsequent papers.
To define the structure of generalized hyperevents in the eventnet GUI, we first indicate the number of different node types, and their names, in the events tab as shown below.
In our example, we have nodes representing papers, scientists, and keywords. Note that the papers can appear in two different event positions (as the published paper or as the cited paper in the references of another paper) and the scientists can also appear in two positions (as authors or editors of papers). The five different event types (editor, publication, reference, author, and keyword) and the node sets that are linked by them can be specified in the same way as explained in prior RHEM tutorials (see the screenshot above). For example, the events that have the type reference link papers to papers and the events of type author link papers to scientists. Note that events of type publication are the only ones that allow loops since they link the published paper to itself (compare the data snipped above). To define settings specific for generalized hyperevents we have to select a column that defines the PARENT_EVENT_ID, compare the screenshot above. Only if this column is defined, some other settings specific for GHE will become available. (There is another setting for the ROOT_EVENT_ID which is currently unused but will be used in future versions of eventnet.)
We can then define the type (publication in the given example) for generalized hyperevents in the dialog shown the the following image. The dialog opens by clicking on the create generalized event type button.
The name of the GHE type can be selected from the event types defined before. In our example, the only GHE type is publication. Then we can add any number of inner event types to the generalized event type. For each inner type we have to give the name of the event positions that are filled with the source nodes, or with the target nodes respectively, of the given inner type. In the example, the inner type author links the nodes in the position published.paper to the nodes in the position author and the inner type reference links the nodes in the published.paper position to those in the cited.paper position. The names after the pipe symbol (vertical bar |) are the names of the respective node sets.
If some positions are filled with nodes from the same set of nodes (e.g., the positions author and editor, which are both filled with scientists) one may specify that these positions have to be disjoint. (This is needed because eventnet samples non-event generalized hyperedges, associated with the observed GHE and these sampled non-events must satisfy some constraints that are imposed by the given empirical setting.) In the example above we add such disjoint constraints for the position pair published.paper and cited.paper (to prevent that a paper cites itself) and to the position pair author and editor. (The latter is only for the sake of example.) In another setting of GHE representing communication events, we might specify that the positions sender and receiver of a message event have to be disjoint to prevent loops. In yet other settings, different positions may be allowed to overlap. For example, if we have information on author roles (such as conducting the analysis or writing the article) these positions may overlap since the same node (scientist) may play both roles in the same paper publication event.
Regarding event network attributes, storing information on past events, attributes for generalized hyperevent are defined very similarly to those for undirected or directed hyperevents. There is an attribute type DEFAULT_GHE_ATTRIBUTE which can store information on generalized hyperedges and which is needed to define the statistics GHE subset repetition or geometrically-weighted GHE subset repetition. Moreover, there is a new dyad-level attribute DYAD_LEVEL_ATTRIBUTE_FROM_GHE which stores pairwise interaction of nodes in some or all event positions of a GHE. This attribute allows to specify a source position and target position (but also allows not to specify them). If the source position is specified and equal to the target position, then all pairs of nodes within the source position are updated. If the source position is different from the target position, then all pairs linking each node in the source position with each node in the target position are updated. If the positions are unspecified, then all pairs among all nodes in any position are updated.
Eventnet offers several statistics for GHE. The example configuration (ghe_example_config.txt) defines three variants of a GHE_SUB_REPETITION_STAT, the first tests whether authors have the tendency to repeatedly co-cite two or more prior papers in the references, the second tests whether authors have a tendency to repeatedly cite the same prior paper while publishing a paper with a repeated keyword, and the third tests whether there is a tendency to cite prior papers written by the editor of the current paper. The screenshot below illustrates the relevant settings for the cite paper of editor statistic. The position sizes define how many nodes have to be repeated in the respective positions. The cite paper of editor statistic additionally defines a role-switching map requiring that the current publication cites a paper that was published in a prior event and the editor (or one of the editors) of the current publication was among the authors of the same prior publication. For example, in the given data example (ghe_publications.csv) the first publication event (of article.5) has scientist.2 among its authors and scientist.2 is the editor of a subsequent publication event (of article.6) which cites article.5 in its references. The settings for the other statistics can be found in the example configuration.
There are several other types of GHE statistics. The statistic type GHE_STAT_BY_DHE_STAT allows to define a GHE statistic by specifying two positions, which take the role of the sources and targets of a directed hyperedge statistic. The DHE statistic, in turn, has to be defined separately and is referred to via the argument other stat name. By this fallback mechanism it is in principle possible to define any GHE statistic that depends on just one or two event positions (although sometimes it might be more tedious than to directly use, e.g., GHE_SUB_REPETITION_STAT). Another type of GHE statistic is GHE_GW_SUB_REP_STAT which is an alternative to subset repetition that applies a geometrical weighting (see more details here). There is also the GHE statistic family GHE_GW_SUB_REP_STAT_FAMILY which defines a whole vector of GHE statistics. In particular, if this family is defined with
The non-events for a GRHEM are sampled as defined by a GHE observation. Currently there are two types, DEFAULT_GHE_OBS and PERTURB_GHE_OBS. Both allow to specify, separately for each event position, whether the position should be conditioned upon (in the example below, we do not explain the published paper nor its editor, but take these as given), conditioned on the observed sizes (to only compare, say, alternative reference lists, or alternative author teams, of the same sizes as the observed ones), or none of the two, in which case any subset, of any size, of the nodes that may fill the respective position can be sampled. Additionally, a position may be required to be filled with nodes that have a certain node attribute. While DEFAULT_GHE_OBS samples uniformly from the so-defined risk set, PERTURB_GHE_OBS samples via a (typically small) number of update steps in which randomly selected nodes may be removed, added, or replaced by other randomly selected nodes. This perturbation sampler is likely to produce non-events that are much closer to the observed events and that therefore may constitute more plausible counterfactuals for analyzing what distinguishes events from non-events.
Once the configuration for GRHEM is fully specified, it can be executed from the GUI or from a command line. Its output table(s) can then be used to fit models with standard statistical software, e.g., coxph() in the R-package survival, as it is explained in many other tutorials. Thus, GRHEM are not different (to REM or RHEM) from the point of view of the statistical modeling framework - but they allow to specify much more complex effects, interacting any number of event positions, given as hyperedge covariates computed by eventnet.