From 2644a51c7d61bccba1e7bc9f206496fc2f8e21b8 Mon Sep 17 00:00:00 2001 From: Mandy Chessell Date: Wed, 21 Feb 2024 12:43:28 +0000 Subject: [PATCH] Add code for getBasicServerProperties Signed-off-by: Mandy Chessell --- site/docs/concepts/catalog-target.md | 2 +- site/docs/concepts/connector.md | 2 +- site/docs/concepts/digital-resource.md | 13 +++ .../concepts/discovery-analysis-report.md | 2 +- .../concepts/governance-engine-definition.md | 14 ++-- .../docs/concepts/governance-service-types.md | 4 +- site/docs/concepts/index.md | 1 + site/docs/concepts/memento.md | 2 +- site/docs/concepts/open-discovery-engine.md | 2 +- site/docs/concepts/resource.md | 7 +- site/docs/concepts/survey-action-engine.md | 2 +- site/docs/concepts/survey-report.md | 2 +- .../discovery/discovery-service-intro.md | 2 +- .../digital-resource-connector-intro.md | 2 +- .../survey-action-service-intro.md | 2 +- .../metadata-governance/common-definitions.md | 2 +- site/docs/features/data-quality/overview.md | 2 +- .../discovery-and-stewardship/overview.md | 2 +- site/docs/features/index.md | 10 +-- .../features/lineage-management/overview.md | 2 +- .../people-roles-organizations/overview.md | 2 +- site/docs/frameworks/saf/annotation-intro.md | 2 +- .../saf/survey-action-pipeline-intro.md | 2 +- site/docs/guides/admin/egeria-admin.drawio | 81 +++++++++---------- ...guration-document-structure-simplified.svg | 4 + site/docs/guides/admin/servers/index.md | 51 ++++-------- .../servers/omag-server-connector-types.svg | 4 +- .../guides/developer/developer-choices.md | 2 +- .../discovery-annotation-intro.md | 2 +- .../discovery-pipeline-intro.md | 2 +- site/docs/parameters/for-lineage.md | 2 +- .../categories-of-metadata.md | 2 +- .../patterns/metadata-manager/overview.md | 2 +- .../semantic-to-implementation.md | 2 +- site/docs/practices/roles/overview.md | 2 +- .../services/omas/asset-consumer/overview.md | 4 +- .../asset-consumer/working-with-connectors.md | 2 +- .../services/omes/asset-analysis/overview.md | 2 +- site/docs/types/0/0045-Servers-and-Assets.md | 2 +- site/docs/types/2/0210-Data-Stores.md | 6 +- site/docs/types/4/0461-Governance-Engines.md | 2 +- site/docs/types/5/0540-Data-Classes.md | 2 +- site/docs/types/7/0710-Digital-Service.md | 2 +- site/mkdocs.yml | 1 + .../calls/get-basic-server-properties.md | 38 +++++++++ .../admin/calls/get-stored-configuration.md | 39 +++++++++ ...onfiguring-omag-server-basic-properties.md | 5 +- 47 files changed, 210 insertions(+), 134 deletions(-) create mode 100644 site/docs/concepts/digital-resource.md create mode 100644 site/docs/guides/admin/servers/configuration-document-structure-simplified.svg create mode 100644 site/snippets/admin/calls/get-basic-server-properties.md create mode 100644 site/snippets/admin/calls/get-stored-configuration.md diff --git a/site/docs/concepts/catalog-target.md b/site/docs/concepts/catalog-target.md index 0467f61b31..e2343873af 100644 --- a/site/docs/concepts/catalog-target.md +++ b/site/docs/concepts/catalog-target.md @@ -3,7 +3,7 @@ # Catalog Target -A *catalog target* describes the third party technology ([resource](/concepts/resource)) that a specific [integration connector](/concept/integration-connector) is exchanging metadata with. +A *catalog target* describes the third party technology ([digital resource](/concepts/digital-resource)) that a specific [integration connector](/concept/integration-connector) is exchanging metadata with. ## Catalog Target Types diff --git a/site/docs/concepts/connector.md b/site/docs/concepts/connector.md index a2835cae95..71c9518a32 100644 --- a/site/docs/concepts/connector.md +++ b/site/docs/concepts/connector.md @@ -8,7 +8,7 @@ hide: # Connector -A connector is a client library for accessing a [resource](/concepts/resource) and, optionally, its associated [asset](/concepts/asset) metadata. +A connector is a client library for accessing a [digital resource](/concepts/digital-resource) and, optionally, its associated [asset](/concepts/asset) metadata. The concept of a connector comes from the [Open Connector Framework (OCF)](/frameworks/ocf/overview). The OCF provides a common framework for components (ie connectors) that enable one technology to call another, arbitrary technology through a common interface. The implementation of the connector is dynamically loaded based on the connector's configuration. diff --git a/site/docs/concepts/digital-resource.md b/site/docs/concepts/digital-resource.md new file mode 100644 index 0000000000..ccc8b002bf --- /dev/null +++ b/site/docs/concepts/digital-resource.md @@ -0,0 +1,13 @@ +--- +hide: +- toc +--- + + + + +# Digital Resource + +A *digital resource* is a [resource](/concepts/resource) that is implemented using software (supported by hardware of course). It is catalogued in open metadata using an [Asset](/concepts/asset) and is accessed via a [digital resource connector](/concepts/digital-resource-connector). + +--8<-- "snippets/abbr.md" diff --git a/site/docs/concepts/discovery-analysis-report.md b/site/docs/concepts/discovery-analysis-report.md index 6f59027311..33a56bf1a1 100644 --- a/site/docs/concepts/discovery-analysis-report.md +++ b/site/docs/concepts/discovery-analysis-report.md @@ -10,7 +10,7 @@ hide: A *discovery analysis report* contains one or more sets of related properties that an [open discovery service](/concepts/open-discovery-service) has discovered about the resource, its metadata, structure and/or content. These are stored in a set of [discovery annotations](#discovery-annotations) linked off of the discovery analysis report. -It is attached to the [asset](/concepts/asset) for the [digital resource](/concepts/resource) that was analysed. Overtime, the discovery analysis reports show how the digital resource's contents are changing. +It is attached to the [asset](/concepts/asset) for the [digital resource](/concepts/digital-resource) that was analysed. Overtime, the discovery analysis reports show how the digital resource's contents are changing. ![Asset with discovery analysis reports](/guides/developer/open-discovery-services/asset-to-discovery-analysis-reports.svg) diff --git a/site/docs/concepts/governance-engine-definition.md b/site/docs/concepts/governance-engine-definition.md index 1380269b46..9b32ae976d 100644 --- a/site/docs/concepts/governance-engine-definition.md +++ b/site/docs/concepts/governance-engine-definition.md @@ -17,11 +17,11 @@ A *governance engine definition* describes the [governance services](/concepts/g There are three types of governance engine and they each support a specialist type of governance service. Therefore, the governance engine definitions include definitions of governance services that are consistent with the type of governance engine. -| Type of Governance Engine | Type of Governance Service | Description | -|---|---|---| -| [Governance action engine](/concepts/governance-action-engine) | [Governance action service](/guides/developer/governance-action-services/overview)| Monitor and manage the content of open metadata across the open metadata landscape. | -| [Open discovery engine](/concepts/open-discovery-engine)| [Open discovery service](/guides/developer/open-discovery-services/overview) | Analyze the content of [resources](/concepts/resource) in the digital landscape and create annotations that are attached to the resource's [asset](/concepts/asset) metadata element in the open metadata repositories in the form of a [discovery analysis report](/concepts/discovery-analysis-report). | -| [Repository governance engine](/concepts/repository-governance-engine) | [Repository governance service](/guides/developer/repository-governance-services/overview) | Provide additional management of the open metadata repositories that are members of the connected [cohorts](/concepts/cohort-members). | +| Type of Governance Engine | Type of Governance Service | Description | +|------------------------------------------------------------------------|--------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| [Governance action engine](/concepts/governance-action-engine) | [Governance action service](/guides/developer/governance-action-services/overview) | Monitor and manage the content of open metadata across the open metadata landscape. | +| [Survey action engine](/concepts/survey-action-engine) | [Survey action service](/guides/developer/survey-action-services/overview) | Analyze the content of [digital resources](/concepts/digital-resource) in the digital landscape and create annotations that are attached to the resource's [asset](/concepts/asset) metadata element in the open metadata repositories in the form of a [survey report](/concepts/survey-report). | +| [Repository governance engine](/concepts/repository-governance-engine) | [Repository governance service](/guides/developer/repository-governance-services/overview) | Provide additional management of the open metadata repositories that are members of the connected [cohorts](/concepts/cohort-members). | Each governance engine definition describes a single engine and its specialized services as illustrated below. @@ -31,8 +31,8 @@ Each governance engine definition describes a single engine and its specialized ![Governance Action Engine Definition Structure](/guides/developer/open-metadata-archives/governance-action-engine-definition.svg) > Logical structure of a governance action engine definition showing how the governance request types map to the governance action service definitions -![Open Discovery Engine Definition Structure](/guides/developer/open-metadata-archives/open-discovery-engine-definition.svg) -> Logical structure of an open discovery engine definition showing how the governance request types map to the open discovery service definitions. Some of these services are *Open Discovery Pipelines* that control the choreography of a number of nested open discovery services +![Survey Action Engine Definition Structure](/guides/developer/open-metadata-archives/survey-action-engine-definition.svg) +> Logical structure of a survey action engine definition showing how the governance request types map to the survey action service definitions. Some of these services are *Survey Action Pipelines* that control the choreography of a number of nested survey action services. !!! education "Further information" diff --git a/site/docs/concepts/governance-service-types.md b/site/docs/concepts/governance-service-types.md index c1126a2ec5..4adb9c054f 100644 --- a/site/docs/concepts/governance-service-types.md +++ b/site/docs/concepts/governance-service-types.md @@ -6,7 +6,7 @@ There are ten types of governance services. Related governance services are [pa | Governance Service | Description | Governance Engine type | Engine Service | |:---------------------------------------------------------------------------------------------|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:-----------------------------------------------------------------------|:----------------------------------------------------------------------------| -| [Survey Action Service](/guides/developer/survey-action-services/overview) | Analyses the content of an [Asset's](/concepts/asset) real-world counterpart ([resource](/concepts/resource)) in the digital landscape. (For example, if the asset describes a file, the survey action service analyses the data stored in the file). Results of the analysis are stored in a [Survey Report](/concepts/survey-report) | [Survey Action Engine](/concepts/survey-action-engine) | [Survey Action OMES](/services/omes/survey-action/overview) | +| [Survey Action Service](/guides/developer/survey-action-services/overview) | Analyses the content of an [Asset's](/concepts/asset) real-world counterpart ([digital resource](/concepts/digital-resource)) in the digital landscape. (For example, if the asset describes a file, the survey action service analyses the data stored in the file). Results of the analysis are stored in a [Survey Report](/concepts/survey-report) | [Survey Action Engine](/concepts/survey-action-engine) | [Survey Action OMES](/services/omes/survey-action/overview) | | [Watchdog Governance Service](/guides/developer/governance-action-services/overview) | Monitors changes to open metadata elements and when certain changes occur (such as the creation of a new [Asset](/concepts/asset)) the watchdog service requests action from other governance services by creating either an [Engine Action](/concepts/engine-action), a [Governance Action Process](/concepts/governance-action-process) or an [Incident Report](/concepts/incident-report). | [Governance Action Engine](/concepts/governance-action-engine) | [Governance Action OMES](/services/omes/governance-action/overview) | | [Verification Governance Service](/guides/developer/governance-action-services/overview) | Tests the properties of specific open metadata elements to ensure they are set up correctly or do not indicate a situation where governance activity is required. The [results](/concepts/guard) returned from the verification service can be used to trigger other governance services as part of a [Governance Action Process](/concepts/governance-action-process). | [Governance Action Engine](/concepts/governance-action-engine) | [Governance Action OMES](/services/omes/governance-action/overview) | | [Triage Governance Service](/guides/developer/governance-action-services/overview) | Makes decisions on how to handle a specific situation or incident. Often this involves a human decision maker. | [Governance Action Engine](/concepts/governance-action-engine) | [Governance Action OMES](/services/omes/governance-action/overview) | @@ -15,7 +15,7 @@ There are ten types of governance services. Related governance services are [pa | [General Governance Action Service](/guides/developer/governance-action-services/overview) | Some form of governance activity. | [Governance Action Engine](/concepts/governance-action-engine) | [Governance Action OMES](/services/omes/governance-action/overview) | | [Event Action Service](/guides/developer/event-action-services/overview) | Event management around [Context Event](/concepts/context-event). | [Event Action Engine](/concepts/event-action-engine) | [Event Action OMES](/services/omes/event-action/overview) | | [Repository Governance Service](/guides/developer/repository-governance-services/overview) | Performs governance for open metadata repositories such as dynamically maintaining [open metadata archives](/concepts/open-metadata-archive). | [Repository Governance Engine](/concepts/repository-governance-engine) | [Repository Governance OMES](/services/omes/repository-governance/overview) | -| [Open Discovery Service](/guides/developer/open-discovery-services/overview) | Analyses the content of an [Asset's](/concepts/asset) real-world counterpart ([resource](/concepts/resource)) in the digital landscape. (For example, if the asset describes a file, the open discovery service analyses the data stored in the file). | [Open Discovery Engine](/concepts/open-discovery-engine) | [Asset Analysis OMES](/services/omes/asset-analysis/overview) | +| [Open Discovery Service](/guides/developer/open-discovery-services/overview) | Analyses the content of an [Asset's](/concepts/asset) real-world counterpart ([digital-resource](/concepts/digital-resource)) in the digital landscape. (For example, if the asset describes a file, the open discovery service analyses the data stored in the file). | [Open Discovery Engine](/concepts/open-discovery-engine) | [Asset Analysis OMES](/services/omes/asset-analysis/overview) | --8<-- "snippets/abbr.md" \ No newline at end of file diff --git a/site/docs/concepts/index.md b/site/docs/concepts/index.md index e32a9ecdba..d93f9c8e45 100644 --- a/site/docs/concepts/index.md +++ b/site/docs/concepts/index.md @@ -88,6 +88,7 @@ - [Design Model OMAS](/services/omas/design-model/overview) - [DevOps OMAS](/services/omas/dev-ops/overview) - [Digital Architecture OMAS](/services/omas/digital-architecture/overview) +- [Digital Resource](/concepts/digital-resource) - [Digital Resource Connector](/concepts/digital-resource-connector) - [Digital Service](/practices/digital-services/overview) - [Digital Service OMAS](/services/omas/digital-service/overview) diff --git a/site/docs/concepts/memento.md b/site/docs/concepts/memento.md index f8aa7de5ec..b17775989f 100644 --- a/site/docs/concepts/memento.md +++ b/site/docs/concepts/memento.md @@ -3,7 +3,7 @@ # Memento -A *Memento* is a classification that is typically applied to an asset or related elements such as schema elements. It indicates that the element is logically deleted because it is no longer describing all or part of a [real-world resource](/concepts/resource) (typically because the resource has been deleted or changed). +A *Memento* is a classification that is typically applied to an asset or related elements such as schema elements. It indicates that the element is logically deleted because it is no longer describing all or part of a [real-world digital resource](/concepts/digital-resource) (typically because the resource has been deleted or changed). This element has only been retained to support lineage graph queries. It will not be returned to callers unless: diff --git a/site/docs/concepts/open-discovery-engine.md b/site/docs/concepts/open-discovery-engine.md index 5218811628..277d1fef55 100644 --- a/site/docs/concepts/open-discovery-engine.md +++ b/site/docs/concepts/open-discovery-engine.md @@ -8,7 +8,7 @@ hide: # Open Discovery Engines -An *open discovery engine* describes a set of related [open discovery services](/guides/developer/open-discovery-services/overview). Each open discovery service implements a specific type of analysis. This analysis is looking into the content of a [digital resource](/concepts/resource) and storing its findings in annotations within a [discovery analysis report](/concepts/discovery-analysis-report) that is linked of the resource's [Asset](/concepts/asset) in the metadata repository. +An *open discovery engine* describes a set of related [open discovery services](/guides/developer/open-discovery-services/overview). Each open discovery service implements a specific type of analysis. This analysis is looking into the content of a [digital resource](/concepts/digital-resource) and storing its findings in annotations within a [discovery analysis report](/concepts/discovery-analysis-report) that is linked of the resource's [Asset](/concepts/asset) in the metadata repository. An open discovery engine is hosted in the [Asset Analysis Open Metadata Engine Service (OMES)](/services/omes/asset-analysis/overview) running on one or more [Engine Host OMAG Servers](/concepts/engine-host). diff --git a/site/docs/concepts/resource.md b/site/docs/concepts/resource.md index 9d7693619c..72b61d0cf1 100644 --- a/site/docs/concepts/resource.md +++ b/site/docs/concepts/resource.md @@ -18,10 +18,13 @@ Examples of resources include: - Analytical models and processes. - Addresses and other locations. - Physical objects such as buildings that can have a digitized representation with a unique identity (for example, serial number). +- People allocated to a project. - -Resources are described in open metadata as [Assets](/concepts/asset). +[Digital Resources](/concepts/digital-resource) and physical resources (such as computers, buildings etc) are described in open metadata as [Assets](/concepts/asset). People and teams are captured using [Actors and Person Roles](/features/people-roles-organizations/overview) In addition, the organization may capture many types of descriptions and definitions that describe their operations in open metadata, such as, for example, a [glossary term](/practices/common-data-definitions/anatomy-of-a-glossary/#inside-a-glossary-term) or a [governance definition](/services/omas/governance-program/overview/#governance-definitions). These elements can be [linked to the asset](/patterns/metadata-manager/overview) to provide more information on the resource's content, significance and proper use to the people working with the resource as well as guiding automated processes that are managing and governing it. +!!! education "ResourceList relationship" + The [ResourceList](/types/0/0019-More-Information) relationship allows the list of resources allocated to a particular activity to be linked to the open metadata element that represents the activity. + --8<-- "snippets/abbr.md" diff --git a/site/docs/concepts/survey-action-engine.md b/site/docs/concepts/survey-action-engine.md index afc7b4a958..89d3b01b44 100644 --- a/site/docs/concepts/survey-action-engine.md +++ b/site/docs/concepts/survey-action-engine.md @@ -8,7 +8,7 @@ hide: # Survey Action Engines -A *survey action engine* is a type of [governance engine](/concepts/governance-engine) that describes a set of related [survey action services](/concepts/survey-action-service). Each survey action service implements a specific type of analysis. This analysis is looking into the content of a [digital resource](/concepts/resource) and storing its findings in annotations within a [survey report](/concepts/survey-report) that is linked of the resource's [Asset](/concepts/asset) in the metadata repository. +A *survey action engine* is a type of [governance engine](/concepts/governance-engine) that describes a set of related [survey action services](/concepts/survey-action-service). Each survey action service implements a specific type of analysis. This analysis is looking into the content of a [digital resource](/concepts/digital-resource) and storing its findings in annotations within a [survey report](/concepts/survey-report) that is linked of the resource's [Asset](/concepts/asset) in the metadata repository. A survey action is hosted in the [Survey Action Open Metadata Engine Service (OMES)](/services/omes/survey-action/overview) running on one or more [Engine Host OMAG Servers](/concepts/engine-host). diff --git a/site/docs/concepts/survey-report.md b/site/docs/concepts/survey-report.md index 5cbc5bf183..27a40915c7 100644 --- a/site/docs/concepts/survey-report.md +++ b/site/docs/concepts/survey-report.md @@ -10,7 +10,7 @@ hide: A *survey report* contains one or more sets of related properties that a [survey action service](/concepts/survey-action-service) has discovered about a resource, its metadata, structure and/or content. These are stored in a set of [annotations](#annotations) linked off of the survey report. -The survey report is attached to the [asset](/concepts/asset) for the [digital resource](/concepts/resource) that was analysed. Over time, the survey reports show how the digital resource's contents are changing. +The survey report is attached to the [asset](/concepts/asset) for the [digital resource](/concepts/digital-resource) that was analysed. Over time, the survey reports show how the digital resource's contents are changing. ![Asset with discovery analysis reports](/frameworks/saf/asset-to-survey-reports.svg) diff --git a/site/docs/connectors/discovery/discovery-service-intro.md b/site/docs/connectors/discovery/discovery-service-intro.md index 613ef60716..3e0e03e3ca 100644 --- a/site/docs/connectors/discovery/discovery-service-intro.md +++ b/site/docs/connectors/discovery/discovery-service-intro.md @@ -1,7 +1,7 @@ -An *open discovery service* is a component that performs specific analysis of the contents of a [digital resource](/concepts/resource) on request. The aim of the open discovery service is to enable a detailed picture of the properties of a resource to be built up. +An *open discovery service* is a component that performs specific analysis of the contents of a [digital resource](/concepts/digital-resource) on request. The aim of the open discovery service is to enable a detailed picture of the properties of a resource to be built up. Each time an open discovery service runs, it creates a new [discovery analysis report](/concepts/discovery-analysis-report) linked off of the digital resource's [Asset](/concepts/asset) metadata element that records the results of the analysis. diff --git a/site/docs/connectors/resource/digital-resource-connector-intro.md b/site/docs/connectors/resource/digital-resource-connector-intro.md index ed54ae9f90..e2b21221e9 100644 --- a/site/docs/connectors/resource/digital-resource-connector-intro.md +++ b/site/docs/connectors/resource/digital-resource-connector-intro.md @@ -1,7 +1,7 @@ -A *digital resource connector* is used to call the API of a particular type of [digital resource](/concepts/resource) in order to access its content or metadata. They may also listen for events from the digital resource if it emits them. For example, you may have a digital resource connector to access a file, another to access a database, another to listen to an Apache Kafka topic, and another to access a system such as Apache Atlas. +A *digital resource connector* is used to call the API of a particular type of [digital resource](/concepts/digital-resource) in order to access its content or metadata. They may also listen for events from the digital resource if it emits them. For example, you may have a digital resource connector to access a file, another to access a database, another to listen to an Apache Kafka topic, and another to access a system such as Apache Atlas. ## What is the interface of a digital resource connector? diff --git a/site/docs/connectors/survey-action/survey-action-service-intro.md b/site/docs/connectors/survey-action/survey-action-service-intro.md index ec672487ed..bc4d290412 100644 --- a/site/docs/connectors/survey-action/survey-action-service-intro.md +++ b/site/docs/connectors/survey-action/survey-action-service-intro.md @@ -1,7 +1,7 @@ -An *survey-action service* is a component that performs analysis of the contents of a [digital resource](/concepts/resource) on request. The aim of the survey action service is to enable a detailed picture of the properties of a resource to be built up. +An *survey-action service* is a component that performs analysis of the contents of a [digital resource](/concepts/digital-resource) on request. The aim of the survey action service is to enable a detailed picture of the properties of a resource to be built up. Each time a survey action service runs, it creates a new [survey report](/concepts/survey-report) linked off of the digital resource's [Asset](/concepts/asset) metadata element that records the results of the analysis. diff --git a/site/docs/education/egeria-dojo/metadata-governance/common-definitions.md b/site/docs/education/egeria-dojo/metadata-governance/common-definitions.md index 646a448a0c..ac41a2db6d 100644 --- a/site/docs/education/egeria-dojo/metadata-governance/common-definitions.md +++ b/site/docs/education/egeria-dojo/metadata-governance/common-definitions.md @@ -13,7 +13,7 @@ The effort required to author and maintain a these standards, plus the governanc * [Subject Areas](/concepts/subject-area) define the standards for your resources and their use. They cover resources that are widely shared across the organization and there is business value in maintaining consistency. * Each subject area has an owner who is responsible for coordinating the development and maintenance of the subject area's materials. -* [Resources](/concepts/resource) that are managed using the subject area's materials are said to be part of the subject area's "domain". This is called the *Subject Area Domain* and is synonymous with *Data Domain* - although since a subject area domain may manage resources that are not just data assets (such as systems and infrastructure), open metadata uses a more generic name. +* [Digital Resources](/concepts/digital-resource) that are managed using the subject area's materials are said to be part of the subject area's "domain". This is called the *Subject Area Domain* and is synonymous with *Data Domain* - although since a subject area domain may manage resources that are not just data assets (such as systems and infrastructure), open metadata uses a more generic name. --8<-- "docs/practices/common-data-definitions/semantic-to-implementation.md" diff --git a/site/docs/features/data-quality/overview.md b/site/docs/features/data-quality/overview.md index 02e724fced..9ad208c912 100644 --- a/site/docs/features/data-quality/overview.md +++ b/site/docs/features/data-quality/overview.md @@ -31,7 +31,7 @@ Detected errors are [captured as exceptions](#correction-of-data) and routed to The management of data quality involves: -* [Understanding the source data values](#understanding-data-values) - Analysing the content of a [data resource](/concepts/resource), typically running [open discovery services](/features/discovery-and-stewardship/overview), to get an assessment of the data values it contains. This may be simple fact gathering using *data profiling* or executing *quality rules* to determine how well it fits to the data specifications needed for its different purposes. +* [Understanding the source data values](#understanding-data-values) - Analysing the data content of a [digital resource](/concepts/digital-resource), typically running [survey action services](/features/discovery-and-stewardship/overview), to get an assessment of the data values it contains. This may be simple fact gathering using *data profiling* or executing *quality rules* to determine how well it fits to the data specifications needed for its different purposes. * [Adding context to the data](#adding-context-to-the-data) - Using the findings from the open discovery service to assign additional classifications and links that help to identify the data as fit for the different purposes. This assignment may be by an automated process or human curation and ensures the data resource will appear in the search results of related data catalog queries. diff --git a/site/docs/features/discovery-and-stewardship/overview.md b/site/docs/features/discovery-and-stewardship/overview.md index 1e23d32f56..958202344a 100644 --- a/site/docs/features/discovery-and-stewardship/overview.md +++ b/site/docs/features/discovery-and-stewardship/overview.md @@ -3,7 +3,7 @@ # Metadata discovery and stewardship -Metadata discovery is an automated process that extracts metadata about a [digital resource](/concepts/resource). This metadata may be: +Metadata discovery is an automated process that extracts metadata about a [digital resource](/concepts/digital-resource). This metadata may be: * embedded within the asset (for example a digital photograph has embedded metadata), or * managed by the platform that is hosting the asset (for example, a relational database platform maintains schema information about the data store in its databases), or diff --git a/site/docs/features/index.md b/site/docs/features/index.md index 297b01cd3e..31b33033e6 100644 --- a/site/docs/features/index.md +++ b/site/docs/features/index.md @@ -9,12 +9,12 @@ The Egeria features describe the value-add features that Egeria adds to its abil - [Cohort Operation](/features/cohort-operation/overview) - How does an open metadata repository cohort work. - [Data Quality](/features/data-quality/overview) - manage the quality of data for specific purposes. - [Discovery and Stewardship](/features/discovery-and-stewardship/overview) - automated metadata discovery and stewardship of results. -- [Duplicate Management](/features/duplicate-management/overview) - linking metadata elements that represent the same [resource](/concepts/resource) so that these duplicates are automatically merged and do not bloat metadata query results. +- [Duplicate Management](/features/duplicate-management/overview) - linking metadata elements that represent the same [digital resource](/concepts/digital-resource) so that these duplicates are automatically merged and do not bloat metadata query results. - [Effectivity Dating](/features/effectivity-dates/overview) - adding an optional start and end date to metadata elements to limit *when* they can be returned on a metadata query. - [External Identifiers](/features/external-identifiers/overview) - attaching the identifiers that metadata elements are known as in external tools and platforms to make it easier to match metadata from each system when synchronizing metadata. - [External References](/features/external-references/overview) - enriching metadata elements with links to related external material. - [Governance Zones](/features/governance-zoning/overview) - grouping [assets](/concepts/asset) that have similar uses and/or governance requirements into governance zones. The assets in a zone can be queried and managed as a group. -- [Incident Reporting](/features/incident-reporting/overview) - reporting and managing the actions associated with a detected incident or issue relating to a metadata element or associated [resource](/concepts/resource). +- [Incident Reporting](/features/incident-reporting/overview) - reporting and managing the actions associated with a detected incident or issue relating to a metadata element or associated [digital-resource](/concepts/digital-resource). - [Integrated Cataloguing](/features/integrated-cataloguing/overview) - using automation to automatically synchronize metadata between Egeria and external tools and platforms. - [Lineage Management](/features/lineage-management/overview) - Tracing the origin and uses of resources in the organization. - [Metadata Archiving](/features/metadata-archiving/overview) - capturing and storing metadata into archives for backups, to share standard definitions between organizations or independently deployed metadata ecosystems. @@ -22,9 +22,9 @@ The Egeria features describe the value-add features that Egeria adds to its abil - [Metadata Security](/features/metadata-security/overview) - ensuring metadata elements are only visible to/editable by the appropriate consumers. - [People, Roles and Organizations](/features/people-roles-organizations/overview) - how to synchronize information about people, what they do and how they are organized with Egeria to support security, collaboration, escalations and delegations. - [Reference Data Management](/features/reference-data-management/overview) - how to synchronize code values and other types of reference data across your systems. -- [Synchronized Access Control](/features/synchronized-access-control/overview) - how to use metadata to maintain security information used to secure access to [digital resources](/concepts/resource). -- [Templated Cataloguing](/features/templated-cataloguing/overview) - using existing metadata elements as templates when cataloguing new [resources](/concepts/resource). -- [User Feedback](/features/user-feedback/overview) - opening up the communication between [resource](/concepts/resource) owners and resource consumers. +- [Synchronized Access Control](/features/synchronized-access-control/overview) - how to use metadata to maintain security information used to secure access to [digital resources](/concepts/digital-resource). +- [Templated Cataloguing](/features/templated-cataloguing/overview) - using existing metadata elements as templates when cataloguing new [digital resources](/concepts/digital-resource). +- [User Feedback](/features/user-feedback/overview) - opening up the communication between [digital resource](/concepts/digital-resource) owners and resource consumers. --8<-- "snippets/abbr.md" diff --git a/site/docs/features/lineage-management/overview.md b/site/docs/features/lineage-management/overview.md index 4c497f1f47..355187ee22 100644 --- a/site/docs/features/lineage-management/overview.md +++ b/site/docs/features/lineage-management/overview.md @@ -59,7 +59,7 @@ The three parts of the lineage architecture are summarized in figure 4. Capturing lineage has both a static and a dynamic aspect to it. -- The *static* aspect involves cataloguing all the [resources](/concepts/resource) that are deployed into your digital landscape. This defines the data sources and processing engines and how they link together. Ideally this cataloguing is done as these resources are deployed, which may then be augmented with [automated cataloguing](/features/inteegrated-cataloguing) of resources and [metadata discovery](/features/discovery-and-stewardship). It is also possible that tools may catalogue resources under the guidance of their users and this metadata is [shared with the open metadata ecosystem](/patterns/metadata-exchange). +- The *static* aspect involves cataloguing all the [digital resources](/concepts/digital-resource) that are deployed into your digital landscape. This defines the data sources and processing engines and how they link together. Ideally this cataloguing is done as these resources are deployed, which may then be augmented with [automated cataloguing](/features/inteegrated-cataloguing) of resources and [metadata discovery](/features/discovery-and-stewardship). It is also possible that tools may catalogue resources under the guidance of their users and this metadata is [shared with the open metadata ecosystem](/patterns/metadata-exchange). - The *dynamic* aspect captures information about the activity that happens day-to-day, such as the running of processes, and its effects. This could include details of the volumes of data discovered and/or processed along with any analysis of its contents. diff --git a/site/docs/features/people-roles-organizations/overview.md b/site/docs/features/people-roles-organizations/overview.md index d1d1251fe5..abe0747bd5 100644 --- a/site/docs/features/people-roles-organizations/overview.md +++ b/site/docs/features/people-roles-organizations/overview.md @@ -120,7 +120,7 @@ In summary, figure 13 show that the other elements linked to the profile creates ## Linking governance and security to roles -Access to [resources](/concepts/resource) is controlled by identifying which user accounts can access which resources. Typically, a *user group* is defined for collections of similar resources. The group contains the list of user accounts that are allowed to access the associated resources. +Access to [digital resources](/concepts/digital-resource) is controlled by identifying which user accounts can access which resources. Typically, a *user group* is defined for collections of similar resources. The group contains the list of user accounts that are allowed to access the associated resources. This information is stored in a User Directory, such as LDAP and used by an *Access Control Manager*. The access control information is organized for efficient lookup of whether a particular user has access to a resource because they are named in the appropriate group. diff --git a/site/docs/frameworks/saf/annotation-intro.md b/site/docs/frameworks/saf/annotation-intro.md index 1dd6d147f5..f080a7779d 100644 --- a/site/docs/frameworks/saf/annotation-intro.md +++ b/site/docs/frameworks/saf/annotation-intro.md @@ -1,7 +1,7 @@ -An *annotation* describes one or more related properties about a [digital resource](/concepts/resource). Some annotations refer to the entire digital resource and others refer to a data field within the digital resource. The annotations that describe a single data field are called *data field annotations*. +An *annotation* describes one or more related properties about a [digital resource](/concepts/digital-resource). Some annotations refer to the entire digital resource and others refer to a data field within the digital resource. The annotations that describe a single data field are called *data field annotations*. ![Structure of survey reports](/guides/developer/open-discovery-services/survey-report-structure.svg) diff --git a/site/docs/frameworks/saf/survey-action-pipeline-intro.md b/site/docs/frameworks/saf/survey-action-pipeline-intro.md index 5c8f9b2cd3..e3fda51fcc 100644 --- a/site/docs/frameworks/saf/survey-action-pipeline-intro.md +++ b/site/docs/frameworks/saf/survey-action-pipeline-intro.md @@ -3,7 +3,7 @@ There is a lot of common functions that are used repeatedly during the discovery process. -An *open discovery pipeline* is a specialized implementation of an [open discovery service](/concepts/open-discovery-service) that runs a set of open discovery services against a single [digital resource](/concepts/resource). The implementation of the open discovery pipeline determines the order that these open discovery services are run. +An *open discovery pipeline* is a specialized implementation of an [open discovery service](/concepts/open-discovery-service) that runs a set of open discovery services against a single [digital resource](/concepts/digital-resource). The implementation of the open discovery pipeline determines the order that these open discovery services are run. ![Open discovery pipeline example](/guides/developer/open-discovery-services/open-discovery-pipeline-example.svg) diff --git a/site/docs/guides/admin/egeria-admin.drawio b/site/docs/guides/admin/egeria-admin.drawio index fd3a0991ef..b7be7159ca 100644 --- a/site/docs/guides/admin/egeria-admin.drawio +++ b/site/docs/guides/admin/egeria-admin.drawio @@ -1,4 +1,4 @@ - + @@ -3176,7 +3176,7 @@ - + @@ -3217,7 +3217,7 @@ - + @@ -3625,78 +3625,75 @@ - + - - + + - + - + - - + + - - + + - - - - + - - + + - - - - - - - - + + - + - - + + - + - + - - + + - + + + + + + + - - + + - - + + - - + + - - + + diff --git a/site/docs/guides/admin/servers/configuration-document-structure-simplified.svg b/site/docs/guides/admin/servers/configuration-document-structure-simplified.svg new file mode 100644 index 0000000000..571ade0652 --- /dev/null +++ b/site/docs/guides/admin/servers/configuration-document-structure-simplified.svg @@ -0,0 +1,4 @@ + + + +
Local Server Id
Local Server Name
Local Server Type
Event Bus Defaults
Access Services
Conformance Suite Services
Engine Host Services
Lineage Warehouse Services
Data Engine Proxy Services
Audit Trail
Default values used in the
configuration services that
send notifications.
Values used by
all types of server.
Configuration to control
the activation of specialized
services that are specific to
particular types of server.
Repository Services
Server Security Connection
Integration Daemon Services
View Services
Basic Server Properties
Values typically
maintained by Egeria
\ No newline at end of file diff --git a/site/docs/guides/admin/servers/index.md b/site/docs/guides/admin/servers/index.md index 2b27982138..b160e5a37e 100644 --- a/site/docs/guides/admin/servers/index.md +++ b/site/docs/guides/admin/servers/index.md @@ -5,27 +5,29 @@ An [OMAG Server](/concepts/omag-server) is a configured set of services and connectors that support the integration of a particular type of technology. This configuration is located in a [configuration document](/concepts/configuration-document) that is stored in the [configuration document store](/concepts/configuration-document-store-connector). -There are [different types of OMAG Server](/concepts/omag-server#types-of-omag-server) each with a specific purpose. Each server is configured separately. They then may call to one another once they are running. +The configuration document is divided into sections. Each section described the configuration of a particular [OMAG Subsystem](/concepts/omag-subsystem). +The configuration document for a specific OMAG Server determines which OMAG subsystems (and hence the types of services) should be activated in the OMAG Server. -The configuration document for the OMAG Server determines which OMAG subsystems (and hence the types of services) should be activated in the OMAG Server. For example: +There are [different types of OMAG Server](/concepts/omag-server#types-of-omag-server) each with a specific purpose. They then may call to one another once they are running. The server types define the combination of subsystems that need to be active to perform a particular role in the open metadata ecosystem. This means, the configuration document for each type of server, will have different sections filled out. -- Basic descriptive properties of the server that are used in logging and events originating from the server. -- The type of local repository to use. -- Which services should be started. -- Which cohorts to connect to. +![Configuration Document Sections](configuration-document-structure-simplified.svg) -Many of the configuration values are [connections](/concepts/connection) to allow the server to create the connectors to the resources it needs. +Many of the configuration values are [connections](/concepts/connection) to allow the server to create the [connectors](/concepts/connectors) to the [digital resources](/concepts/digital-resource) it needs. These connectors enable Egeria to run in different deployment environments and to connect to different third party technologies. ![Connector types supported by the OMAG Servers](omag-server-connector-types.svg) -## Retrieving the configuration +## Retrieving the configuration document + +It is possible to retrieve whole configuration document for a server either as a single structure, or by section. This first command retrieves the whole configuration document. + +--8<-- "snippets/admin/calls/get-stored-configuration.md" + +This next command retrieves the basic server properties. + +--8<-- "snippets/admin/calls/get-basic-server-properties.md" -!!! get "GET - retrieve the configuration document for a specific OMAG Server" - ``` - {{platformURLRoot}}/open-metadata/admin-services/users/{{adminUserId}}/servers/{{serverName}}/configuration - ``` !!! get "GET - retrieve the origin of the server" It is also possible to query the origin of the server supporting the open metadata services. @@ -35,30 +37,5 @@ These connectors enable Egeria to run in different deployment environments and t {{platformURLRoot}}/open-metadata/platform-services/users/{{adminUserId}}/servers/{{serverName}}/server-platform-origin ``` -## Migrating configuration documents - -As Egeria evolves, the content of the configuration document expands. Many of the changes are pure additions and are therefore backward compatible. - -!!! attention "OMAG Server Platform fails to load configuration document" - From time to time the structure of the configuration document needs to change. When this happens, the OMAG Server Platform is not able to load the configuration document and a message similar to this is returned: - - ```json - { - "class": "VoidResponse", - "relatedHTTPCode": 400, - "exceptionClassName": "org.odpi.openmetadata.adminservices.ffdc.exception.OMAGInvalidParameterException", - "exceptionErrorMessage": "OMAG-ADMIN-400-022 The configuration document for OMAG Server cocoMDS1 is at version V1.0 which is not compatible with this OMAG Server Platform which supports versions [V2.0]", - "exceptionSystemAction": "The system is unable to configure the local server because it can not read the configuration document.", - "exceptionUserAction": "Migrate the configuration document to a compatible version (or delete and recreate it). See https://egeria.odpi.org/open-metadata-implementation/admin-services/docs/user/migrating-configuration-documents.html" - } - ``` - -### Migrating a configuration document from V1.0 to V2.0 - -The `additionalProperties` property name changed to `configurationProperties`. To migrate the configuration document, make a global change from `additionalProperties` to `configurationProperties` throughout the configuration document. - -### Release 2.x+ of Egeria - -Release 2.0 encrypts the configuration document by default. This includes automatically detecting and encrypting any clear-text (unencrypted) configuration document that may already exist. No user action is required for this migration, the encryption will be handled automatically when the clear-text configuration document is first opened by the platform in these releases. --8<-- "snippets/abbr.md" diff --git a/site/docs/guides/admin/servers/omag-server-connector-types.svg b/site/docs/guides/admin/servers/omag-server-connector-types.svg index fdbec41f4f..9fe04b8e7c 100644 --- a/site/docs/guides/admin/servers/omag-server-connector-types.svg +++ b/site/docs/guides/admin/servers/omag-server-connector-types.svg @@ -1,4 +1,4 @@ - + -
OMAG Server
OMAG Server
Audit Log
Audit Log
Repository
Repository
Event Mapper
Event Mapper
Open Metadata
Archive
Open Metadata...
Event Bus
Topic
Event Bus...
Server Security
Connector
Server Security...
Cohort Registry
Cohort Registry
Integration
Connectors
Integration...
Integration
Connectors
Integration...
Integration
Connectors
Integration...
Governance
Action Services
Governance...
Discovery
Services
Discovery...
All OMAG Servers
All OMAG Servers
Engine
Host
Engine...
Metadata Server
Metadata Server
Cohort Member
Cohort Member
Integration
Daemons
Integration...
Text is not SVG - cannot display
\ No newline at end of file +
OMAG Server
Audit Log
Destination
Repository
Event Mapper
Open Metadata
Archive
Open Metadata
Topic
Server Metadata Security
Cohort Registry
Integration
Connector
Governance
Service
All OMAG Servers
Engine Host
Metadata
Access Store
Cohort Members
Integration
Daemon
Repository
Proxy
\ No newline at end of file diff --git a/site/docs/guides/developer/developer-choices.md b/site/docs/guides/developer/developer-choices.md index 17f7770ff0..614fc97919 100644 --- a/site/docs/guides/developer/developer-choices.md +++ b/site/docs/guides/developer/developer-choices.md @@ -12,7 +12,7 @@ The numbers on the diagram refer to these notes: 2. Many of Egeria's *Java clients* provide the mechanism to register a listener with a [topic](/concepts/basic-concepts/#topic) that an Egeria service is publishing notifications to. This removes all requirements for the consuming Java application to interact with the [event bus](/concepts/event-bus) technology. -3. Some of Egeria's *Java clients* also support the creation of [digital resource connectors](/concepts/digital-resource-connector) that can access the content of [digital resources](/concepts/resource) along with the [metadata about the digital resource](/concepts/asset). +3. Some of Egeria's *Java clients* also support the creation of [digital resource connectors](/concepts/digital-resource-connector) that can access the content of [digital resources](/concepts/digital-resource) along with the [metadata about the digital resource](/concepts/asset). 4. For applications that are not written in Java, it is possible to call Egeria directly through its *REST APIs*, and access Egeria's notifications by connecting directly to the topics on the *event bus*. diff --git a/site/docs/guides/developer/open-discovery-services/discovery-annotation-intro.md b/site/docs/guides/developer/open-discovery-services/discovery-annotation-intro.md index b72ab888e0..38e06f82ee 100644 --- a/site/docs/guides/developer/open-discovery-services/discovery-annotation-intro.md +++ b/site/docs/guides/developer/open-discovery-services/discovery-annotation-intro.md @@ -1,7 +1,7 @@ -A *discovery annotation* describes one or more related properties about a [digital resource](/concepts/resource). Some annotations refer to the entire digital resource and others refer to a data field within the digital resource. The annotations that describe a single data field are called *data field annotations*. +A *discovery annotation* describes one or more related properties about a [digital resource](/concepts/digital-resource). Some annotations refer to the entire digital resource and others refer to a data field within the digital resource. The annotations that describe a single data field are called *data field annotations*. ![Structure of discovery analysis reports](/guides/developer/open-discovery-services/discovery-analysis-report-structure.svg) diff --git a/site/docs/guides/developer/open-discovery-services/discovery-pipeline-intro.md b/site/docs/guides/developer/open-discovery-services/discovery-pipeline-intro.md index 5c8f9b2cd3..e3fda51fcc 100644 --- a/site/docs/guides/developer/open-discovery-services/discovery-pipeline-intro.md +++ b/site/docs/guides/developer/open-discovery-services/discovery-pipeline-intro.md @@ -3,7 +3,7 @@ There is a lot of common functions that are used repeatedly during the discovery process. -An *open discovery pipeline* is a specialized implementation of an [open discovery service](/concepts/open-discovery-service) that runs a set of open discovery services against a single [digital resource](/concepts/resource). The implementation of the open discovery pipeline determines the order that these open discovery services are run. +An *open discovery pipeline* is a specialized implementation of an [open discovery service](/concepts/open-discovery-service) that runs a set of open discovery services against a single [digital resource](/concepts/digital-resource). The implementation of the open discovery pipeline determines the order that these open discovery services are run. ![Open discovery pipeline example](/guides/developer/open-discovery-services/open-discovery-pipeline-example.svg) diff --git a/site/docs/parameters/for-lineage.md b/site/docs/parameters/for-lineage.md index 33517237e1..f20df93323 100644 --- a/site/docs/parameters/for-lineage.md +++ b/site/docs/parameters/for-lineage.md @@ -1,7 +1,7 @@ -The `forLineage` flag is set by callers that are working with lineage. Most callers will set this value to `false`. It is used when retrieving elements to determine whether to return elements with the [*Memento*](/concepts/memento) classification. The Memento classification indicates that the corresponding [digital resource](/concepts/resource) has been removed, and the metadata element has only been retained to support the linkage in a lineage graph. +The `forLineage` flag is set by callers that are working with lineage. Most callers will set this value to `false`. It is used when retrieving elements to determine whether to return elements with the [*Memento*](/concepts/memento) classification. The Memento classification indicates that the corresponding [digital resource](/concepts/digital-resource) has been removed, and the metadata element has only been retained to support the linkage in a lineage graph. When `forLineage=false` elements with the Memento classification are not returned; when `forLineage=true` they are returned. diff --git a/site/docs/patterns/metadata-manager/categories-of-metadata.md b/site/docs/patterns/metadata-manager/categories-of-metadata.md index 5b3dfbd78f..347e69f424 100644 --- a/site/docs/patterns/metadata-manager/categories-of-metadata.md +++ b/site/docs/patterns/metadata-manager/categories-of-metadata.md @@ -11,7 +11,7 @@ The categories of metadata listed below help you organize your metadata needs ar ??? info "Technical metadata" ### Technical metadata - The most commonly collected metadata is *technical metadata* that describes the way something is implemented. For example, technical metadata for common [digital resources](/concepts/resource) includes: + The most commonly collected metadata is *technical metadata* that describes the way something is implemented. For example, technical metadata for common [digital resources](/concepts/digital-resource) includes: * The databases and their database schema (table and column definitions) configured in a database server. * APIs and their interface specification implemented by applications and other software services to request actions and query data. diff --git a/site/docs/patterns/metadata-manager/overview.md b/site/docs/patterns/metadata-manager/overview.md index ef4abb196b..41fafc0169 100644 --- a/site/docs/patterns/metadata-manager/overview.md +++ b/site/docs/patterns/metadata-manager/overview.md @@ -57,7 +57,7 @@ This is built on an [extensible type system](/types) that allows further informa ![Basic asset properties](basic-asset-properties.svg) - Each instance of a [resource](/concepts/resource), no matter what its physical type, is represented by a [type of asset](/concepts/asset) in the catalog. + Each instance of a [digital resource](/concepts/digital-resource), no matter what its physical type, is represented by a [type of asset](/concepts/asset) in the catalog. Every asset contains the following properties: diff --git a/site/docs/practices/common-data-definitions/semantic-to-implementation.md b/site/docs/practices/common-data-definitions/semantic-to-implementation.md index ecb75941fd..0acd893d02 100644 --- a/site/docs/practices/common-data-definitions/semantic-to-implementation.md +++ b/site/docs/practices/common-data-definitions/semantic-to-implementation.md @@ -78,7 +78,7 @@ ??? info "Schemas and assets" - An [asset](/concepts/asset) describes a valuable [resource](/concepts/resource) (typically digital). Such resources include databases, data files, documents, APIs, data feeds, and applications. A digital resource can be dependent on other digital resource to fulfill their implementation. This relationship is also captured in open metadata with relationships such as [DataContentForDataSet](/types/2/0210-Data-Stores). These relationships help to highlight inconsistencies in the assets' linkage to the subject area's materials, which may be due to errors in either the metadata or the implementation/deployment/use of the associated digital resources. + An [asset](/concepts/asset) describes a valuable [digital resource](/concepts/digital-resource). Such resources include databases, data files, documents, APIs, data feeds, and applications. A digital resource can be dependent on other digital resource to fulfill their implementation. This relationship is also captured in open metadata with relationships such as [DataContentForDataSet](/types/2/0210-Data-Stores). These relationships help to highlight inconsistencies in the assets' linkage to the subject area's materials, which may be due to errors in either the metadata or the implementation/deployment/use of the associated digital resources. ![Figure 5](/practices/common-data-definitions/semantic-to-implementation-assets-and-schemas-dependencies.svg) > Figure 5: Dependencies between digital resources are reflected in open metadata by relationships between assets diff --git a/site/docs/practices/roles/overview.md b/site/docs/practices/roles/overview.md index 7384ac2def..e28f94105a 100644 --- a/site/docs/practices/roles/overview.md +++ b/site/docs/practices/roles/overview.md @@ -176,7 +176,7 @@ Roles involved in the day-to-day use of an organization's resources: ![Icon](asset-owner-role.png) - A person who is accountable for the proper use and protection of a [Resource](/concepts/resource). This includes the maintenance of the resource's [Asset](/concepts/asset). + A person who is accountable for the proper use and protection of a [Digital Resource](/concepts/digital-resource). This includes the maintenance of the resource's [Asset](/concepts/asset). Most employees in an organization will be an owner of at least one resource. The size and importance of the resource in question will determine the level of seniority of the individual that is the asset owner. diff --git a/site/docs/services/omas/asset-consumer/overview.md b/site/docs/services/omas/asset-consumer/overview.md index e9f32bf8b4..5757bbc577 100644 --- a/site/docs/services/omas/asset-consumer/overview.md +++ b/site/docs/services/omas/asset-consumer/overview.md @@ -17,7 +17,7 @@ ## Overview The Asset Consumer OMAS provides services to an individual who wants to work -with [digital resources](/concepts/resource) such as: +with [digital resources](/concepts/digital-resource) such as: * data stores, data sets and data feeds * reports @@ -43,7 +43,7 @@ The connectors returned by the Asset Consumer OMAS are [Open Connector Framework ## User Guide -The Asset Consumer OMAS is designed for use by an application that is accessing data sources and services through [connectors](/concepts/connector). These data sources and services are called [digital resources](/concepts/resource). Digital resources are represented in open metadata as [Assets](/concepts/asset), hence the name of this OMAS is **Asset Consumer**. +The Asset Consumer OMAS is designed for use by an application that is accessing data sources and services through [connectors](/concepts/connector). These data sources and services are called [digital resources](/concepts/digital-resource). Digital resources are represented in open metadata as [Assets](/concepts/asset), hence the name of this OMAS is **Asset Consumer**. Typically, the first action to take is to [create the connector](#creating-a-connector-for-application-use) to get [access to the asset content and its properties](#working-with-connectors). Connectors are created from [Connection](/concepts/connection) objects. Connection objects can be created by the calling application, or stored in one of the open metadata repositories that are accessible to the Asset Consumer OMAS. diff --git a/site/docs/services/omas/asset-consumer/working-with-connectors.md b/site/docs/services/omas/asset-consumer/working-with-connectors.md index ea935efd04..d4f788e0e2 100644 --- a/site/docs/services/omas/asset-consumer/working-with-connectors.md +++ b/site/docs/services/omas/asset-consumer/working-with-connectors.md @@ -3,7 +3,7 @@ ### Working with connectors -An **open connector** is a Java client to a [digital resource](/concepts/resource) that implements the **Connector** interface defined in the [Open Connector Framework (OCF)](/frameworks/ocf/overview). It has 2 parts to its interface: +An **open connector** is a Java client to a [digital resource](/concepts/digital-resource) that implements the **Connector** interface defined in the [Open Connector Framework (OCF)](/frameworks/ocf/overview). It has 2 parts to its interface: - The specialized interface to work with the specific contents of the resource. For example, if the connector was for data stored in a relational database, this interface would probably follow the [Java Database Connectivity (JDBC)](https://en.wikipedia.org/wiki/Java_Database_Connectivity) specification. The documentation for this interface is found with the specific connector. diff --git a/site/docs/services/omes/asset-analysis/overview.md b/site/docs/services/omes/asset-analysis/overview.md index 2c521a90dd..41869ac121 100644 --- a/site/docs/services/omes/asset-analysis/overview.md +++ b/site/docs/services/omes/asset-analysis/overview.md @@ -18,7 +18,7 @@ The Asset Analysis OMES provides support for [open discovery engines](/concepts/ An open discovery engine hosts [automated metadata discovery](/features/discovery-and-stewardship/overview). -The Asset Analysis OMES is capable of hosting one or more [open discovery engines](/concepts/open-discovery-engine) and supports a REST API to request that an open discovery engine runs an [open discovery service](/guides/developer/open-discovery-services/overview) to analyse a [digital resource](/concepts/resource). The results of this analysis is a [discovery analysis report](/concepts/discovery-analysis-report) that is attached to the resource's [asset](/concepts/asset). +The Asset Analysis OMES is capable of hosting one or more [open discovery engines](/concepts/open-discovery-engine) and supports a REST API to request that an open discovery engine runs an [open discovery service](/guides/developer/open-discovery-services/overview) to analyse a [digital resource](/concepts/digital-resource). The results of this analysis is a [discovery analysis report](/concepts/discovery-analysis-report) that is attached to the resource's [asset](/concepts/asset). The REST API also supports a request to a discovery engine to run a specific open discovery service against each asset it has access to. diff --git a/site/docs/types/0/0045-Servers-and-Assets.md b/site/docs/types/0/0045-Servers-and-Assets.md index cb424b3b0a..48892aae1f 100644 --- a/site/docs/types/0/0045-Servers-and-Assets.md +++ b/site/docs/types/0/0045-Servers-and-Assets.md @@ -3,7 +3,7 @@ # 0045 Servers and Assets -Many data catalogs capture information about data stores, data sets, APIs and topics. These [digital resources](/concepts/resource) provide access to data and reusable function which is why they are of interest. These resources run on IT infrastructure. +Many data catalogs capture information about data stores, data sets, APIs and topics. These [digital resources](/concepts/digital-resource) provide access to data and reusable function which is why they are of interest. These resources run on IT infrastructure. ![UML](0045-Servers-and-Assets.svg) diff --git a/site/docs/types/2/0210-Data-Stores.md b/site/docs/types/2/0210-Data-Stores.md index a73605f129..1cc2132fb4 100644 --- a/site/docs/types/2/0210-Data-Stores.md +++ b/site/docs/types/2/0210-Data-Stores.md @@ -9,11 +9,11 @@ Both [*DataSets*](/types/0/0010-Base-Model#dataset) and [*DataStores*](#datastor ## DataStore entity -The *DataStore* entity describes a physical [digital resource](/concepts/resource) that supplies data. The *deployedImplementationType* attribute describes the class of technology that is used in its implementation. Values for the *deployedImplementationType* attribute can be managed for consistency in a [*deployed implementation type*](/concepts/deployed-implementation-type) valid value set. +The *DataStore* entity describes a physical [digital resource](/concepts/digital-resource) that supplies data. The *deployedImplementationType* attribute describes the class of technology that is used in its implementation. Values for the *deployedImplementationType* attribute can be managed for consistency in a [*deployed implementation type*](/concepts/deployed-implementation-type) valid value set. ## DataContentForDataSet relationship -The *DataContentForDataSet* relationship defines how data is supplied to a [DataSet](/types/0/0010-Base-Model) from a particular [digital resources](/concepts/resource). The DataSet entity includes a property called *formula*. This describes the logic that is used to populate the data set. The formula can include placeholders. These placeholders are defined by the *queryId* properties in the linked DataContentForDataSet relationships. The associated *query* property describes how the data from the linked dataContent resource is selected. +The *DataContentForDataSet* relationship defines how data is supplied to a [DataSet](/types/0/0010-Base-Model) from a particular [digital resources](/concepts/digital-resource). The DataSet entity includes a property called *formula*. This describes the logic that is used to populate the data set. The formula can include placeholders. These placeholders are defined by the *queryId* properties in the linked DataContentForDataSet relationships. The associated *query* property describes how the data from the linked dataContent resource is selected. ## DataStoreEncoding classification @@ -21,7 +21,7 @@ The *DataStoreEncoding* classification provides the ability to store details of ## DataScope classification -The *DataScope* classification identifies the scope of the data stored in the [resource(s)](/concepts/resource) represented by the entity it is attached to. This classification can be attached to any [*Referenceable*](/types/0/0010-Base-Model), but it is typically associated with assets such as *DataStores* and *DataSets*. The attributes of this classification identify the scope of the data in space and time. +The *DataScope* classification identifies the scope of the data stored in the [digital-resource(s)](/concepts/digital-resource) represented by the entity it is attached to. This classification can be attached to any [*Referenceable*](/types/0/0010-Base-Model), but it is typically associated with assets such as *DataStores* and *DataSets*. The attributes of this classification identify the scope of the data in space and time. * *minLongitude* - if the data is bound by an area, this is the longitude for bottom-left corner of the bounding box (BBOX) for the area covered by the data. * *minLatitude* - if the data is bound by an area, this is the latitude for the bottom-left corner of the bounding box (BBOX) for the area covered by the data. diff --git a/site/docs/types/4/0461-Governance-Engines.md b/site/docs/types/4/0461-Governance-Engines.md index 6bd792bfa7..874c82f8af 100644 --- a/site/docs/types/4/0461-Governance-Engines.md +++ b/site/docs/types/4/0461-Governance-Engines.md @@ -17,7 +17,7 @@ Open metadata recognizes three types of governance engine: * *OpenSurveyEngine* - * *EventActionEngine* - event action engines and services support the automated management of [context events](/types/4/0475-Context-Events) and their associated [actions](/types/1/0137-Actions). Note - this type of engine is still in development. * *RepositoryGovernanceEngine* - [Repository governance engines and services](/concepts/repository-governance-engine) support the maintenance of repository level concerns, such as monitoring audit logs and maintaining [open metadata archives](/concepts/open-metadata-archive) that are defined in the [Open Metadata Repository Services (OMRS)](/services/omrs). -* *[OpenDiscoveryEngine](/types/6/0601-Open-Discovery-Engine)* - [Discovery engines and services](/concepts/open-discovery-engine) support the analysis of [digital resources](/concepts/resource). The results of this analysis are stored in a [discovery analysis report](/types/6/0605-Open-Discovery-Analysis-Reports) chained off of the corresponding [Asset](/types/0/0010-Base-Model#asset) metadata element. The interfaces for discovery are found in the [Open Discovery Framework (ODF)](/frameworks/odf/overview). The types for the open discovery engines are shown on model . +* *[OpenDiscoveryEngine](/types/6/0601-Open-Discovery-Engine)* - [Discovery engines and services](/concepts/open-discovery-engine) support the analysis of [digital resources](/concepts/digital-resource). The results of this analysis are stored in a [discovery analysis report](/types/6/0605-Open-Discovery-Analysis-Reports) chained off of the corresponding [Asset](/types/0/0010-Base-Model#asset) metadata element. The interfaces for discovery are found in the [Open Discovery Framework (ODF)](/frameworks/odf/overview). The types for the open discovery engines are shown on model . ## SupportedGovernanceService relationship diff --git a/site/docs/types/5/0540-Data-Classes.md b/site/docs/types/5/0540-Data-Classes.md index 4c50296597..1e91dec8cb 100644 --- a/site/docs/types/5/0540-Data-Classes.md +++ b/site/docs/types/5/0540-Data-Classes.md @@ -9,7 +9,7 @@ Data classes describe logical data types that can be used to classify data value ## DataClass -The *DataClass* entity provides the specification of a [logical data type](/concepts/data-class). This goes beyond the [*SchemaType*](/types/5/0501-Schema-Elements) used to store the data value and includes a specification of the values that are found in this logical type. For example, a credit card number is typically stored as a string. However, it has a well-defined pattern of four groups of four digits. The data class allows the capture of the specification of a credit card number type that can be used by discovery engines to narrow down the expected data values within a [digital resource](/concepts/resource). +The *DataClass* entity provides the specification of a [logical data type](/concepts/data-class). This goes beyond the [*SchemaType*](/types/5/0501-Schema-Elements) used to store the data value and includes a specification of the values that are found in this logical type. For example, a credit card number is typically stored as a string. However, it has a well-defined pattern of four groups of four digits. The data class allows the capture of the specification of a credit card number type that can be used by discovery engines to narrow down the expected data values within a [digital resource](/concepts/digital-resource). ## DataClassHierarchy diff --git a/site/docs/types/7/0710-Digital-Service.md b/site/docs/types/7/0710-Digital-Service.md index 40e1f1ff15..f927f66b15 100644 --- a/site/docs/types/7/0710-Digital-Service.md +++ b/site/docs/types/7/0710-Digital-Service.md @@ -14,7 +14,7 @@ The *DigitalService* entity provides a root element for a digital capability tha Digital services are typically owned and consumed by business capabilities. These relationships are described in [model 0715](/types/7/0715-Digital-Service-Ownership). -Digital services may be implemented by many [digital resources](/concepts/resource) such as APIs, data sets, and software components. This can be represented directly by using the [ImplementedBy](/types/7/0737-Solution-Implementation) relationship to link the *DigitalService* entity to a digital resource's [Asset](/types/0/0010-Base-Model) entity. Alternatively, the architecture of a digital service can be described in a [solution blueprint](/types/7/0740-Solution-Blueprints) made up of [solution components](/types/7/0730-Solution-Components). The solution components have [SolutionPorts](/types/7/0735-Solution-Ports-and-Wires) that describe the inputs and outputs of the solution components. *SolutionLinkingWire* relationships show how they are linked together. The solution components can then be linked to the implementing digital resources' Asset entities via the *ImplementedBy* relationship. +Digital services may be implemented by many [digital resources](/concepts/digital-resource) such as APIs, data sets, and software components. This can be represented directly by using the [ImplementedBy](/types/7/0737-Solution-Implementation) relationship to link the *DigitalService* entity to a digital resource's [Asset](/types/0/0010-Base-Model) entity. Alternatively, the architecture of a digital service can be described in a [solution blueprint](/types/7/0740-Solution-Blueprints) made up of [solution components](/types/7/0730-Solution-Components). The solution components have [SolutionPorts](/types/7/0735-Solution-Ports-and-Wires) that describe the inputs and outputs of the solution components. *SolutionLinkingWire* relationships show how they are linked together. The solution components can then be linked to the implementing digital resources' Asset entities via the *ImplementedBy* relationship. ## DigitalServiceDependency diff --git a/site/mkdocs.yml b/site/mkdocs.yml index 8b20fe4575..cea68a5e77 100644 --- a/site/mkdocs.yml +++ b/site/mkdocs.yml @@ -717,6 +717,7 @@ nav: - Data Domain: concepts/subject-area.md - Data Engine Proxy: concepts/data-engine-proxy.md - Deployed Implementation Type: concepts/deployed-implementation-type.md + - Digital Resource: concepts/digital-resource.md - Digital Resource Connector: concepts/digital-resource-connector.md - Discovery Analysis Report: concepts/discovery-analysis-report.md - Endpoint: concepts/endpoint.md diff --git a/site/snippets/admin/calls/get-basic-server-properties.md b/site/snippets/admin/calls/get-basic-server-properties.md new file mode 100644 index 0000000000..a39b71f8ff --- /dev/null +++ b/site/snippets/admin/calls/get-basic-server-properties.md @@ -0,0 +1,38 @@ + + + +??? get "getBasicServerProperties" + Return the basic server properties in a single request. + + === "Java" + + ```java + String adminUserId = "garygeeke"; + String serverName = "active-metadata-server" + String adminPlatformURLRoot = "https://127.0.0.1:9443"; + + OMAGServerConfigurationClient configurationClient = new OMAGServerConfigurationClient(adminUserId, + serverName, + adminPlatformURLRoot); + + BasicServerProperties basicServerProperties = configurationClient.getBasicServerProperties(); + ``` + + === "Python" + + ```python + admin_user_id="garygeeke" + server_name="active-metadata-store" + admin_platform_url_root="https://127.0.0.1:9443" + + config_client=CoreServerConfig(server_name, + admin_platform_url_root, + admin_user_id) + + config_client.get_basic_server_properties() + ``` + + === "REST" + ``` + GET {{platformURLRoot}}/open-metadata/admin-services/users/{{adminUserId}}/servers/{{serverName}}/server-properties + ``` diff --git a/site/snippets/admin/calls/get-stored-configuration.md b/site/snippets/admin/calls/get-stored-configuration.md new file mode 100644 index 0000000000..fb3efcfd21 --- /dev/null +++ b/site/snippets/admin/calls/get-stored-configuration.md @@ -0,0 +1,39 @@ + + + + +??? get "getStoredConfiguration" + Return the stored configuration document for the server. + + === "Java" + + ```java + String adminUserId = "garygeeke"; + String serverName = "active-metadata-server" + String adminPlatformURLRoot = "https://127.0.0.1:9443"; + + OMAGServerConfigurationClient configurationClient = new ConfigurationManagementClient(adminUserId, + adminPlatformURLRoot); + + OMAGServerConfig omagServerConfig = configurationClient.getOMAGServerConfig(serverName); + ``` + + === "Python" + + ```python + admin_user_id="garygeeke" + server_name="active-metadata-store" + admin_platform_url_root="https://127.0.0.1:9443" + + config_client=CoreServerConfig(server_name, + admin_platform_url_root, + admin_user_id) + + config_client.get_stored_configuration() + ``` + + === "REST" + + ``` + GET {{platformURLRoot}}/open-metadata/admin-services/users/{{adminUserId}}/servers/{{serverName}}/configuration + ``` \ No newline at end of file diff --git a/site/snippets/admin/configuring-omag-server-basic-properties.md b/site/snippets/admin/configuring-omag-server-basic-properties.md index 268c8b1677..0de5b4aa90 100644 --- a/site/snippets/admin/configuring-omag-server-basic-properties.md +++ b/site/snippets/admin/configuring-omag-server-basic-properties.md @@ -44,7 +44,7 @@ Alternatively, you can set these properties one at a time. POST {{platformURLRoot}}/open-metadata/admin-services/users/{{adminUserId}}/servers/{{serverName}}/server-user-password?password="{{serverUserPassword}}" ``` -!!! post "setMaxPageSize" +??? post "setMaxPageSize" The maximum page size value sets an upper limit on the number of results that a caller can request on any paging REST API to this server. Setting maximum page size helps to prevent a denial of service attack that uses very large requests to overwhelm the server. A value of `0` means no limit, and leaves the server open to such attacks. ``` POST {{platformURLRoot}}/open-metadata/admin-services/users/{{adminUserId}}/servers/{{serverName}}/max-page-size?limit={{maxPageSize}} @@ -52,5 +52,8 @@ Alternatively, you can set these properties one at a time. ### Retrieving a server's basic properties +It is possible to retrieve the basic server properties to verify the values they are set to. + +--8<-- "snippets/admin/calls/get-basic-server-properties.md"