FPO: Factoids

In FPO this part of the FPO structure, which is about assertions and factoids, is perhaps the central part of what defines “factoid prosopography”. It is represented by the set of classes shown below (and taken from the general FPO structure diagram shown here):

 

fpo-factoids

This structure is the most complex of any shown in FPO and might need careful study. Much of the complexity is expressed through subclassing. However, this area also makes non-trivial connections to the complex area of historical dating, and we suggest that the reader should also pay attention to the several different relationships between Assertions / Factoids and dates (or date ranges), which reflects the different kind of dates that might need to be specified.  From experience in CCH/DDH, these different dates often provided a source for confusion between ourselves and our historian partners.

Classes

  • :Assertion: In the factoid prosopography model, the central structural element in the model is the set of assertions made about historical people.
  • :Factoid: A factoid is a kind of prosopographical assertion that centers on statements made by an historical source.  It is a structured interpretation of something that an historical source says about an individual.
    Note that :Factoid has two direct subclasses, because it became useful to recognise that there were two overall types of factoids that turned up.
  • :EventFactoid: This is one of the two direct subclasses of :Factoid mentioned earlier. Historical sources often describe historical events, and since events involve people, they are important in prosopography. Events often involve multiple persons, each one with possibly different roles in the event.
  • :Transaction: Since several of the CCH/DDH prosopographies had a large number of legal charters as historical sources, it became useful to recognise a :Transaction as an important subclass of an :EventFactoid.  The kind of transactions represented here, then, were (usually) legal or para-legal events that involved the exchange of various kinds of possessions.
  • :StateOfAffairsFactoid: The second major subclass of Factoids found useful in CCH/DDH factoid projects were “state of affairs” factoids. A StateOfAffairsFactoid is an interpretation of a statement in an historical source that the source claims represents a then-current state of affairs.  An identification of Alfred as King, for example, in a source means that the source indicates that the state of affairs at the time being represented by that sourcewas one that had Alfred as king at the time. Many of these “state of affairs” factoids involved further structure, not shown here, which linked an instance to an item in an authority list.  “King”, for example, would be an entry in a project’s Types Of Status authority list, and the assertion that Alfred was King would be made by creating a suitable State of Affairs Factoid that connected Alfred to this “King” authority term item.

    Many State of Affairs factoids in CCH/DDH prosopographies represented an historical person’s place in their society.  This categorisation certainly applies to :OccupationFactoid, :OfficeFactoid, :TitleFactoid and :StatusFactoid. It is important to understand that no project used all four of these categorisations of status in society.  In particular, some projects used :TitleFactoid for handling status information that, in other DDH projects were considered either status or office terms.

  • :OccupationFactoid: This type of factoid asserted a person’s occupation (such as, say, carpenter). In CCH/DDH projects occupations were maintained as authority lists and the :OccupationFactoid was a way to link one of them to a person.
  • :OfficeFactoid: This type of factoid asserted a person’s office (such as, say, chancellor). In CCH/DDH project’s offices were maintained as authority lists and the :OfficeFactoid was a way to link one of them to a person.
  • :StatusFactoid: This type of factoid was used in PASE, and represented terms that were applied to a person giving their status in society, ranging from low-status terms such as serf or slave to higher status such as knight. In PASE, status terms were maintained as an authority list and the :StatusFactoid was the way to link one of them to a person.
  • :TitleFactoid: Several CCH/DDH projects chose not to record low-status terms, and since they only dealt with high status terms they were unprepared to separate them into Offices or Status titles.  For them, the more general factoid subclass of :TitleFactoid was used.  The titles the project found in their sources were maintained as authority list items and the :TitleFactoid was a way to link one of them to a person.
  • :RelationshipFactoid: All CCH/DDH projects were interested in recording assertions of relationships between people as factoids: things such as “John was son of Keith” or “Harold was lord over Peter”.  Unlike other state of affairs factoids, a :RelationshipFactoid involves two people rather than one.  The two are differentiated through the kind of :Reference that links them to the relationship factoid.  See description of this here. Kinds of relationships were maintained as authority lists, and each CCH/DDH project maintained their own authority list for the of kinds of relationships that interested them. Several categorised relationships further into things like (from PoMS) “Blood”, “Employment”, “Fealty” and “Tenurial” relationships (which, from FPO’s perspective, could be considered either to be subclasses of :RelationshipFactoid, or hierarchical structures in the relationship authority lists themselves).
  • :PossessionFactoid: A possession factoid asserts that a particular object was possessed by someone at a point in time.  Note, therefore, its “State of Affairs” character, and the different relationship it has to possessions than a transaction (and :Transaction) has, which will indicate a change in possession.  Where the nature of possession was possibly complex and different kinds of possession are possible, a project would maintain a list of kinds of possession as authority list, and connect a :PossessionFactoid to one of those to indicate the kind of possession involved.

