"Here are some random notes I wrote down when glancing through the ODPS (which is great btw), might be something to consider:
Visibility - this should likely be more fine grained to be practical (?)
productSeries - id reference might be more sustainable (?)
brandSlogan - maybe should be part of holder rather than product, seems a little out of place?
Pricing - should be tied to interfaces (?)
SLAs - should be tied to interfaces (?), response times etc might differ a lot depending on the interface and/or contract used
Data Quality - should likely include quality rules and associated assurance methods"
Answer by Jussi Niilahti:
"Visibility - this should likely be more fine grained to be practical (?)
True! Private - just the creator. Organisation - visible to all in your organisation. Public - visible to all publicly. <-- These may not be enough.
productSeries - id reference might be more sustainable (?)
True. ODPS is intended to be 'autonomous', so id data alone may not be enough. ODPS should be usable, e.g. without access to the Data Marketplace or querying APIs.
brandSlogan - maybe should be part of holder rather than product, seems a little out of place?
The Data Holder has a 'company-level slogan', so this is intended to be the 'brand slogan' for the data product. It could at least be more clearly stated and instructed.
Pricing - should be tied to interfaces (?)
This is something to consider. The original idea was that if the interface changes, the product changes.
SLAs - should be tied to interfaces (?), response times etc might differ a lot depending on the interface and/or contract used
Same as previous. This is relevant to be considered. SLAs usually have a major impact on the price of a service or product.
Data Quality - should likely include quality rules and associated assurance methods
Absolutely. The current solution is simple, with a breakdown between 6 quality factors (without rules), assurance methods and the possibility of defining the quality standard used. These may not be sufficient in the future."
niilahti
commented
11 months ago
"Here are some random notes I wrote down when glancing through the ODPS (which is great btw), might be something to consider:
Visibility - this should likely be more fine grained to be practical (?) productSeries - id reference might be more sustainable (?) brandSlogan - maybe should be part of holder rather than product, seems a little out of place? Pricing - should be tied to interfaces (?) SLAs - should be tied to interfaces (?), response times etc might differ a lot depending on the interface and/or contract used Data Quality - should likely include quality rules and associated assurance methods"
Answer by Jussi Niilahti:
"Visibility - this should likely be more fine grained to be practical (?) True! Private - just the creator. Organisation - visible to all in your organisation. Public - visible to all publicly. <-- These may not be enough. productSeries - id reference might be more sustainable (?) True. ODPS is intended to be 'autonomous', so id data alone may not be enough. ODPS should be usable, e.g. without access to the Data Marketplace or querying APIs. brandSlogan - maybe should be part of holder rather than product, seems a little out of place? The Data Holder has a 'company-level slogan', so this is intended to be the 'brand slogan' for the data product. It could at least be more clearly stated and instructed. Pricing - should be tied to interfaces (?) This is something to consider. The original idea was that if the interface changes, the product changes. SLAs - should be tied to interfaces (?), response times etc might differ a lot depending on the interface and/or contract used Same as previous. This is relevant to be considered. SLAs usually have a major impact on the price of a service or product. Data Quality - should likely include quality rules and associated assurance methods Absolutely. The current solution is simple, with a breakdown between 6 quality factors (without rules), assurance methods and the possibility of defining the quality standard used. These may not be sufficient in the future."