Agent Role Patterns

Dave Dubin


There are several ways to document the roles agents play in a transaction. The most important factor to consider in choosing from among these approaches is the stakeholder communities with which you plan to share the provenance, and the ontological commitments that govern the vocabularies used by those communities.

The running example illustrating the patterns described below will be a specimen loan scenario, in which an organization loans a physical specimen to a researcher for use in a study. We wish to document the lending organization's role as a lender in this transaction. In all three of the patterns the loan itself is understood to be an event, and we will identify the "Resources" taxon from the CRediT Contributor Roles Taxonomy.


Pattern 1: roles as shared social object instances

The first approach for documenting agent roles is to understand the role as one instance of a class of social objects. This pattern is consistent with the treatment of roles in the PROV data model and vocabulary.

Roles in the PROV data model are attributes of the association between an agent and an event, but since RDF admits only binary relationships, we reify the association as a vertex (the assignment of responsibility) as well as an edge ("was associated with"). The important thing to note about this pattern is that the agent's role is a particular, i.e., an instance of a Role class. A different agent participating in a different transaction might play exactly the same role, using the same identifier for the resources role. For example, some other lening agency could play the very same resources role in the context of other loan events.

Pattern 2: roles as a common class identity

Many communities use vocabularies based in BFO, the Basic Formal Ontology, which has an Aristotelian characterization of roles. On this view, roles inhere within the agents that assume them.

We illustrate this pattern using properties from the VIVO-ISF vocabulary, which takes BFO as a basis. The Resources Role in this example is not an instance or particular, but a class. That is because no role instance can inhere within two different agents. Two agent roles may have the same class identity, but not the same individual identity.

Pattern 3: contingent subclasses

The last example illustrates a third way we can represent contributor roles: as contingent agent subclasses. With this approach, an agent's participation in an event of a particular type licenses the deduction that it has played a particular role. But rather than reifying the role itself, we represent the agent as an instance of a role-specific subclass.

In the running example, being a Resource Provider is understood as a class identity for agents that loan. This class identity is deduced (dashed edge) from the agent's participation in a Resources Provision event. With this pattern, the participation that licenses this inference is not directly associated with the triggering event (as it was in the realization of the BFO role).


As stated earlier, one's choice from among these patterns should be justified based on which stakeholder communities one wishes to cooperate with. But it's not always a matter of chosing one pattern over another: note that in the running example the bare facts are the same, only the interpretations differ. The same database record documenting these facts could be serialized and published according to any or all three of these patterns, as needed.