Add opportunity to link data product with data contract

[kyyberi]

Is your feature request related to a problem? Please describe. Data products are shared and technical data contract is used in the process. That data contract is generated separately. Having a link to data contract in the data product would make sense.

Describe the solution you'd like Possibly attribute to root level?

Additional context Data Contracts

1. https://datacontract.com/
2. https://github.com/bitol-io/open-data-contract-standard

[kyyberi]

Suggested implementation approach below. This is optional object directly under the product details object.

• Id (string) is needed to sepate contracts and to be able to find it in data contract management system
• type (enum) defines standard used in describing the contract. Options are DCS and ODCS.
• version defines the version of the standard used in describing the data contract
• url is optional link to the data contract in data contract management system.

model

product:
  details:
     contract:
        id:      # ID, like uuid in the system managing contracts  
        type:  # this can be ODCS or DCS 
        version:   # defines the version of the above type standard used
        url:   # link to contract management system. Should be full link and go directly to agreement details. 

example

product:
  details:
     contract:
       id: "2343e34543567e767i23" 
       type: "ODCS" 
       version: "2.2"
       url: "https://demo.datamesh-manager.com/demo834016807886/dataproducts/9bd53b1b-b51e-41a8-a757-4d33b4cde460"

[kyyberi]

Questions:

1. is it possible that there is need to define multiple data contracts here?
2. should it be possible to include the data contract as YAML inline object under the contract object?

[kyyberi]

Questions:

1. is it possible that there is need to define multiple data contracts here?

2. should it be possible to include the data contract as YAML inline object under the contract object?

To enable the inline YAML object mentioned in the question 2, one possibility is to add spec element under which the data contract code can be added as is. That would follow the pattern we have used in data quality and SLA.

product:
  details:
     contract:
        id:      # ID, like uuid in the system managing contracts  
        type:  # this can be ODCS or DCS 
        version:   # defines the version of the above type standard used
        spec: # under this the YAML formatted contract can be added directly. 

[kyyberi]

I am not sure should this be under the product details directly, or should we start a new root level object for data contract. We have data licensing object to which this might be related to later, but that is legally oriented while data contract is technically oriented.

[kyyberi]

Also our model has data access object separately. That is often part of the data contract.

[kyyberi]

One clearly tempting option is to rename existing data access to data contract and align the models if needed. ODPS data access object resembles in spirit and intention to some extent the data contract purpose

[kyyberi]

Another approach is to keep the data product and contract totally separated. Then only a link and/or reference to contract exists in the data product description. This is was also the initial idea.

[kyyberi]

After some considerations I propose that we add the data contract to the document level as optional element with URL linking and spec (inline) options. Some customers want to use this to define access and other details.

product:
     contract:
        id:      # ID, like uuid in the system managing contracts  
        type:  # this can be ODCS or DCS 
        version:   # defines the version of the above type standard used
        URL: # link to contract manager service
        spec: # under this the YAML formatted contract can be added directly. 

Other customers who do not want to use Data Contract can use Data Access object to define access related details. Refinement of Data Access object is already another item in the backlog #10

[kyyberi]

Details in the PR

[kyyberi]

Supported in TSC