OWL T-Box. Six layers (Ownership, Business, Logical, Delivery, Physical, Consumption) crossed with a provenance axis (Defined vs Captured). Defined objects are written by governance and reviewed; Captured objects are read from Snowflake, Tableau and Looker and are rebuilt, never edited. Bridge annotation properties are declared for future alignment with domain ontologies.
Links a documentation record (Business Object, Business Concept, Data Object) to the CLASS it describes in a domain ontology. Example: ex:BO_16_03_001 pr:denotes fin:Invoice .
Links a Data Element or Business Concept to the PROPERTY it describes in a domain ontology. Example: ex:DE_16_03_0001 pr:denotesProperty fin:netAmount .
Links a Metric or Business Object to the PROCESS or EVENT it describes, typically a prov:Activity subclass. Example: ex:M_16_03_001 pr:denotesActivity fin:InvoiceIssuance .
For Captured terms: the system view or API that populates this term. Documents the contract between the meta model and the harvester.
Who writes this, in practice: ASSERTED (a person does), HARVESTED (a job does) or PROPOSED_CONFIRMED (a job proposes and a person accepts). Renamed from curationMode along with the classes: 'curation' belonged to the same jargon family as 'curated'.
Anything the meta model describes. Actors are deliberately NOT Meta Model Objects.
Somebody decided it. Written by governance, edited through a pull request on the domain TTL file, and subject to the full identity and lifecycle shape: identifier, name, owner, owning Data Domain, status, version.
v1.4 term. Renamed because 'curated' is governance jargon; 'defined' says the same thing to a business reader. No instance ever named this class directly.
Read from a running system and rebuilt on every run. Never hand-edited. Carries sourceIdentifier, fullyQualifiedName and harvestedOn instead of declared ownership: attribution is INFERRED through the Data Element it is mapped to, never asserted on the node.
v1.4 term. Renamed because 'observed' is passive and technical; 'captured' says where it came from. No instance ever named this class directly.
What we promise, to whom, until when. A different question from how the data is structured, hence a layer of its own: version, owner, changelog, support channel, consumers to warn.
The one layer whose members do NOT share a provenance, which is why this class -- unlike the other five layer roots -- says nothing about it. A System is DEFINED: somebody decides that MDM Product is a system worth tracking, and names it. Nobody harvests the list of systems that matter. Everything beneath a system is CAPTURED: databases, schemas, data structures, fields, keys and transformations are read from what is running. Until v1.4 this class was itself declared a kind of Captured Object, which made every physical class captured by construction and put the five seeded Systems in breach of the harvest rules. The two axes are meant to be orthogonal; that shortcut collapsed them.
The BI estate. Separate from Physical because BI assets have their own lifecycle and their own owner: a dashboard belongs to its author, not to the Data Domain that owns the underlying data.
The single anchor of accountability, which is why it stays in the Ownership layer: it is the one object where a steward is declared, and Data Objects and Data Elements inherit from it. It carries NO business definition of its own -- its meaning comes from its aboutConcept. What it does carry is a perimeter: the subject it is about, and the notions needed to read it.
A shared business notion WITHOUT a formula. The presence of a formula is the sole discriminator against Metric (rule BR-003).
A quantifiable measurement WITH a formula, a unit and a grain. Under BR-013 a Metric carries the harmonised CALCULATION RULE; variants that differ only by analysis context are Data Elements linked back via computedBy.
An elevated Metric. Use this class rather than the deprecated isKPI flag.
The pivot: represents exactly one Business Object, is composed of Data Elements, and is materialized as one or more Physical Relations. The single junction between governance and technology.
The finest defined unit. Its mapping to a physical Field is the ONLY place where the defined graph and the captured graph meet: proposed automatically by name and type matching, confirmed by a Data Steward.
v1.0 term, defined as 'directly consumable by a business user' -- a judgement, not a structural test, which is why it collected zero instances in a year. Use DataInterface.
The unit of delivery: what carries a version number, an owner, a changelog, a support channel and a list of consumers to warn. It has no single technical counterpart, and should not: physically it often lands on a Snowflake schema or a dbt project, but that is not what defines it. Operated by exactly one Sub-Domain -- it is a consumable, and there must be no ambiguity about who runs it. Candidate alignment: dcat:Dataset / DPROD.
The channel through which a consumer actually gets the data: a Snowflake secure share or listing, a consumption schema with its grants, a file extract to a panel partner, an API or reverse-ETL feed. Not a Data Object (that is structure) and not a BI Data Source (that is one consumer among others). Verifiable: a grant, a share or an endpoint either exists or it does not. The output port in data-mesh terms.
The service commitment attached to a Data Product: schema, freshness, quality thresholds, support, breaking-change notice period. Candidate alignment: ODCS (Bitol).
A real system: Snowflake, MDM Product, MDM Customer, a panel provider feed, Tableau Server, Looker. Making this a node rather than a string is what makes 'what depends on MDM Product?' answerable.
Anything that carries Fields and reads as a set of rows. Never instantiated directly: a harvest types the concrete kind, and a viewer shows that kind rather than this parent. WHY THE PARENT EXISTS. Three properties need exactly this set as their scope: storedIn from a Data Object, hasField and its inverse livesIn, and dependsOn. Without it each would have to be tripled, once per concrete kind, and the checks would go with them. WHY THE NAME CHANGED. It was PhysicalRelation, from Codd, where a relation IS a table. In an ontology "relation" reads as a property, and the word locks the class into the tabular world. A Neo4j node label, a Mongo collection and a Kafka topic all carry fields; none is a relation. EXTENSION POINT for non-tabular storage. Nothing at Pernod Ricard is non-tabular today, so no such class is declared -- four terms were deprecated in v1.2 precisely because nobody instantiated them. The day a graph enters scope, the insertion is additive and touches no instance, because subClassOf is transitive: pr:Dataset rdfs:subClassOf pr:DataStructure . pr:Graph rdfs:subClassOf pr:DataStructure . pr:BaseTable rdfs:subClassOf pr:Dataset . # instead of DataStructure pr:inSchema rdfs:domain pr:Dataset . # instead of nothing Existing BaseTable assertions stay DataStructure by entailment, every shape targeting DataStructure keeps working, and storedIn does not move. The extension point is paid once; the extension is paid when it arrives.
Depends on other relations through dependsOn, so impact is transitive.
A class standing in for an attribute: what distinguishes it is being derived, which dependsOn already states.
Backed by files outside the warehouse. Marks the boundary where lineage leaves Snowflake.
A physical column. The anchor of impact analysis: everything upstream reaches a Field, everything downstream starts from one.
SNOWFLAKE.INFORMATION_SCHEMA.TABLE_CONSTRAINTS + KEY_COLUMN_USAGE
Gives foreign keys a home. Rule OW-006 says an FK is not a Data Element - true, but it still needs somewhere to live, and it lets the asserted DataObject-references-DataObject edge be checked against reality.
dbt manifest.json, Snowflake TASKS, Azure Data Factory pipelines
The code that turns inputs into outputs: a dbt model, a Snowflake task, an ADF pipeline. Subclass of prov:Activity so that lineage is expressed in a standard vocabulary rather than a private one.
Tableau Metadata API (Project/Site) ; Looker API (Model)
Tableau Published Datasource ; Looker Explore
The semantic surface a report is built on. This is where BI meets the warehouse.
Tableau calculated fields ; LookML measures and dimensions
A field as a business user sees it. exposesMetric is what turns a certified Metric from a definition on paper into something measurable against the real BI estate.
Tableau Workbook/Sheet ; Looker Look/Dashboard
What a Data Governance Lead actually cares about in an impact analysis: not that a column changed, but which reports break and who to warn.
A person or a team. Deliberately NOT a MetaModelObject: people are not subject to ownership and lifecycle rules.
Accountable for a Data Domain. Exactly one per domain.
Accountable for a Sub-Domain. Exactly one per sub-domain.
Runs governance for a Data Domain. The acronym belongs in hasAcronym, not in the label (rule NR-005).
Runs a Data Product day to day: releases, changelog, support, consumer communication. Belongs to the Sub-Domain that operates the product.
Monitors a Business Object. Declared there and nowhere else: Data Objects and Data Elements inherit their steward, so that no column can ever have two answers to 'who watches this'.
Same logical object, several physical incarnations. Kept as a vocabulary rather than folded into the name so that DEV drift never pollutes PROD lineage.
Position in the categorization tree. One property for the whole tree: SubDomain belongs to DataDomain, BusinessObject belongs to SubDomain. Scope is enforced per class by SHACL rather than by two near-identical properties, and the same relation will serve if a domain family ever appears. Deliberately NOT transitive: entailment would produce two values and break the maxCount 1 shape. To walk the ancestry, use the property path belongsTo+ in the query.
The single subject of this Business Object, and where its meaning comes from -- a Business Object carries no definition of its own. Exactly one. If the subject cannot be named, the object is not scoped, and that is the most useful thing the rule can tell you. Replaces the 3..10 minimum of BR-004, which was satisfied in v0.6 by attaching unrelated concepts.
The other notions required to read this object correctly. Zero or more, and zero is a legitimate answer.
Carried three different meanings depending on the object: dependency (Sell Out Volume), subject (Retailer Stock), part-whole (Calendar). One word for three relations is what allowed the v0.6 padding. Split into aboutConcept and usesConcept.
Removed as a genuine relation. Its only use was as a false inverse of composedOf.
The elements whose combination makes a row unique. Grain belongs to a DATASET, not to a calculation rule: a Metric has no rows, so it cannot have a grain of its own -- its grain is derivable from the Data Objects it lands in. Stated at element level rather than object level because it is then CHECKABLE against the harvested PrimaryKey: a declared grain that does not match the real key is an automatic finding.
Put grain on the Metric, which confounded a declarative statement with a structural fact. See hasGrainElement.
BR-013. Links a mother Metric to the granular Data Elements that implement it in a given analysis context (period, promo status, scope, unit, currency).
The business notion a logical artefact is the data-side counterpart of. One relation at two granularities: DataObject represents BusinessObject (exactly one -- the pivot, BR-006) DataElement represents BusinessConcept (at most one) Renamed from 'implements', which carried software-engineering baggage: a Data Object does not implement a Business Object the way a class implements an interface. Range is deliberately left open and scoped by SHACL per class, because the two uses have different targets. A Data Element uses this ONLY when it is dimensional. A measure element reaches meaning through Metric -> computedBy, which says more: it names WHICH metric the meaning travels through. Never both routes on one element. Functional at DataObject level only -- not declared owl:FunctionalProperty here, since a single global cardinality would be wrong for one of the two uses.
The Data Objects that give this one its analysis context: a fact dataset is qualified by Product, Customer, Currency and Date. Physically a foreign key, which is why it is checkable against the harvested ForeignKeyConstraint objects -- but the name says the reason rather than the mechanism. NOT ownership. It is also what carries the grain of a fact object, whose own elements are measures and whose keys are not Data Elements (OW-006).
The scope of the product. Through these Data Objects and their represents, the Business Objects a product makes available are derivable -- which is why a product needs no direct link to a Business Object.
The channels through which the product is actually consumed.
What physically backs the interface: the shared relations, the extract source.
The single Sub-Domain that runs this product. A Data Product spans several Business Objects and therefore cannot inherit accountability the way a Data Object does -- so it declares its own, and exactly one. It is a consumable: there must be no ambiguity about who runs it.
Exactly one. Belongs to the operating Sub-Domain -- checkable, not just conventional.
Redundant once storedIn serves two granularities. One verb fewer, and the seam counts one relation instead of two.
Where a logical artefact actually sits. One relation at two granularities, like represents: DataObject storedIn DataStructure (a table, a view, later a node label) DataElement storedIn Field (a column, later a node property) Range left open and scoped by SHACL per class, because the two uses have different targets. THE SEAM. This is the one relation crossing from what governance defines to what a harvester captures, and the one thing a steward confirms: the reconciliation job proposes the mapping on fully qualified name and type, a person accepts it. It is also what makes end-to-end impact analysis possible. Not functional: the same object exists in DEV, UAT and PROD, and a Data Element may sit in several Fields -- see primaryLocation for the authoritative one. Renamed from physicalizedIn, which was jargon.
The authoritative Field among the several a Data Element may sit in -- the others being copies, replicas or downstream materialisations. A SUB-PROPERTY of storedIn on purpose, not a parallel relation. Entailment then guarantees the primary location is always among the locations, so the two can never disagree; two independent properties would allow a Field marked primary here and absent from storedIn there. Primary and replica rather than master and slave: the industry has moved on, and it reads better to the business.
The System holding the authoritative data for this object. Replaces the free-text hasSource, and answers a question that text could not: which objects depend on MDM Product. Domain deliberately omitted -- it applies to Data Elements, Data Structures, Metrics and BI Data Sources alike, and the scope lives in the shapes. It also settles a naming collision. As a string, "source" meant a system here and a BI surface in BIDataSource, two readings of one word. As a relation towards System, the two are different kinds of thing and the ambiguity disappears.
Domain deliberately not declared, and the shapes must keep this OPTIONAL: Neo4j has no schema and BigQuery calls the level a dataset. A minCount 1 would break on the first harvest outside Snowflake. It is also the only property that would distinguish a tabular Dataset from a Graph, which is why that intermediate level is not declared yet -- one client does not pay for a level of hierarchy.
Domain widened from Table to PhysicalRelation so that views and external tables carry columns too. Inverse now declared - in v0.9 hasField and livesIn were inverses in fact but not in the model, so they were free to diverge.
Derivable: constrainsField then livesIn gives the relation. An asserted edge redundant with an existing path is a divergence waiting to happen.
Relation-level dependency, view to table. Transitive by nature; in practice compute the closure at query time in Snowflake rather than materialising it with a reasoner.
SNOWFLAKE.ACCOUNT_USAGE.ACCESS_HISTORY (column lineage) ; dbt manifest
Column-to-column lineage. The single highest-value edge in the model, and largely free: Snowflake already computes it.
Tableau Metadata API (GraphQL) ; Looker Explore SQL
Closes the last gap in the impact chain: from a dashboard field back to the warehouse column.
The harmonisation measure: how many distinct BI Fields expose one certified Metric, and do their expressions agree. Turns 'we harmonised the definitions' from a claim into a count over the real BI estate. In principle this is derivable from the lineage chain Metric -> DataElement -> Field -> BIField, since lineage carries semantic inheritance. In practice that chain will have holes -- four hops, one of them PROPOSED_CONFIRMED, another harvested from an API that does not resolve custom SQL, extracts or cascaded calculated fields -- and the question it answers is too important to depend on them. So: TRANSITIONAL CONTROL. Asserted directly, and that is all. No rule is written against the lineage chain: making the assertion conditional on intermediate mappings would create confusion and discourage people from filling it in. Retirement criterion, to be measured rather than debated: when the lineage chain reproduces the asserted link for more than 95% of certified BI fields across three consecutive reconciliation cycles, the direct link is derivable and can go.
The author or publisher. This is who gets notified by an impact analysis, and it is NOT the Data Domain owner.
The single Data Domain with authority to define the object's rule. Absent on Captured Objects: a Snowflake column is attributed through the Data Element mapped to it, never asserted directly. Unlike the steward, this one is RE-DECLARABLE on a Data Element. It is inherited by default from the parent chain, but OW-002 attributes an element to the domain that defines its RULE, and a borrowed element -- Brand Code sitting in a Sell Out fact object -- has its rule elsewhere. A Data Element whose owningDomain differs from its parent's is a borrowed element: a signal to check against its represents, not an anomaly to fix.
Declared on BusinessObject, and on DataProduct, and NOWHERE ELSE. Data Objects inherit through represents, Data Elements through hasElement. Declaring a steward at several levels would allow two answers to 'who watches this column'. Says what the steward DOES, where the deprecated hasSteward only stated a membership. DataProduct is the one exception to inheritance: it packages Data Objects belonging to several Business Objects, so it cannot inherit a single steward and declares its own.
The name screens use, where the canonical name is the exhaustive one: Domain for Data Domain, SODH Gold for Sell Out Data Hub - Gold. Declared rather than left to each interface. The same object was being called two different things depending on where you looked, because every viewer kept a display dictionary of its own. One name is authoritative, the other is short, and both live in the model.
The system holding the authoritative data for this object: SODH Gold, MDM Product, Group Finance. ONE MEANING ONLY. It had drifted into naming the document a record came from ("SODH back-doc v0.7"), and into packing a system and a relation into one string ("SODH Gold / F_SELL_OUT"). The relation belongs in physicalName; the document belongs nowhere -- provenance of a record is not a property of the thing it describes. MUST NOT appear on a Business Concept: a concept has no data source. Its authority is its owning domain and its definition is published in the glossary. Enforced by SHACL. On a Metric it is asserted rather than derived, by exception, because "where can I get this metric" is a first-order question and the derivation chain (computedBy, then the data object holding the element) will have gaps before harvesting. A shape checks the assertion against the elements.
TO_ARBITRATE blocks publication (OW-007). Use this on the object rather than tracking arbitration in a side spreadsheet.
The meaning of a business notion. Belongs to the BusinessConcept. MUST NOT be carried by a BusinessObject: an object gets its meaning through aboutConcept. Two definitions for one notion are two definitions free to diverge. Enforced by SHACL rather than by rdfs:domain, because Data Elements legitimately carry one too and a declared domain would make them entail BusinessConcept -- which the disjointness axioms would then reject. MIGRATION: text currently on a Business Object moves to the Concept named by its aboutConcept.
From the Units LoV. Note the LoV currently mixes physical units, currencies (ISO 4217) and value types (Index, Rate, Count) - three different concepts that should eventually be split.
Free-text grain label on a Metric, e.g. 'SKU x Customer x Day'. Kept a second, unverifiable copy of something now stated structurally on the Data Object. Grain is a property of a dataset, not of a calculation rule.
Duplicated the KPI class. Two ways to say the same thing are two ways to diverge.
Free text. 'Which objects depend on MDM Product?' was unanswerable because MDM Product was a string, not a node.
Recorded verbatim, never altered (NR-009). Must NOT be carried by a Metric - that is a layer leak; under BR-013 the physical name belongs on the Data Element.
DATABASE.SCHEMA.RELATION[.COLUMN]. The actual join key against INFORMATION_SCHEMA: a bare physical name is ambiguous as soon as the same column name exists in two tables.
Native immutable id in the source system (Snowflake object id, Tableau LUID, Looker id). Makes reconciliation idempotent and survives renames, which names do not.
Staleness marker. A Captured Object not refreshed by the last run is a deletion candidate, not a fact.
Git URI of the code behind a Transformation. Connects the graph to the repository.
Volumetry with no identified use. queryCount30d and lastQueriedOn carry the rationalisation argument; row count does not.
Lets the model say 'documented but unused for eight months'. A rationalisation argument that costs nothing and is denominated in warehouse spend.
The calculated-field formula, Tableau or LookML. Compared against the Metric formula to detect definition drift.