From b3a334801a6fb5215bb630a4bd52ce7f552ca842 Mon Sep 17 00:00:00 2001 From: johcarter Date: Thu, 9 Jan 2025 10:55:17 +0000 Subject: [PATCH 1/3] Fix hardcoded image path --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 23108e0b..962083fa 100644 --- a/README.md +++ b/README.md @@ -89,7 +89,7 @@ https://oasislmf.org/open-data-standards The diagram below highlights the proposed, long-term structure of ODS and all the key components. Interoperability is vital to ensure efficient interaction across multiple databases, systems and external exposure management and data storage facilities. - + ## Open Exposure Data (OED) From fae457f63a8acf50998a9894336364b3d1fe972f Mon Sep 17 00:00:00 2001 From: johcarter Date: Thu, 9 Jan 2025 10:57:22 +0000 Subject: [PATCH 2/3] Remove #213 from 4.0.0 following reversion --- Changelog.rst | 1 - 1 file changed, 1 deletion(-) diff --git a/Changelog.rst b/Changelog.rst index ce4459d3..50fe2689 100644 --- a/Changelog.rst +++ b/Changelog.rst @@ -19,7 +19,6 @@ ODS Changelog * (https://github.com/OasisLMF/ODS_OpenExposureData/issues/224) - [Property] Many fields incorrectly described as percentage instead of proportion * (https://github.com/OasisLMF/ODS_OpenExposureData/issues/216) - [Property] Clarify value in BITIV as annualised in field description * (https://github.com/OasisLMF/ODS_OpenExposureData/issues/225) - [Property] Valid values for BaseFloodElevation are incorrect -* (https://github.com/OasisLMF/ODS_OpenExposureData/issues/213) - [Property] MRI new codes * (https://github.com/OasisLMF/ODS_OpenExposureData/issues/173) - [Cyber] Do not include implicit business logic in the schema design * (https://github.com/OasisLMF/ODS_OpenExposureData/issues/182) - [Cyber, Liability] Integration of Cyber and Liability into Property specification * (https://github.com/OasisLMF/ODS_OpenExposureData/issues/188) - [Cyber, Liability] Financial coverages and field name revisions From ba7045094ca5c3964e07e6af9b990694295e6f99 Mon Sep 17 00:00:00 2001 From: johcarter Date: Thu, 9 Jan 2025 11:09:14 +0000 Subject: [PATCH 3/3] Tidy up and update old links --- README.md | 17 +++++------------ 1 file changed, 5 insertions(+), 12 deletions(-) diff --git a/README.md b/README.md index 962083fa..d8f6503d 100644 --- a/README.md +++ b/README.md @@ -125,17 +125,13 @@ https://github.com/OasisLMF/OpenDataTransform **Liability** -The focus for OED has primarily been on property exposure data since its inception but has now expanded to support other lines of business. The v1 liability data schema was released in April 2022 and has now been incorporated into the main OED schema. See the 'liability field status' field here https://github.com/OasisLMF/ODS_OpenExposureData/blob/release/4.0.0/OpenExposureData/OEDInputFields.csv. - +The focus for OED has primarily been on property exposure data since its inception but has now expanded to support other lines of business. The v1 liability data schema was released in April 2022 and has now been incorporated into the main OED schema. See the 'Liability field status' field in [here](OpenExposureData/OEDInputFields.csv).   **Cyber** -The v1 cyber schema was released in February 2023 but has now been incorporated into the main OED schema. See the 'cyber field status' field here: -https://github.com/OasisLMF/ODS_OpenExposureData/blob/release/4.0.0/OpenExposureData/OEDInputFields.csv. - - +The v1 cyber schema was released in February 2023 but has now been incorporated into the main OED schema. See the 'Cyber field status' field in [here](OpenExposureData/OEDInputFields.csv).   @@ -147,10 +143,8 @@ ORD follows the same versioning format as OED (following the SemVer convention a https://github.com/OasisLMF/ODS_OpenResultsData -   - ## Governance ODS is governed by a steering committee that meets periodically and is chaired by Oasis LMF. @@ -176,8 +170,7 @@ All releases will follow the SemVer convention (https://semver.org/), so given a * Adding ‘mandatory’ fields to the schema. * Moving fields between input files (i.e., from ‘ReinsScope’ to ‘ReinsInfo’ files) * Removing occupancy or construction codes. - * Changing or removing any other codes currently used in the OED schema. I.e., any codes contained in the tabs of the *OpenExposureData_Spec.xlsx* -(https://github.com/OasisLMF/ODS_OpenExposureData/blob/develop/OpenExposureData/Docs/OpenExposureData_Spec.xlsx) + * Changing or removing any other codes currently used in the OED schema. I.e., any codes contained in the *OpenExposureData_Spec.xlsx* * Reducing the ‘valid value range’. * Changing the ‘allow blanks’ field. * Changing the ‘default’ values. @@ -188,7 +181,7 @@ All releases will follow the SemVer convention (https://semver.org/), so given a * Adding new fields to the OED schema. * Adding new occupancy or construction codes. - * Adding new codes in the tabs of the *OpenExposureData_Spec.xlsx* (https://github.com/OasisLMF/ODS_OpenExposureData/blob/develop/OpenExposureData/Docs/OpenExposureData_Spec.xlsx) + * Adding new codes in the *OpenExposureData_Spec.xlsx* * Increasing ‘valid value range’. **PATCH** updates are for making backwards compatible bug fixes e.g. correcting a typo in a column label. @@ -199,7 +192,7 @@ All new work will be done in **feature** branches, following the [GitFlow model] ### Versioning and Back Compatibility -The 'versioning' tab in the OED spec (https://github.com/OasisLMF/ODS_OpenExposureData/tree/OED_v3.1_testing/OpenExposureData/Docs) contains the mapping and back compatibility of occupancy and construction codes from previous versions of OED. For example, if a user codes exposure data using an occupancy or construction code from OED v3, but the model implementation they are running is only using the OED v2 schema, then that code will be mapped back to an appropriate code in OED v2 so any validation processes will still work. +The 'versioning' table in the OED spec (OpenExposureData/Versioning.csv) contains the mapping and back compatibility of occupancy and construction codes from previous versions of OED. For example, if a user codes exposure data using an occupancy or construction code from OED v3, but the model implementation they are running is only using the OED v2 schema, then that code will be mapped back to an appropriate code in OED v2 so any validation processes will still work.