Properties

Since the Factoid’s character is as an object that acts as a nexus between various objects, this means that the properties that FPO proposes for them are relatively few, since the relationships between factoids and other objects are rather more the places where the primary information lies.

One exception is the :EventFactoid, since the primarily information it held was connected to an historical event itself.  Hence, FPO provides:

  • :hasEventName for :EventFactoid: a short description of the event that this factoid is meant to represent. No DDH/KCL project provided a more elaborate structure to represent an historical event than simply a name for it (although some had more complex structure to represent a Transaction), but it could be imagined that some more elaborate structure could be created for historical events, and that the :EventFactoid could then have a property to link into that.

Relationships

The following relationship properties are defined in FPO for assertions / factoids:

  • :hasReference (from :Assertion to :Reference): provides the path through which (a) a person or persons  or (b) a geographic location can be associated with an assertion / factoid. FPO allows more than one :hasReference relationship to be defined for a single assertion / factoid, thereby allowing more than one person or location to be connected to it. Allowing more than one :Reference is essential for the :RelationshipFactoid, and usually necessary for the :EventFactoid too. As well as providing the mechanism to allow multiple people or locations to be connected to a factoid, :Reference also provides mechanisms, through subclassing, to allow one to define a role for the person in the :Assertion.  In CCH/DDH prosopographies all factoids have at least one link through a :PersonReference to a person.
  • :sourcedFrom (from :Assertion to :SourceCitation): provides the mechanism through which an assertion / factoid is connected to the historical source that provided it. In CCH/DDH prosopographies all factoids had exactly one of these (a link to the source that provided the assertion / factoid.
  • :hasDateAssertionMade (from :Assertion to :DateRange): provides the mechanism for historians to provide a date (or Date Range) when the assertion was made. Note that this is not necessarily the same date associated with the assertion itself.  A source by the Venerable Bede, for example, will generate factoids for events that happened before his work was written.  This is the date in which the assertion was written.  This relationship can be simply omitted if the historians are unwilling or unable to provide it. For CCH/DDH prosopographies only one of these links was made, if any were made at all.
  • :dateForAssertion (from :StateOfAffairsFactoid to :DateRange): provides the mechanism for specifying a date where the source asserts that something was so: when Alfred was King of England, for example. This date is not the same as the one connected to a factoid through :hasDateAssertionMade, which specifies when the assertion itself was made (probably a date associated with the writing of the source). This relationship can be simply omitted if the historians are unwilling or unable to provide it. For CCH/DDH prosopographies only one :dateForAssertion link was made to a factoid, if any were made at all.
  • :occurredOn (from :EventFactoid to :DateRange): provides the date (or date range) when the source asserted that the event happened. The Battle of Hastings, for example, occurred in 1066. This relationship can be simply omitted if the historians are unwilling or unable to provide it. For CCH/DDH prosopographies only one of these links was made, if any were made at all.
  • :involvesPossession (from :Transaction to :Possession): asserts that a particular possession (for CCH/DDH projects usually a piece of land) was involved in a :Transaction. Data models for CCH/DDH projects often allowed more than one possession to be associated with a transaction, since a single transaction often involved more than one possession.
  • :assertsPossessionOf (from :PossessionFactoid to :Possession): asserts that the :PossessionFactoid is referring to a particular :Possession object. Data models for CCH/DDH allowed for only one possession to be associated with a :PossessionFactoid.