ProMoTe is under active development and evaluation from both the academic community and our industrial partners. If you intend to use this standard, feel free to reach out with questions and or feedback.
This document is licensed under the Creative Commons BY 4.0 license.
- ProMoTe
- Disclaimer
- License
- Table of Contents
- Introduction
- ProMoTe from a bird's-eye view
- How to read and use this document.
- External Documents
- Specification
- Class: Resource
- Property: Title
- Property: Resource Provider
- Property: Domain
- Property: Identifier
- Property: Description
- Property: Date Issued
- Property: Date Modified
- Property: Resource Type
- Property: Keyword
- Property: Language
- Property: Institutional Knowledge
- Property: Newer Version
- Property: Older Version
- Property: Consumes
- Property: Source System
- Property: Is Consumed By
- Property: Estimated Value
- Property: Qualified Attribution
- Property: Catalog Record
- Class: Domain
- Class: Institutional Knowledge
- Class: Data Product
- Class: Use Case
- Class: Data Asset
- Class Distribution
- Class: Output Port
- Class: Data Contract
- Class: Input Port
- Class: Control Port
- Class: Resource
ProMoTe is a data Product Modelling Template for describing data products in a data mesh environment in a technology-independent manner. It was originally designed by researchers collaborating with large European companies that were looking to transition from a centralised, monolithic data landscape towards a more decentralised data-mesh (like) data landscape. ProMoTe is grounded in academic literature and industrial practice. It extends well-established ontologies (primarily DCAT) in a way that is intended to help create data products that achieve the DAUTNIVS+ non-functional requirements (Discoverability, Addressability, Understandability, Truthful & Trustworthy, Natively Accessible, Interoperable, Valuable and Secure + Feedback-Driven). The first eight of these are described extensively in the original data mesh book, published by Dehghani in 2020, whereas being Feedback-Driven originates from a desire to develop data products in an agile manner, akin to how DevOps has become standard practice for software development.
The figure below shows an overview in UML of the classes described in ProMoTe and the relations that can be used to describe them; the classes and relations are also described in detail below. Additionally, whenever relevant, we describe how the different classes and properties contribute to achieving DAUTNIVS+ in the "Motivation" field. At a high level ProMoTe extends the dcat:Resource class with a subclass: pmt:Resource. pmt:Resources come in three varieties: the pmt:DataAsset, which is a subclass of dct:Dataset; the pmt:Dataproduct, which is the architectural quantum of a data mesh and the main focus of ProMoTe; and the pmt:UseCase, that describes how the data is consumed. Data Products make available one or more data sets. Each data set has one or more physical representations (distributions), which are exposed throught output ports.
Each resource is managed within a pmt:Domain that maintains semantic domain knowledge in pmt:InstitutionalKnowledge. Data products ingest data through one or more pmt:InputPorts and are governed through policies that are managed through pmt:ControlPorts. Finally, data products make available one or more dct:Distributions of pmt:DataAssets through an associated pmt:OutputPort. For each output port, an associated pmt:DataContract establishes the conditions that apply when consuming the underlying data.
With ProMoTe, you can help define metadata models to describe data products in the data catalogue of your data mesh, or it can help you determine what a data product should look like within your organisation and whether different maturity levels that contain various aspects exist. An academic paper illustrating these use cases of ProMoTe is underway. The core concepts of ProMoTe are also available as an ontology in a .owl-file, which can be found here.
The key words MAY, MUST, MUST NOT, and SHOULD in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here.
ProMoTe is compliant with and incorporates terms from the DCAT vocabulary, which in turn makes use of other vocabularies. This means that ProMoTe can both extend existing implementations using these standards and be extended with terminology from those vocabularies.
The following properties are specific to this class: title, resource provider, domain, identifier, description, date issued, date modified, resource type, keyword, language, institutional knowledge, newer version, older version, estimated value, qualified attribution, catalog record.
| Class: | pmt:Resource |
|---|---|
| Definition: | A data product, data asset or use case that can be described on a data catalog. |
| Subclass of: | dcat:Resource |
| Comment | The class of all data sets, data products and use cases that exist and are registered in the data catalog of the data mesh. |
| Usage Note: | If the data catalog also contains information on data sevices, this class can be used in conjunction with dcat:DataService. |
| Property: | dct:title |
|---|---|
| Definition: | A name given to the item. |
| Range: | rdfs:Literal |
| Motivation: | A title contributes to Discoverability, Addressability (if unique), and Understandability. |
| Property | pmt:resourceProvider |
|---|---|
| Definition: | The agent responsible for providing the resource. |
| SubProperty of: | dct:publisher |
| Range: | foaf:Agent |
| Usage Note: | Resource Providers are either data product providers or use case providers. |
| Motivation: | Resource providers are necessary to achieve Addressability, as well as making the development of the resource Feedback-Driven. |
| Property: | pmt:domain |
|---|---|
| Definition | The domain from which the resource stems. |
| Range: | pmt:Domain |
| Motivation: | Domains make resources more Addressable and Discoverable. |
| Property: | dct:identifier |
|---|---|
| Definition | An unambiguous reference to the resource within a given context. |
| Usage Note: | Common values are a urn or url. |
| Motivation: | A unique identifier is a necessity for Addressability. |
| Property | dct:description |
|---|---|
| Definition | A human-readable account of the resource. |
| Motivation: | Descriptions make the resource more Understandable. Additionally, descriptions can contribute to Discoverability if they are indexed in a data catalog. |
| Property: | dct:issued |
|---|---|
| Definition | Date when the resource was first made available for consumers. |
| Range: | xsd:date |
| Motivation: | Adding the date issued contributes to the Understandability of the resource. |
| Property: | dct:modified |
|---|---|
| Definition | Date when the resource was last modified. |
| Range: | xsd:date |
| Motivation: | The date modified contributes to the Understandability, Interoperability, and Trustworthiness & Truthfulness. |
| Property: | pmt:type |
|---|---|
| Definition | The type of the resource. |
| subPropertyOf: | dct:Type |
| Range: | {pmt:DataProduct, pmt:UseCase, pmt:DataAsset} |
| Motivation: | Describing the type of resource contributes to Discoverability and Understandability. |
| Property: | dcat:keyword |
|---|---|
| Definition | A keyword or tag describing the resource. |
| Range: | rdfs:Literal |
| Motivation: | Keywords contribute primarily to Discoverability and, to a lesser extent, to Understandability. |
| Property: | dct:language |
|---|---|
| Definition | A keyword or tag describing the resource. |
| Range: | rdfs:Literal |
| Motivation: | Describing the language of the resource contributes primarily to Understandability. |
| Property: | pmt:institutionalKnowledge |
|---|---|
| Definition | Existing terminology within the organisation or domain that relates to a pmt:Resource. |
| Range: | pmt:InstitutionalKnowledge |
| Motivation: | Institutional knowledge contributes to Discoverability, Understandability and Interoperability. |
| Property: | pmt:hasNewVersion |
|---|---|
| Definition | A newer version of the data product, which will eventually replace this version. |
| Comment: | This property is used for versioning, keeping an older version available helps consumers of the resources by giving them time to migrate to the new resource. |
| isDefinedBy: | dct:hasVersion |
| Range: | pmt:Resource |
| Usage Note: | Recommended usage is to describe until when this resource is available in the dct:description property. |
| Motivation: | Versioning in general contributes to Discoverability, Addressability, Understandability, Truthfulness & Trustworthiness, and Interoperability. |
| Property: | pmt:hasOldVersion |
|---|---|
| Definition | An older version of the data product, which this version is replacing. |
| Comment: | This property is used for versioning, keeping an older version available helps consumers of the resources by giving them time to migrate to the new resource. |
| isDefinedBy: | dct:isVersionOf |
| Range: | pmt:Resource |
| Usage Note: | Recommended usage is to describe when the old resource is no longer available in the dct:description property. |
| Motivation: | Versioning in general contributes to Discoverability, Addressability, Understandability, Truthfulness & Trustworthiness, and Interoperability. |
| Property: | pmt:consumes |
|---|---|
| Definition | A resource or output port of a data product which is consumed to create or maintain this resource. |
| Range | {pmt:Resource, pmt:OutputPort} |
| Usage Note: | This property is an inverse property of pmt:isConsumedBy |
| Motivation: | In addition to making data products Feedback-Driven, tracking lineage in general contributes to Discoverability, Addressability, Understandability, and Interoperability. |
| Property: | pmt:sourceSystem |
|---|---|
| Definition | An IT system that generates or stores data in this resource, such as a specific data warehouse, data lake, or database. |
| Range | {pmt:DataAsset, pmt:Distribution} |
| Usage Note: | This property can be used to describe either where a specific data set or distribution lives, or give information on the input port of a data product. |
| Motivation: | In addition to making data products Feedback-Driven, tracking lineage in general contributes to Discoverability, Addressability, Understandability, and Interoperability. |
| Property: | pmt:isConsumedBy |
|---|---|
| Definition: | An input port of a data product or a use case that consumes this data product. |
| Range: | pmt:InputPort, pmt:UseCase |
| Usage Note: | Linking consuming data products helps establish data lineage, whereas linking use cases to data products improves the discoverability, understandability of the data product and helps establish a pmt:estimatedValue |
| Motivation: | In addition to making data products Feedback-Driven, tracking lineage in general contributes to Discoverability, Addressability, Understandability, and Interoperability. |
| Property: | pmt:estimatedValue |
|---|---|
| Definition | An indication of the value the resource provides for the company. |
| Usage Note: | Ideally the estimated value is backed by a quantifier, such as money or manhours saved. Otherwise a qualitative description of the value provided can be provided. |
| Motivation: | Explicitly including an estimated value is necessary for establishing that a resource is Valuable. |
| Property: | prov:qualifiedAttribution |
|---|---|
| Definition | A link to an agent, other than the pmt:resourceProvider, that is bears some responsibility for the resource. |
| Usage Note: | Qualified attributions are useful when ownership is split amongst several owners, such as a business owner and a technical owner. |
| Motivation: | Qualified Attributions contribute to the Addressability of the resource. |
| Property: | pmt:catalogRecord |
|---|---|
| Definition | The record describing this resource in a data catalog |
| Range: | dcat:CatalogRecord |
| Motivation: | Catalog records contribute to Discoverability, Addressability, Understandability, Interoperability and Value. |
The following properties are specific to this class: resource, domain knowledge, domain owner, domain participant.
| Class: | pmt:Domain |
|---|---|
| Definition: | The organisational sphere of knowledge and activity from which the data originates. |
| Usage Note: | Aligning data and software with domains is one of the primary concerns of building a data mesh and domain-driven design in general. |
| Motivation: | Domains make resources more Addressable and Discoverable. |
| Property: | pmt:hasResource |
|---|---|
| Definition: | A resource offered in the domain. |
| Range: | [pmt:Resource](#class-resource) |
| Usage Note: | This is an inverse property of pmt:domain |
| Property: | pmt:domainKnowledge |
|---|---|
| Definition | Existing terminology within the organisation or domain that relates to a pmt:Resource. |
| Range: | pmt:InstitutionalKnowledge |
| Usage Note: | This is an inverse property of pmt:definingDomain |
| Motivation: | Institutional knowledge contributes to Discoverability, Understandability and Interoperability. |
| Property: | pmt:domainOwner |
|---|---|
| Definition | The person who carries the high-level responsibility for domain, the business processes in it and the data they generate. |
| Range: | foaf:Agent |
| Motivation: | Domain owners help assign responsibility for the different data products, which contributes to Addressability. |
| Property: | pmt:domainParticipant |
|---|---|
| Definition | A person who is active within the domain. |
| Range: | foaf:Agent |
The following properties are specific to this class: defining domain, knowledge URI.
| Class: | pmt:InstitutionalKnowledge |
|---|---|
| Definition: | Superclass of terminology within the organisation or domain that can be related to a pmt:Resource. |
| Usage Note: | Examples include how the data relates to specifically defined terms, business objects or business processes. |
| Usage Note: | Recommended usage is to organise institutional knowledge in (existing) ontologies or business glossaries. |
| Motivation: | Institutional knowledge contributes to Discoverability, Understandability and Interoperability. |
| Property: | pmt:definingDomain |
|---|---|
| Definition: | The domain that defines and maintains the institutional knowledge. |
| Usage Note: | This is an inverse property of pmt:institutionalKnowledge |
| Usage Note: | It is possible that a piece of institutional knowledge is maintained on an organisation-wide level, rather than on a domain-level, but there should still be a domain responsible for maintining organisation-wide knowledge. |
| Property: | pmt:knowledgeURI |
|---|---|
| Definition: | A link to documentation about the institutional knowledge. |
| Usage Note: | Best practice is to store institutional knowledge in a business glossary or domain ontologies. |
The following properties are specific to this class: data provider, data asset, output port, input port, control port, transformation logic, enforcement logic.
The following properties are inherited from the super-class pmt:Resource: title, domain, identifier, description, date issued, date modified, resource type, keyword, language, institutional knowledge, newer version, older version, consumes, consumed by, estimated value, qualified attribution.
| Class: | pmt:DataProduct |
|---|---|
| Definition: | A data product, in a data mesh environment. |
| Subclass of: | pmt:Resource |
| Usage Note: | The class of all data products that exist and are registered in the data catalog of the data mesh. |
| Usage Note: | This class describes all everything that holds true across all underlying data assets, distributions, and output ports in the data product. |
| Property: | pmt:dataProvider |
|---|---|
| Definition: | The actor responsible for providing the data product. |
| SubPropertyOf: | pmt:resourceProvider |
| Motivation: | Data providers are essential to achieve Addressability, as well as making the development of the resource Feedback-Driven. |
| Property: | pmt:dataAsset |
|---|---|
| Definition: | A data asset that is offered through this data product. |
| Range: | pmt:Data Asset |
| Usage Note: | This is an inverse property of pmt:offeredInDataProduct |
| Property: | pmt:outputPort |
|---|---|
| Definition: | An output port that exposes a distribution of this data product. |
| Range: | pmt:OutputPort |
| Usage Note: | This is an inverse property of pmt:exposesDataProduct |
| Motivation: | Output ports make different distributions of a data product's data assets Natively Accessible. Additionally, tracking lineage in general contributes to Discoverability, Addressability, Understandability, and Interoperability. |
| Property: | pmt:inputPort |
|---|---|
| Definition: | An input port through which data is ingested into this data product. |
| Range: | pmt:InputPort |
| Motivation: | In addition to making data products Feedback-Driven, tracking lineage in general contributes to Discoverability, Addressability, Understandability, and Interoperability. |
| Property: | pmt:controlPort |
|---|---|
| Definition: | A control port through which the policies of this data product are managed. |
| Range: | pmt:ControlPort |
| Property: | pmt:transformationLogic |
|---|---|
| Definition: | The logic or code used to transform data coming in from the input ports of the data product to the distributions that are exposerd through the output ports. |
| Property: | pmt:enforcementLogic |
|---|---|
| Definition: | The logic or code used to (semi-)automatically enforce the policies that govern the data product. |
| Motivation: | Automating enforcement logic contributes to the Truthfulness & Trustworthiness of the data product. |
The following property is specific to this class: planned end date.
The following properties are inherited from the super-class pmt:Resource: title, resource provider, domain, identifier, description, date issued, date modified, resource type, keyword, language, institutional knowledge, newer version, older version, consumes, estimated value, qualified attribution.
| Class: | pmt:UseCase |
|---|---|
| Definition: | A use case of a data product, in a data mesh environment. |
| Subclass of: | pmt:Resource |
| Usage Note: | This is the class of all use cases that consume data products and are registered in the data catalog of the data mesh. |
| Usage Note: | If use cases generate new data, they can, over time also lead to new data products. |
| Motivation: | Explicitly tracking use cases contributes to Discoverability, Understandability, Interoperability, Value and Feedback-Driven development. |
| Property: | pmt:plannedEndDate |
|---|---|
| Definition: | The date by which the use case plans to stop consuming data products. |
| Usage Note: | Keeping track of a planned end date helps with data product maintenance. There is no need to put effort into maintaining a data product if there are no active use cases. |
| Usage Note: | If there is no foreseeable end date, the planned end date can be indefinite. |
| Motivation: | Planned end dates of use cases are important for establishing Value and achieving Feedback-Driven development. |
The following properties are specific to this class: distribution, logical, data product.
The following properties are inherited from the super-class pmt:Resource: title, resource provider, domain, identifier, description, date issued, date modified, resource type, keyword, language, institutional knowledge, newer version, older version, consumes, consumed by, estimated value, qualified attribution.
The following properties are inherited from the super-class dcat:Dataset: spatial/geographic coverage, spatial resolution, temporal coverage, temporal resolution.
| Class: | pmt:DataAsset |
|---|---|
| Definition: | A collection of data that can be described by a single logical schema and be consumed in one or more techincal representations (distributions) through one or more output ports. |
| Sub-class of: | pmt:Resource |
| Usage Note: | This class describes the conceptual dataset. One or more representations might be available, with differing schematic layouts and formats or serializations. |
| Usage Note: | A data asset can exist as a precursor to a data product and evolve to become a fully mature data produt over time. Not every data set needs to become a fully function data product however. Additionally, it is possible for a single data product to provide (access to) multiple data assets. |
| Property: | dcat:distribution |
|---|---|
| Definition: | A physical manifestion of the data asset. |
| Property: | pmt:logicalSchema |
|---|---|
| Definition: | A description of the data structure and internal relations at the data asset-level. |
| Usage Note: | Logical schemas describe the structure of data that holds true across different distributions of the data asset. Structural descriptions of different distributions are described in pmt:technicalSchema |
| Motivation: | Logical schemas contribute to Understandability and Interoperability. |
| Property: | pmt:offeredInDataProduct |
|---|---|
| Definition: | A data product that makes this data asset available for consumption. |
| Range: | pmt:DataProduct |
| Usage Note: | This is an inverse property of pmt:dataAsset |
The following property is specific to this class: technical schema. The following property is shared with the pmt:DataProduct class: output port.
The following properties are inherited from the super-class dcat:Distribution: spatial/geographic coverage, spatial resolution, temporal coverage, temporal resolution.
| Class: | pmt:Distribution |
|---|---|
| Definition: | A technical collection of data representating one or more data assets. Data assets might be available in multiple serializations that may differ in various ways, including natural language, media-type or format, schematic organization, temporal and spatial resolution, level of detail or profiles (which might specify any or all of the above). A distribution might also combine information from multiple data assets. |
| Subclass-of: | dcat:Distribution |
| Usage Note: | This represents a general availability of a dataset. It implies no information about the actual access method of the data, which is described in pmt:OutputPort. |
| Property: | pmt:correspondingOutputPort |
|---|---|
| Definition: | An output port that exposes this distribution. |
| Range: | pmt:OutputPort |
| Usage Note: | This is an inverse property of pmt:exposesDistribution |
| Motivation: | Output ports make different distributions of a data product's data assets Natively Accessible. Additionally, tracking lineage in general contributes to Discoverability, Addressability, Understandability, and Interoperability. |
| Property: | pmt:physicalSchema |
|---|---|
| Definition: | A description of the data structure and internal relations at the distribution-level. |
| Usage Note: | Physical schemas describe the structure of data of a specific distribution of a pmt:DataAsset. Structural descriptions that hold true across all distributions of a data asset are described in pmt:logicalSchema |
| Motivation: | Physical schemas help with Understandability and Interoperability. |
| Property | dct:description |
|---|---|
| Definition | A human-readable account of the distribution. |
| Motivation: | Adding a description of the distribution improves Understandability, and potentially Discoverability and Interoperability. |
The following properties are specific to this class: distribution, data product.
| Class: | pmt:OutputPort |
|---|---|
| Definition: | An output port of a data product that exposes a specific representation. |
| Usage Note: | Output ports represent the various ways in which data products expose their data. For example, data can be made available through a download link, a SQL-based API or a kafka-stream. |
| Motivation: | Output ports are necessary for achieving Native Accessability. |
| Property: | pmt:exposesDistribution |
|---|---|
| Definition: | The distribution that is exposed for consumption through this output port. |
| Range: | dcat:Distribution |
| Property: | pmt:exposesDataProduct |
|---|---|
| Definition: | The data product that this output port exposes for consumption. |
| Usage Note: | This is an inverse property of pmt:outputPort |
| Range: | pmt:DataProduct |
| Property | pmt:consumeInstructions |
|---|---|
| Definition | A unique URI for the endpoint of this output port. |
| See Also of: | dcat:endpointURL |
| Motivation: | Unique endpoints contribute to Addressability and Native Accessibility. |
| Property | pmt:consumeInstructions |
|---|---|
| Definition | Human-readable instructions on how to consume data through this output port. |
| SubProperty of: | dcat:endpointDescription |
| Usage note: | Consume instructions are the informal equivalent of the pmt:dataContract, which captures the formal promises and expectations of this output port. |
| Motivation: | Consume instructions help with making the data Natively Accessible, and, potentially, Interoperable. |
| Property: | pmt:isConsumedBy |
|---|---|
| Definition: | The input port of a data product or a use case that consumes this data product. |
| Range: | pmt:InputPort, pmt:UseCase |
| Usage Note: | Linking consumed data products and operational sources helps establish data lineage, as well a pmt:estimatedValue for the connsumed data products. |
| Motivation: | Keeping track of who consumes what data contributes to determining Value, as well as establishing data lineage. In addition to making data products Feedback-Driven, tracking lineage in general contributes to Discoverability, Addressability, Understandability, and Interoperability. |
| Property | pmt:dataContract |
|---|---|
| Definition | A data contract associated with an output port. If the output port is the input port of another data contract, the data contract regulates how the data flows into that data product. |
| Motivation: | Data Contracts contribute to Understandability, Truthfulness & Trustworthiness, Native Accessibility and Security. |
| Property | pmt:accessManagement |
|---|---|
| Definition | The enforcement of access rights on an output port. |
| Usage Note | Access Management is usually provided by the organisation as part of a larger IAM framework |
| Motivation: | Access Mangement contributes to Security, Native Accessibility and Feedback-Driven. |
The following properties are specific to this class: providerPromise, consumerPromise, service level agreement, service level objective.
| Class: | pmt:DataContract |
|---|---|
| Definition: | A collection of enforceable promises concerning the delivery of a data product or use case. |
| Usage Note: | Data contracts are highly dependable on the requirements and culture of the organisation implementing a data mesh. External standards, can and should be used to establish and describe data contracts. Examples include the SCC for transferring data outside of the EU, ISO9001 for security purposes or Paypal's standard for a data contract in a data mesh. |
| Motivation: | Data Contracts contribute to Understandability, Truthfulness & Trustworthiness, Native Accessibility and Security. |
| Property: | pmt:providerPromise |
|---|---|
| Definition: | A promise made by the pmt:dataProvider to the data consumer that is captured in the data contract. |
| Usage Note: | Provider promises can also be captured in a pmt:SLA, pmt:SLO or in a pmt:policy |
| Motivation: | Provider promises contribute to Truthfulness & Trustworthiness, Native Accessibility and Security. |
| Property: | pmt:consumerPromise |
|---|---|
| Definition: | A promise required from the data consumer to the pmt:dataProvider that is captured in the data contract. |
| Usage Note: | Consumer promises can also be captured in a pmt:SLA or in a pmt:policy. |
| Motivation: | Consumer promises contribute to Security. |
| Property: | pmt:policy |
|---|---|
| Definition | A policy that is explained and enforced in the data contract. |
| Usage Note: | A wide variety of policies may exist that manage different aspects of the data product such as: computational policies, data product standardized protocols, and automated tests and automated monitoring. |
| Usage Note: | Best practice is to use additional documentation to describe and manage the different types of policies that exist within a data mesh ecosystem. |
| Motivation: | Policies can contribute to one or more of Understandability, Truthfulness & Trustworthiness and Security. |
| Property: | pmt:SLA |
|---|---|
| Definition: | A service level agreement related to the delivery of data through the output port of this data contract. |
| Usage Note: | Best practice is to use additional documentation to describe and manage SLAs in the data mesh ecosystem. |
| Motivation: | Service level agreements contribute to Understandability, Truthfulness & Trustworthiness, Native Accessibility and Security. |
| Property: | pmt:SLO |
|---|---|
| Definition: | A service level objective related to the delivery of data through the output port of this data contract. |
| Usage Note: | Best practice is to use additional documentation to describe and manage SLOs in the data mesh ecosystem. |
| Motivation: | Service level objectives contribute to Understandability, Truthfulness & Trustworthiness, Native Accessibility and Security. |
| Class: | pmt:InputPort |
|---|---|
| Definition: | An input port of a data product which relates to a source system or an output port of another data product. |
| Motivation: | Keeping track of who consumes what data contributes to determining Value, as well as establishing data lineage. In addition to making data products Feedback-Driven, tracking lineage in general contributes to Discoverability, Addressability, Understandability, and Interoperability. |
| Property | dct:description |
|---|---|
| Definition | A human-readable account of the input port. |
| Motivation: | Adding a description of the distribution improves Understandability, and potentially Discoverability and Interoperability. |
| Property | pmt:correspondingDataProduct |
|---|---|
| Definition | The data product of this input port. |
| Usage Note | This is an inverse property of pmt:inputPort |
| Property: | pmt:consumes |
|---|---|
| Definition | A resource or output port of a data product which is consumed to create or maintain this input port. |
| Range | {pmt:Resource, pmt:OutputPort} |
| Usage Note: | This property is an inverse property of pmt:isConsumedBy |
| Motivation: | Keeping track of who consumes what data contributes to determining Value, as well as establishing data lineage. In addition to making data products Feedback-Driven, tracking lineage in general contributes to Discoverability, Addressability, Understandability, and Interoperability. |
| Property: | pmt:sourceSystem |
|---|---|
| Definition | An IT system that generates or stores data that is used for this data product, such as a speficic data warehouse, data lake, or database. |
| Domain | {pmt:DataAsset, pmt:InputPort} |
| Usage Note: | This property can be used to describe either where a specific data set or distribution lives, or give information on the input port of a data product. |
| Motivation: | In addition to making data products Feedback-Driven, tracking lineage in general contributes to Discoverability, Addressability, Understandability, and Interoperability. |
| Property | pmt:dataContract |
|---|---|
| Definition | A data contract associated with an output port. If the output port is the input port of another data contract, the data contract regulates how the data flows into that data product. |
| Motivation: | Data Contracts contribute to Understandability, Truthfulness & Trustworthiness, Native Accessibility and Security. |
| Property: | pmt:physicalSchema |
|---|---|
| Definition: | A description of the data structure and internal relations at the distribution-level. |
| Usage Note: | Physical schemas describe the structure of data of a specific distribution of a pmt:DataAsset. Structural descriptions that hold true across all distributions of a data asset are described in pmt:logicalSchema |
| Motivation: | Physical schemas help with Understandability and Interoperability. |
| Class: | pmt:ControlPort |
|---|---|
| Definition: | A control port through which a data product's policies can be managed by external parties such as the pmt:dataProvider or a federated governance team. |
| Usage Note: | Since control ports are highly dependent on the infrastructure provided in the data mesh, as well as the policies employed in the organisation, description of control ports SHOULD be extended with external documentation as the situation requires. |
| Property | dct:description |
|---|---|
| Definition | A human-readable account of the control port. |
| Property | pmt:correspondingDataProduct |
|---|---|
| Definition | The data product whose policies are managed through this control port. |
| Usage Note | This is an inverse property of pmt:controlPort |
| Property: | pmt:managedPolicy |
|---|---|
| Definition | A policy that can be managed through this control port. |
| Usage Note: | A wide variety of policies may exist that manage different aspects of the data product such as: computational policies, data product standardized protocols, and automated tests and automated monitoring. |
| Usage Note: | Best practice is to use additional documentation to describe and manage the different types of policies that exist within a data mesh ecosystem. |