Persons in Context
Persons in Context, abbreviated as PiCo, is a knowledge model for annotating and publishing person observations from historical sources. A main characteristic of PiCo is the distinction between Person observations (person data as found on a Source) and Person reconstructions (groupings of Person observations, created by the process of matching Person observations). PiCo makes use of existing ontologies where possible and adds its own classes and properties when required.
Persons in Context is developed by the CBG|Center for family history as a successor of the XML standard A2A for annotating historical person data. Cultural heritage institutions in the Netherlands are encouraged to move to PiCo. PiCo was developed in collaboration with technical and domain experts. The first version of PiCo was reviewed by a selected group of Dutch archivists and scientists. PiCo is maintained by the PiCo Maintenance Group.
Activity
The Activity that generated a PersonReconstruction
A Person Reconstruction can either be created by a human researcher or by a software algorithm. In case of a human-made reconstruction, provide information about the time, place and knowledge- input. In case of a software algorithm, provide information about the name, version and configuration settings of the program.
Agent
The agent (person or organisation) that is responsible for the creation of a person reconstruction.
Example of an Agent responsible for an Activity
cbg:reconstruction_activity_01 a prov:Activity ; prov:wasAssociatedWith cbg:reconstruction_agent_01 ; prov:startedAtTime "2024-05-24T00:00:00"^^xsd:dateTime ; prov:endedAtTime "2024-05-24T00:00:00"^^xsd:dateTime . cbg:reconstruction_agent_01 a prov:Agent ; sdo:name "CBG|Center for Family History" ; sdo:url <https://cbg.nl> .
Person
A Person is a human being whose individual existence can somehow be documented.
Container class for Person observation and Person reconstruction. Not to be used directly in PiCo resources.
PersonObservation
A Person observation is a person that can be observed on a Source
A person observation represents how a person is recorded on a Source. Therefore, it must always be related to a source. Person observations closely reflect data as it appears in the source, that is, with the age, occupation, and spelling of the person's name recorded as in the record. A notable exception are dates where the creator of the person observation is encouraged to write down the date according to the YMD ISO 8601 date standard (for example: '1802-07-29'), even though the source probably lists the date in a DMY or MDY format or another calendar entirely. Information on the original entry can be stored using an optional triple.
Schematic overview of a PersonObservation
Schematic overview of a person observation.
Example of two Person Observations from the same source
afr:geboorteregister_1858_po_1 a pico:PersonObservation ; prov:hadPrimarySource afr:geboorteregiser_1858 ; sdo:name "Abe Bos" ; sdo:familyName "Bos" ; sdo:givenName "Abe" ; sdo:birthDate "21 Junij 1858"^^xsd:string ; sdo:birthDate "1858-06-21"^^xsd:date ; sdo:birthPlace "Joure" ; sdo:gender sdo:Male ; pico:hasRole picot_roles:575 ; # child sdo:parent afr:geboorteregiser_1858_po_2, afr:geboorteregiser_1858_po_3 . afr:geboorteregiser_1858_po_2 a pico:PersonObservation ; prov:hadPrimarySource afr:geboorteregiser_1858 ; sdo:name "Sjouke Abes Bos" ; sdo:familyName "Bos" ; sdo:givenName "Sjouke" ; pico:hasAge "30"^^xsd:decimal ; sdo:hasOccupation "klokmakersknecht" ; sdo:address "Joure" ; sdo:gender sdo:Male ; sdo:spouse afr:geboorteregiser_1858_po_3 ; sdo:children afr:geboorteregiser_1858_po_1 ; pico:hasRole picot_roles:489 . # declarant
PersonReconstruction
A Person reconstruction is the result of modelling one or multiple PersonObservation(s) into a single resource.
A Person reconstruction must always refer to one or more Person observations. For this, the prov:wasDerivedFrom property is used. Information about the creation should be documented with the prov:wasGeneratedBy property. Information about updates of a Person reconstruction should be documented with prov:wasRevisionOf
Schematic overview of a person reconstruction
Schematic overview of a person reconstruction.
cbg:person_reconstruction_2 a pico:PersonReconstruction ; sdo:name "Anna Maria Koppen" ; sdo:familyName "Koppen" ; sdo:givenName "Anna" ; sdo:gender sdo:Female ; sdo:birthPlace "Haarlem" ; sdo:birthDate "1860-03-31"^^xsd:date ; sdo:deathPlace "Detroit, VSA" ; sdo:deathDate "1926"^^xsd:gYear ; prov:wasDerivedFrom nha:huwelijksakte_1885_321_po_1, cbg:NL-HaCBG_1755_0341_142_po_1 ; prov:wasGeneratedBy cbg:reconstruction_activity_01 . cbg:reconstruction_activity_01 a prov:Activity ; prov:wasAssociatedWith cbg:reconstruction_agent_01 ; prov:startedAtTime "2015-08-07T00:00:00"^^xsd:dateTime ; prov:endedAtTime "2020-01-08T00:00:00"^^xsd:dateTime .
An intangible type to be applied to any archive content, carrying with it a set of properties required to describe archival items and collections.
Source
Person observations can appear on many types of historical documents. The PiCo model does not aim to describe these sources, as excellent data models, such as Records in Contexts and Dublin Core, already exist within the heritage domain. In order to model person observations, we require that institutions describe their sources at least with a single name property that combines identifying information about the source like its title and creation date. For example, a Marriage Certificate is then described as follows: "BS Marriage Haarlem, November 11, 1885, certificate number 321". As long as this description consists of various elements that identify the source, heritage institutions are free to use any authoritative domain-specific standard to describe their historical person records.
afr:geboorteregister_1858 a sdo:ArchiveComponent ; sdo:additionalType picot_sourcetypes:551 ; # civil registry: birth sdo:name "Geboorteregister 1858, archiefnummer 30-16, Burgerlijke Stand Haskerland - Tresoar, inventarisnummer 1020, blad 051" ; sdo:holdingArchive <https://www.tresoar.nl/> ; sdo:url <https://allefriezen.nl/zoeken/deeds/f7e82c08-47c5-de67-c636-26aa1603f6c9> ; sdo:dateCreated "1885"^^xs:gYear ; sdo:locationCreated "Haskerland" ; sdo:associatedMedia [ a sdo:ImageObject ; sdo:position 51 ; sdo:url "https://tresoar-images.memorix.nl/frl/download/fullsize/3a9b2d6a-f225-a14e-ab85-3581be7d4d04.jpg" ; sdo:thumbnail "https://tresoar-images.memorix.nl/frl/thumb/250x250/3a9b2d6a-f225-a14e-ab85-3581be7d4d04.jpg" ; ] .
An image file.
Scan
A link to the location of the scan at the HoldingArchive. A link to scan as it can be displayed online and a link to a thumbnail (for search results) should be provided. Preferably a link to a IIIF manifest.
Name of a person, expressed in Person Name Vocabulary (PNV)
PersonName
In the Person Name Vocabulary, a name is considered to be a a resource type in its own right. A PersonName can consist of many different parts. The most common ones are mentioned here. See the full specification of the Person Name Vocabulary for more details. Additionally to a pnv:PersonName, the properties sdo:literalName or sdo:givenName and sdo:familyName should be used.
address
Address of a Person as mentioned on the Source.
A Base surname is a family name without any prefixes, if those prefixes need to be ignored in sorting. If the family name is e.g. 'de Vries' and it needs to be sorted under 'V', the Base surname is 'Vries'. Base surname is equivalent to BioDes:geslachtsnaam.
baseSurname
birthDate
The birth date of a person. A date value in ISO 8601 format should be used. Incomplete dates are allowed, but only when truncated from small to large. For example: "1970-08-15", "1970-08" and "1970" are all allowed, but "1970-00-15" or "08-15" are not. Sometimes, you may want use a string as birthDate. For example if you want to or have to record the date exactly as it was written on the Source. If possible use both the string format and the xsd:date format in this case.
birthPlace
Preferably, use a link to an existing thesaurus like geonames or wikidata. If desired, both the literal place, as mentioned on the Source can be used together with the reconciled version.
The location depicted or described in the content. For example, the geographic coverage of an archival record. Or the location in a photograph or painting.
contentLocation
The date on which the Source was created.
dateCreated
deathDate
The death date of a person. A date value in ISO 8601 format should be used. Incomplete dates are allowed, but only when truncated from small to large. For example: "1970-08-15", "1970-08" and "1970" are all allowed, but "1970-00-15" or "08-15" are not. When the date of death is not known, but is known that a person is deceased, the property :deceased can be used. Sometimes, you may want to use a string as deathDate. For example if you want to or have to record the date exactly as it was written on the Source. If possible use both the string format and the xsd:date format in this case.
The place where the person died.
deathPlace
deceased
Indication if a person is still alive or not at time of the source of the observation. Only used when deathDate is unknown. A person without a deathDate and without the property deceased set to true, will be considered alive. This will have consequences for the publication of the person record and of any linked media items.
The end time of the activity that generated a Person Reconstruction.
Family name. For Dutch names, this is the last name of a person.
familyName
The use of sdo:givenName and sdo:familyName is the most straightforward method for describing person names. Use pnv:PersonName for more extensive name annotations.
Literal name designates a full personal name. This property may only be left blank if a person's name was unknown or if a person was unnamed (e.g. a child that died shortly after being born), in which cases the property pnv:nameSpecification should state "unknown" or "unnamed".
literalName
gender
Use one of: sdo:Male or sdo:Female.
The given name of a pnv:PersonName. Designates the name(s) given to someone at birth or any other name-giving event.
givenName (pnv)
Given name. For Dutch names, this could be multiple given names of a person.
The use of sdo:givenName and sdo:familyName is the preferred method for describing person names. Use pnv:PersonName for more extensive name annotations.
The age of a person.
hasAge
Only used for Person observations, in case the birth date is not known, but the age is. In combination with de date of the Source, a birth date range can be derived, which can be used in the process of creating a Person reconstruction. The age is considered to be in years, unless otherwise mentioned. So an age of "4" is considered to be 4 years, where "4 months" is interpreted as 4 months. Numerical ages ("4") are preferred above ages in text ("four").
The occupational title related to a person in an observation.
hasOccupation
Occupation as mentioned on the Source
Religious conviction related to a person in an observation.
Religion as mentioned on the Source. If desired, a SKOS thesaurus can be used to annotate religion.
An initial is the first letter of a person's given name (or sometimes a combination of letters). The Initials property can be used to separately record the initial(s) of a person's given name(s). Each initial should be followed by a dot. It is recommended to always use the Initials property to record initials, but if only the initials of a given name are known, they may also be recorded using pnv:givenName (or pnv:firstName). Example 1: "Peter R. de Vries" would be modelled using pnv:initials "P.R." and pnv:givenName "Peter R.". Example 2: "C.Joh. Kieviet" would ideally be modelled using pnv:initials "C.Joh.", but pnv:givenName "C.Joh." is also possible. Example 3: "H.A.F.M.O. (Hans) van Mierlo" would be modelled using pnv:initials "H.A.F.M.O." and pnv:givenName "Hans".
initials
name
For Persons: Use full name if the name can't be split into given name and family name. Otherwise use sdo:givenNamen and sdo:fullName or the more extensive pnv:PersonName.
For Sources: Use a user-friendly name to identify the source. Depending on the Source type, this may contain a combination of it's name, year of creation, creator, et cetera.
A Patronym is a name element based on the given name of one's father or grandfather. This is also the preferred property for a matronym (i.e. a name element based on the given name of one's mother or grandmother).
patronym
The position of the scan in the order of a set of scans
position
The position defines the order in which scans are presented on the web. This feature is required when a Source has multiple scans.
The start time of the activity that generated a Person Reconstruction.
A Surname prefix is a name part prefixing the surname (e.g. 'van' or 'van den').
surnamePrefix
Assignment of responsibility to an agent for the activity of creating a person reconstruction.
The name of a Person, annotated according to the Person Name Vocabulary.
additionalName
additionalType
Use a term from the PiCo thesaurus for Source types: https://terms.personsincontext.org/sourcetypes
A media object, usually a scan, that encodes the Source of a Person observation.
associatedMedia
todo
A child of a person.
children
For Person observations, the child should always refer to another Person observation on the same Source.
For Person reconstructions, the child should refer to another Person reconstruction.
A URL pointing to a viewer for a specific scan.
embedUrl
A primary source for a topic refers to something produced by some agent with direct experience and knowledge about the topic, at the time of the topic's study, without benefit from hindsight. Because of the directness of primary sources, they 'speak for themselves' in ways that cannot be captured through the filter of secondary sources. As such, it is important for secondary sources to reference those primary sources from which they were derived, so that their reliability can be investigated. A primary source relation is a particular case of derivation of secondary materials from their primary sources. It is recognized that the determination of primary sources can be up to interpretation, and should be done according to conventions accepted within the application's domain.
hadPrimarySource
Linking a Source with the hadPrimarySource property is required for Person Observations.
hasAncestor
hasAncestor is not meant to be used as a property for PersonObservations or PersonReconstructions. It is a superclass of sdo:Parent. Since hasAncestor is a owl:TransitiveProperty, this will make the parent of your parent into your ancestor.
hasDescendant
hasDescendant is not meant to be used as a property for PersonObservations or PersonReconstructions. It is a superclass of sdo:Children. Since hasAncestor is a owl:TransitiveProperty, this will make the children of your children into your descendants.
hasChild-in-law
For Person observations, the hasChild-in-law property should always refer to another Person observation on the same Source.
For Person reconstructions, the hasChild-in-law property should refer to another Person reconstruction.
hasCousin
For Person observations, the hasCousin property should always refer to another Person observation on the same Source.
For Person reconstructions, the hasCousin property should refer to another Person reconstruction.
hasCousin-in-law
For Person observations, the hasCousin-in-law property should always refer to another Person observation on the same Source.
For Person reconstructions, the hasCousin-in-law property should refer to another Person reconstruction.
hasFosterChild
For Person observations, the hasFosterChild property should always refer to another Person observation on the same Source.
For Person reconstructions, the hasFosterChild property should refer to another Person reconstruction.
hasFosterParent
For Person observations, the hasFosterParen property should always refer to another Person observation on the same Source.
For Person reconstructions, the hasFosterParen property should refer to another Person reconstruction.
hasGodchild
For Person observations, the hasGodchild property should always refer to another Person observation on the same Source.
For Person reconstructions, the hasGodchild property should refer to another Person reconstruction.
hasGodparent
For Person observations, the hasGodparent property should always refer to another Person observation on the same Source.
For Person reconstructions, the hasGodparent property should refer to another Person reconstruction.
hasGrandchild
For Person observations, the hasGrandchild property should always refer to another Person observation on the same Source.
For Person reconstructions, the hasGrandchild property should refer to another Person reconstruction.
hasGrandchild-in-law
For Person observations, the hasGrandchild-in-law property should always refer to another Person observation on the same Source.
For Person reconstructions, the hasGrandchild-in-law property should refer to another Person reconstruction.
hasGrandparent
For Person observations, the hasGrandparent property should always refer to another Person observation on the same Source.
For Person reconstructions, the hasGrandparent property should refer to another Person reconstruction.
hasGrandparent-in-law
For Person observations, the hasGrandparent-in-law property should always refer to another Person observation on the same Source.
For Person reconstructions, the hasGrandparent-in-law property should refer to another Person reconstruction.
hasGreat-grandchild
For Person observations, the hasGreat-grandchild property should always refer to another Person observation on the same Source.
For Person reconstructions, the hasGreat-grandchild property should refer to another Person reconstruction.
hasGreat-grandparent
For Person observations, the hasGreat-grandparent property should always refer to another Person observation on the same Source.
For Person reconstructions, the hasGreat-grandparent property should refer to another Person reconstruction.
hasHalf-sibling
For Person observations, the hasHalf-sibling property should always refer to another Person observation on the same Source.
For Person reconstructions, the hasHalf-sibling property should refer to another Person reconstruction.
hasLegitimizedChild
For Person observations, the hasLegitimizedChild property should always refer to another Person observation on the same Source.
For Person reconstructions, the hasLegitimizedChild property should refer to another Person reconstruction.
For Person observations, the isLegitimitezedChildOf property should always refer to another Person observation on the same Source.
For Person reconstructions, the isLegitimitezedChildOf property should refer to another Person reconstruction.
hasNephew-in-law/Niece-in-law
For Person observations, the hasNephew_Niece-in-law property should always refer to another Person observation on the same Source.
For Person reconstructions, the hasNephew_Niece-in-law property should refer to another Person reconstruction.
hasNephew/Niece
For Person observations, the hasNephew_Niece property should always refer to another Person observation on the same Source.
For Person reconstructions, the hasNephew_Niece property should refer to another Person reconstruction.
hasParent-in-law
hasPreviousPartner
For Person observations, the hasPreviousPartner property should always refer to another Person observation on the same Source.
For Person reconstructions, the hasPreviousPartner property should refer to another Person reconstruction.
hasSibling-in-law
For Person observations, the hasSibling-in-law property should always refer to another Person observation on the same Source.
For Person reconstructions, the hasSibling-in-law property should refer to another Person reconstruction.
hasStepchild
For Person observations, the hasStepchild property should always refer to another Person observation on the same Source.
For Person reconstructions, the hasStepchild property should refer to another Person reconstruction.
hasStepchild-in-law
For Person observations, the hasStepchild-in-law property should always refer to another Person observation on the same Source.
For Person reconstructions, the hasStepchild-in-law property should refer to another Person reconstruction.
hasStepparent
For Person observations, the hasStepparent property should always refer to another Person observation on the same Source.
For Person reconstructions, the hasStepparent property should refer to another Person reconstruction.
hasStepparent-in-law
For Person observations, the hasStepparent-in-law property should always refer to another Person observation on the same Source.
For Person reconstructions, the hasStepparent-in-law property should refer to another Person reconstruction.
hasStepsibling
For Person observations, the hasStepsibling property should always refer to another Person observation on the same Source.
For Person reconstructions, the hasStepsibling property should refer to another Person reconstruction.
hasUncle/Aunt
For Person observations, the hasUncle_Aunt property should always refer to another Person observation on the same Source.
For Person reconstructions, the hasUncle_Aunt property should refer to another Person reconstruction.
For Person observations, the hasUncle_Aunt-in-law property should always refer to another Person observation on the same Source.
For Person reconstructions, the hasUncle_Aunt-in-law property should refer to another Person reconstruction.
Organization that holds, keeps or maintains the ArchiveComponent.
holdingArchive
isWidow/WidowerOf
For Person observations, the isWidOf property should always refer to another Person observation on the same Source.
For Person reconstructions, the isWidOf property should refer to another Person reconstruction.
parent
For Person observations, the parent property should always refer to another Person observation on the same Source.
For Person reconstructions, the parent property should refer to another Person reconstruction.
A person's brother or sister.
sibling
For Person observations, the sibling should always refer to another Person observation on the same Source.
For Person reconstructions, the sibling should refer to the Person reconstruction of the spouse.
The person's spouse.
spouse
For Person observations, the spouse should always refer to another Person observation on the same Source.
For Person reconstructions, the spouse should refer to the Person reconstruction of the spouse.
Thumbnail image of the Scan.
thumbnail
url
For Sources: a link to the Source at the holding archive. Preferably a permalink.
For Scans of Sources: a link to the scan of the Source at the holding archive. Preferably a link to a IIIF manifest.
The role of a Person observation on the Source.
hasRole
Use a term from the PiCo Roles thesaurus: https://terms.personsincontext.org/roles
A derivation is a combination of one or more Person observations in a Person reconstruction
wasDerivedFrom
A PersonReconstruction is always derived from one or more PersonObservations. The wasDerivedFrom property is therefore required for PersonReconstructions.
Generation is the completion of production of a new Person reconstruction by an activity. This Person reconstruction did not exist before generation and becomes available for usage after this generation.
wasGeneratedBy
Required for PersonReconstructions.
A revision is a derivation for which the resulting entity is a revised version of some original.
wasRevisionOf
The wasRevisionOf property is used for modifications made on Person reconstructions. It can be qualified with a prov:Revision.