Master/data-meta-model
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

tbox: v2.2 - polymorphisme declare sur 19 proprietes, 17 domaines poses, provenance portee par les classes concretes, GovernanceLayerObject rattachee, affectations de gouvernance completes (12 completees, 10 SDO, 1 PO, 16 stewards par objet metier), Panel Coverage gouverne. Validation SHACL sans violation bloquante

Browse Source
This commit is contained in:
Bastien Gourdon
2026-08-07 10:31:16 +02:00
parent d90d2a316d
commit 0b7d3834d2
29 changed files with 3274 additions and 274 deletions
Download Patch File Download Diff File Expand all files Collapse all files
governance/migration/assignments_v2_2.yaml
+179
View File
@@ -0,0 +1,179 @@
# T-BOX AND A-BOX MIGRATION TO v2.2 — GOVERNANCE ASSIGNMENTS
# =============================================================================
# Data consumed by migrate_tbox_v2_2.py.
#
# An actor node is an ASSIGNMENT, not a person. The post is stable and carries
# the canonical name, the identifier and the domain it answers to; the person
# holding it is a value that changes. Modelled the other way round, a change of
# incumbent would move nodes and edges rather than one literal, and the same
# person covering two domains would exist twice.
# =============================================================================
meta:
from_version: "2.1"
to_version: "2.2"
namespace: "https://ontology.pernod-ricard.com/metamodel/"
instance_namespace: "https://data.pernod-ricard.com/sodh/"
# -----------------------------------------------------------------------------
# T-BOX
# -----------------------------------------------------------------------------
declare_properties:
- term: personName
kind: DatatypeProperty
domain: Actor
range: "http://www.w3.org/2001/XMLSchema#string"
comment: >
The name of the person currently holding the post. Declared on Actor rather
than on each role, since every role shares it and Actor is their smallest
common ancestor below the layer root. Held as a value rather than a node
because what changes is the person, not the assignment: the post keeps its
identifier, its domain and every edge that points at it, and a change of
holder rewrites one literal. Used on actors and nowhere else.
display_updates:
- {term: DataSteward, acronym: DST}
# -----------------------------------------------------------------------------
# A-BOX — RENAME
# ST is not the short form of Data Steward; DST is, and the rulebook now
# declares it.
# -----------------------------------------------------------------------------
instance_renames:
- {from: ST_DD_04, to: DST_DD_04}
- {from: ST_DD_05, to: DST_DD_05}
- {from: ST_DD_06, to: DST_DD_06}
- {from: ST_DD_10, to: DST_DD_10}
- {from: ST_DD_16, to: DST_DD_16}
- {from: ST_DD_21, to: DST_DD_21}
# -----------------------------------------------------------------------------
# A-BOX — COMPLETE THE EXISTING ASSIGNMENTS
# The canonical name becomes the name of the POST. The person moves to heldBy.
# -----------------------------------------------------------------------------
complete:
- {node: DDO_DD_04, identifier: "DDO-04", name: "Data Domain Owner", held_by: "David Carpio", domain: DD_04}
- {node: DDO_DD_05, identifier: "DDO-05", name: "Data Domain Owner", held_by: "David Carpio", domain: DD_05}
- {node: DDO_DD_06, identifier: "DDO-06", name: "Data Domain Owner", held_by: "Ludovic Cottier", domain: DD_06}
- {node: DDO_DD_10, identifier: "DDO-10", name: "Data Domain Owner", held_by: "Alberto Lupano", domain: DD_10}
- {node: DDO_DD_16, identifier: "DDO-16", name: "Data Domain Owner", held_by: "Julien Soisson", domain: DD_16}
- {node: DDO_DD_21, identifier: "DDO-21", name: "Data Domain Owner", held_by: "Vincent Meunier", domain: DD_21}
- {node: DGL_DD_04, identifier: "DGL-04", name: "Data Governance Lead", held_by: "Marie Carabin", domain: DD_04}
- {node: DGL_DD_05, identifier: "DGL-05", name: "Data Governance Lead", held_by: "Alberic Piot", domain: DD_05}
- {node: DGL_DD_06, identifier: "DGL-06", name: "Data Governance Lead", held_by: "Bastien Gourdon", domain: DD_06}
- {node: DGL_DD_10, identifier: "DGL-10", name: "Data Governance Lead", held_by: "Anas El Kesri", domain: DD_10}
- {node: DGL_DD_16, identifier: "DGL-16", name: "Data Governance Lead", held_by: "Gaelle Seret", domain: DD_16}
- {node: DGL_DD_21, identifier: "DGL-21", name: "Data Governance Lead", held_by: "Bastien Gourdon", domain: DD_21}
# -----------------------------------------------------------------------------
# A-BOX — SUB-DOMAIN OWNERS, 10
# -----------------------------------------------------------------------------
create_sub_domain_owners:
- {node: SDO_SD_04_01, identifier: "SDO-04.01", held_by: "Etienne Coulon", sub_domain: SD_04_01, domain: DD_04}
- {node: SDO_SD_04_02, identifier: "SDO-04.02", held_by: "Etienne Coulon", sub_domain: SD_04_02, domain: DD_04}
- {node: SDO_SD_04_03, identifier: "SDO-04.03", held_by: "Etienne Coulon", sub_domain: SD_04_03, domain: DD_04}
- {node: SDO_SD_05_01, identifier: "SDO-05.01", held_by: "David Carpio", sub_domain: SD_05_01, domain: DD_05}
- {node: SDO_SD_06_01, identifier: "SDO-06.01", held_by: "Loic Berger", sub_domain: SD_06_01, domain: DD_06}
- {node: SDO_SD_10_01, identifier: "SDO-10.01", held_by: "Alberto Lupano", sub_domain: SD_10_01, domain: DD_10}
- {node: SDO_SD_16_01, identifier: "SDO-16.01", held_by: "Julien Soisson", sub_domain: SD_16_01, domain: DD_16}
- {node: SDO_SD_16_02, identifier: "SDO-16.02", held_by: "Julien Soisson", sub_domain: SD_16_02, domain: DD_16}
- {node: SDO_SD_16_03, identifier: "SDO-16.03", held_by: "Julien Soisson", sub_domain: SD_16_03, domain: DD_16}
- {node: SDO_SD_21_01, identifier: "SDO-21.01", held_by: "Vincent Meunier", sub_domain: SD_21_01, domain: DD_21}
sub_domain_owner_name: Data Sub Domain Owner
# -----------------------------------------------------------------------------
# A-BOX — PRODUCT OWNER, 1
# -----------------------------------------------------------------------------
create_product_owners:
- {node: PO_SODH, identifier: "PO-06.01-001", held_by: "Guilherme Muller", product: DP_06_01_001, domain: DD_06}
product_owner_name: Data Product Owner
# -----------------------------------------------------------------------------
# A-BOX — STEWARDS, ONE ASSIGNMENT PER BUSINESS OBJECT
# Derived from the graph rather than listed: the business objects are the source
# of truth for how many assignments exist and which domain each answers to.
# The incumbent is read from this map by domain.
# -----------------------------------------------------------------------------
steward_holders:
DD_04: Marc Chambouleyron
DD_05: Francois Vadrouille
DD_06: Michael Flores
DD_10: Magda Kugli
DD_16: Clementine Sauries
DD_21: Alberic Piot
steward_name: Data Steward
# The six per-domain steward nodes are replaced by one per business object.
# monitoredBy is repointed from the old node to the new one, and the old node is
# withdrawn once nothing names it (EV-003).
retire_domain_stewards: true
# -----------------------------------------------------------------------------
# A-BOX — GOVERN A TRANSVERSE CONCEPT
# Panel Coverage is used by four business objects through usesConcept and is the
# subject of none. A concept mobilised without an object that carries it has no
# owner, no steward and no governance chain: it is used without being governed.
# Creating the missing business object closes the chain BC -> BO -> SD -> DD,
# and the steward assignment follows automatically since assignments are derived
# from the business objects present in the graph.
# -----------------------------------------------------------------------------
create_business_objects:
- node: BO_06_01_006
identifier: "BO-06.01-006"
name: Panel Coverage
is_about: BC_06_01_003
sub_domain: SD_06_01
domain: DD_06
# -----------------------------------------------------------------------------
# A-BOX — ownedBy AGAINST THE OLD DOMAIN-LEVEL STEWARDS
# 53 subjects declared they belonged to the per-domain steward node. That node
# disappears, so each reference is resolved rather than dropped in silence.
#
# business object -> removed. It already carries monitoredBy towards the
# same assignment, and two properties holding one fact
# are two answers to one question waiting to diverge.
# sub-domain -> repointed to its Data Sub Domain Owner, whose function
# this is; a steward had no business holding it.
# everything else -> repointed to the steward assignment of the business
# object it belongs to, followed through the graph.
# -----------------------------------------------------------------------------
owned_by_resolution:
remove_on: [BusinessObject]
repoint_sub_domains: true
repoint_to_business_object_assignment: true
# Chains followed to reach the business object, in order. The first that
# resolves wins; anything unresolved is reported and left untouched.
chains:
- {via: isAbout, direction: inbound} # a BO is about this concept
- {via: represents, direction: outbound} # this object represents a BO
- {via: measures, direction: outbound} # a metric measures a concept, then isAbout
# -----------------------------------------------------------------------------
# COMMON
# -----------------------------------------------------------------------------
status: PUBLISHED
version: "1.0"
# -----------------------------------------------------------------------------
# SHAPES — NR-002 EXEMPTION
# -----------------------------------------------------------------------------
shape_notes:
- rule: NR-002
change: exempt descendants of Actor from the canonical-name uniqueness query
reason: >
An assignment is a post, not a catalogued object. Five steward posts in one
domain are legitimately homonymous; what tells them apart is the identifier
and the business object that names them. Applying a uniqueness rule written
for catalogued objects would force fifteen invented names for one job.