Documentation issueshttps://community.opengroup.org/osdu/documentation/-/issues2020-03-23T18:38:17Zhttps://community.opengroup.org/osdu/documentation/-/issues/57Search convenience queries2020-03-23T18:38:17ZFerris ArgyleSearch convenience queries## Status
- [ ] Proposed
- [ ] Trialing
- [ ] Under review
- [X] Approved
- [ ] Retired
## Context & Scope
R1 implemented map aggregate, zoom, and other convenience methods to address INT and SSIO requests.
## Decision
Deprecate plat...## Status
- [ ] Proposed
- [ ] Trialing
- [ ] Under review
- [X] Approved
- [ ] Retired
## Context & Scope
R1 implemented map aggregate, zoom, and other convenience methods to address INT and SSIO requests.
## Decision
Deprecate platform support for consumer-specific convenience methods other than map aggregates, eg. zoom
## Rationale
## Consequences
## When to revisit
---
# Tradeoff Analysis - Input to decision
## Alternatives and implications
* Deprecate platform support for consumer-specific convenience methods other than map aggregates, eg. zoom
* Retain these
## Decision criteria and tradeoffs
* Over-fitting against INT and SSIO
* Client convenience vs. service burden
## Decision timeline
R3Release 3ethiraj krishnamanaiduethiraj krishnamanaiduhttps://community.opengroup.org/osdu/documentation/-/issues/54Ingestion reference data validation2020-03-23T18:35:20ZFerris ArgyleIngestion reference data validation## Status
- [ ] Proposed
- [ ] Trialing
- [x] Under review
- [ ] Approved
- [ ] Retired
### History
This was approved in [January OSDU R2 Decisions review](https://docs.google.com/presentation/d/13muxPb8gnZ8P_mwFvGu0K3rWaqoHD5z5uNx2-Lb...## Status
- [ ] Proposed
- [ ] Trialing
- [x] Under review
- [ ] Approved
- [ ] Retired
### History
This was approved in [January OSDU R2 Decisions review](https://docs.google.com/presentation/d/13muxPb8gnZ8P_mwFvGu0K3rWaqoHD5z5uNx2-LbmN2k/edit#slide=id.g7628e71997_0_358) and has since been revisited.
## Context & Scope
* Currently we are only validating manifests, not reference targets; we should validate that reference data to which an SRN refers exists, as well as other relationships
* How should this work? OpenDES model is to load and cleanup after based on batch scan checks; OSDU philosophy tends to be to only allow valid data in; if they’re doing as part of pre-processing, then capture as long-term backlog issue.
## Decision
## Rationale
## Consequences
Implementation Tasks:
* Gap Fit: Understand how validation is done today (ex, is it well formed JSON)
* Create an ADO story
* Dependency on Schema Service developed by SLB Pune Team
* Ethiraj to update on readiness
* Cross-Cloud Testing and Validation
## When to revisit
---
# Tradeoff Analysis - Input to decision
## Alternatives and implications
Propose postponing post-R2; this implies that bad data can be loaded.
## Decision criteria and tradeoffs
## Decision timelineRelease 2JoeJoehttps://community.opengroup.org/osdu/documentation/-/issues/52Delivery access tokens2020-03-23T16:08:19ZFerris ArgyleDelivery access tokens## Status
- [ ] Proposed
- [ ] Trialing
- [ ] Under review
- [X] Approved
- [ ] Retired
## Context & Scope
Retaining OpenDES functionality in R2 and expanding it
Supporting R1 Behavior
WPC types (Kinds) as it relates to real content ar...## Status
- [ ] Proposed
- [ ] Trialing
- [ ] Under review
- [X] Approved
- [ ] Retired
## Context & Scope
Retaining OpenDES functionality in R2 and expanding it
Supporting R1 Behavior
WPC types (Kinds) as it relates to real content are identified by A LIST OF SRNs
## Decision
Return a read access token, and then use the cloud blob API and then use a convenient function API that rides on top of the data platform and carries through the logic
* 1 SRN -- 1 signed URL
* X SRNs --- X signed URLs with transformation
* Metadata - if you want to get to the S3 path, in the future we would get an S3 prefix to the VDS object
## Rationale
## Consequences
Implementation Tasks:
* Gap fit on this use case
* Test according to the definition of done (Write test cases)
* Add a user story to the project ADO
## When to revisit
---
# Tradeoff Analysis - Input to decision
## Alternatives and implications
## Decision criteria and tradeoffs
## Decision timelineRelease 2JoeJoehttps://community.opengroup.org/osdu/documentation/-/issues/50Entitlements Filter2020-03-23T16:09:14ZFerris ArgyleEntitlements Filter## Status
- [ ] Proposed
- [ ] Trialing
- [ ] Under review
- [X] Approved
- [ ] Retired
## Context & Scope
* Retaining OpenDES functionality in R2 and expanding it
* Supporting R1 Behavior
## Decision
Add Entitlements Filter
* Use ...## Status
- [ ] Proposed
- [ ] Trialing
- [ ] Under review
- [X] Approved
- [ ] Retired
## Context & Scope
* Retaining OpenDES functionality in R2 and expanding it
* Supporting R1 Behavior
## Decision
Add Entitlements Filter
* Use a default group or a default company policy to grant wider access to meta-data
* Meta-data to be carved out to go into an explicit group and that group would have general access
* Meta-data includes: group-type, master data, reference data
## Rationale
Supports ISVs currently implemented functionality without undue burden on service.
## Consequences
None.
Implementation Tasks:
* Discussion Jan 9 in OSDU Authorization and Entitlements workshop.
## When to revisit
---
# Tradeoff Analysis - Input to decision
## Alternatives and implications
## Decision criteria and tradeoffs
## Decision timelineRelease 2ethiraj krishnamanaiduethiraj krishnamanaiduhttps://community.opengroup.org/osdu/documentation/-/issues/48OpenDES record/resource id and group semantics (SRN)2020-03-23T18:36:07ZFerris ArgyleOpenDES record/resource id and group semantics (SRN)## Status
- [ ] Proposed
- [ ] Trialing
- [ ] Under review
- [X] Approved
- [ ] Retired
## Context & Scope
SRN has record/resource id and group encapsulated, whereas GUID doesn’t - Alan
## Decision
Add semantics to OpenDES for record...## Status
- [ ] Proposed
- [ ] Trialing
- [ ] Under review
- [X] Approved
- [ ] Retired
## Context & Scope
SRN has record/resource id and group encapsulated, whereas GUID doesn’t - Alan
## Decision
Add semantics to OpenDES for record/resource id and group
## Rationale
## Consequences
Implementation Tasks:
* Review and formalize the gap fit
* Add a service to map the SRN to the identifier to the ingestion workflow in OpenDES
* Add test
* Define new services to fill gap
## When to revisit
---
# Tradeoff Analysis - Input to decision
## Alternatives and implications
## Decision criteria and tradeoffs
## Decision timelineRelease 2ethiraj krishnamanaiduethiraj krishnamanaiduhttps://community.opengroup.org/osdu/documentation/-/issues/47Search - Return entities name2020-03-23T18:39:10ZFerris ArgyleSearch - Return entities name## Status
- [ ] Proposed
- [ ] Trialing
- [ ] Under review
- [X] Approved
- [ ] Retired
## Context & Scope
## Decision
Retain name for all return entities: these are there in R1, but weren’t in R0 in some cases
## Rationale
Support...## Status
- [ ] Proposed
- [ ] Trialing
- [ ] Under review
- [X] Approved
- [ ] Retired
## Context & Scope
## Decision
Retain name for all return entities: these are there in R1, but weren’t in R0 in some cases
## Rationale
Supports ISVs currently implemented functionality.
## Consequences
None.
Implementation Tasks:
* Test according to the definition of done (Write test cases)
* Add a user story to the project ADO
## When to revisit
---
# Tradeoff Analysis - Input to decision
## Alternatives and implications
## Decision criteria and tradeoffs
## Decision timelineRelease 2ethiraj krishnamanaiduethiraj krishnamanaiduhttps://community.opengroup.org/osdu/documentation/-/issues/30Domain Centric approach2020-06-24T20:24:36ZStephen Whitley (Invited Expert)Domain Centric approach# Domain Centric approach
Adopt a Domain Centric Approach first, followed by Data Centric Approach
## Status
- [ ] Proposed
- [ ] Trialing
- [ ] Under review
- [X] Approved
- [ ] Retired
## Context
We need a consistent way to model ...# Domain Centric approach
Adopt a Domain Centric Approach first, followed by Data Centric Approach
## Status
- [ ] Proposed
- [ ] Trialing
- [ ] Under review
- [X] Approved
- [ ] Retired
## Context
We need a consistent way to model a business problem to build a set to services, instead of building a set of services and looking for a business problem. We need a consistent way to promote and communicate what is the primary driver.
## Decision
Use a domain first approach, model the systems around the domain and business value they provide. This natural way will eventually prove more beneficial when compared with approaching the problem them as pure data or technology partitions. In essence, discover the data architecture, data flow, partitions and separate concerns as the result of this modelling exercise instead of the other way around. We realize that this may appear to be counter intuitive to the "separate data from applications", however it is encouraged that we take a domain centric view first and then go about drawing boundaries and layers. That would provide for the natural way the business is organized and functions, and more importantly it will also help us realize what is the core domain (that a product line wishes to stay ahead and be a differentiator and has a direct value to the business) and hence where one must focus the resources.
## Rationale
1. The realization of the business value or otherwise, defines the outcome of the exercise (success or failure). And hence the success or failure can easily be measured and measured fast
1. The approach provides for a high cohesion and loose coupling. As the domains gets divided into smaller units (sub-domains and realms), the concerns are better grouped and encapsulated from each other. In the resulting system of sub-components, each concerns reflects as "services" . This naturally leads to the microservices style development and can be developed at scale.
## Consequences
1. Not everyone has the detailed view of all sub-domains - it is possible to get locked and promote one's own service as the "Core" service. It is fundamental to identify the Core service per domain/sub-domain early on. And this Core service should reflect the goal/objective that is set for the domain/problem-space.
1. The "data" might get locked and may not be discoverable outside the sub-domain. This is true and is indeed by design - strongly advocated by the Sam Newman in his [book](https://samnewman.io/books/building_microservices/). The fear of lock-in can be mitigated by publishing all the relevant data for future analytics and discovery.