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.
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.
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). We find other types of hyperevents linking the published articles to their keywords and editors.
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 for each parent event id defines the type of the generalized hyperevent, in the example the generalized hyperevents all have the type publication. 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 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.
