MetaBelgica data model specification

Historically, in authority control, a single uniform name was used to uniquely identify an authority record, hence the name as a sort of identifier. Instead of by name, we use a unique and persistent identifier to refer to persons. Nevertheless, we still use the preferred name spelling as the preferred label of a person.

• A person MUST have at least one preferred name
• A person MAY have one preferred name per language. This supports for example multilingual interfaces to consult the record.
• A preferred name MUST be comprised of unicode characters and cannot be empty. This supports multilingual use cases in which different alphabets need to be supported.
• A preferred name MAY be annotated with a language.
• The language of a preferred name or alternate name MUST be annotated with language tags according to [RFC5646].

Names might be spelled differently in other languages, there might be recorded nicknames or aliases. As mentioned above, historically a single uniform name was chosen as preferred name spelling. Other spellings were recorded as well to improve information retrieval.

• A person MAY have zero or more alternate names
• An alternate name MUST be comprised of unicode characters and cannot be empty. This supports multilingual use cases in which different alphabets need to be supported.

This is the recorded date of birth of a person according to the Gregorian calender.

• The birth date MUST be indicated by using [ISO8601:2019-1] or its extension for uncertain dates [ISO8601:2019-2].

This is the recorded date of death of a person according to the Gregorian calender.

• The death date MUST be indicated by using [ISO8601:2019-1] or its extension for uncertain dates [ISO8601:2019-2].

This is the occupation of a person according to a controlled vocabulary.

• A person MAY have zero or more occupations.

This property links a person to an entity of type Location (see definition below).

This property links a person to an entity of type Location (see definition below).

We employ the property visibility to indicate the envisioned target audience. In MetaBelgica we distinguish between the following three use cases:

1. internal: An entity/property is only meant to be used internally, one example are other administrative properties
2. shared: An entity/property can be shared in a research context and in the frame of a data sharing agreement with a trusted partner, one example is sensitive data such as gender information
3. public: An entity/property is meant to be displayed publicly, one example is the name of a person record

The visibility property MUST BE applicable to annotate a whole entity, a whole property or a specific property instance. Entities annotated with internal or shared MUST NOT be shown publicly. Entities annotated with internal MUST NOT be shared with third-parties.

An entity may have several properties, in case the entity itself has the visibility public, but one of the used properties has the visibility internal or shared, then those property values MUST NOT be shown publicly.

For example, the property gender has the visibility shared, hence all person entities with visibility public may be displayed publicly, but the value of the gender property shall not be shown.

We employ the property legal basis to qualify why an entity, a property or a property instance has a certain visibility.

There property legal basis MUST link to one of the following legal basis (future versions of this specification may extend this list):

• Freedom of Information: Used to indicate that an entity, property or property value should be publicly visible. Based on Belgian law, covering the access of administrative documents held by public bodies.
• Deceased: Used to indicate that all personal data can be publicly visible, GDPR no longer applies
• Consent: Used to indicate that something can be publicly visible, because the person described by the record (data-subject) provided consent to display the property value.
• Opt-out: Used to indicate that something must not be publicly visible, because the person described by the record (data-subject) opted out.
• Sensitive data: Used to indicate that a property or property value should not be publicly visible as it is sensitive data which also due to data minimization must not be made publicly visible.

When the legal basis Consent is used, there MUST be a link to a Consent entity that provides further details about the consent.

The following default values apply, for example for the initial bulk-load from MetaBelgica partners.

• The default legal basis for living persons is Freedom of Information.
• The default legal basis for persons with a known death date is Deceased

With respect to GDPR's data minimization, certain data should be adapted. Todo: elaborate

• The default annotation yearOnly MUST be applied to the year of birth.

The conceptual MetaBelgica data model, implemented as Wikibase entities and properties, can be used to support various data governance use cases. It can be used in a consistent way and only relies on the properties visibility, applies To and legal ground, optionally with start date and end date.

The following use cases are supported which means that even fine-grained control is possible:

1. Display entity publicly
2. Display property for entities publicly
3. Do not display entity publicly
4. Do not display property on entities publicly
5. Opt-in to display entity publicly
6. Opt-in to display property for specific entity publicly
7. Opt-out to display entity publicly
8. Opt-out to display property for specific entity publicly

Additionally, the Wikibase data model can be used to annotate provenance about the visibility with a legal ground property when used as a qualifier. Therefore it will be documented why something is public or not and when using start and end date qualifiers, a whole provenance record can be built. Useful to indicate if a certain opt-in only occurred at some point in time or to indicate from when an opt-out was requested.