https://datahubproject.io logo
Join Slack
Powered by
I have noted that many ownership types have been d...
# advice-metadata-modeling
w
I have noted that many ownership types have been declared as deprecated https://github.com/datahub-project/datahub/blob/master/metadata-models/src/main/pegasus/com/linkedin/common/OwnershipType.pdl However we are actively using some of them: • 
PRODUCER
and `CONSUMER`: to differentiate groups with write/read permission to a given Dataset • `DATAOWNER`: in many cases in our organization the data producer is different from the data owner. So mixing all those types in a single one (
TECHNICAL_OWNER
) does not give us the precision we need. I could provide more details on these use cases if necessary. Also, beyond having a model describing reality with high accuracy, our plan is to drive some access management and some other features based on this ownership type. Eg: provide some preview of the data only to users belonging to a group with the 
CONSUMER
owner role. I think the way to go here is to make ownership types a deployment config. So we can set the allowed ownership types for a given DataHub instance. Alternatively, a pragmatic option could be to set Ownership Type just as a string and left validation to the application level. Is there any other way to set ownership type in the entity model that I missed? Or what are the plans on this?
lookaround 2
👍 3
👍🏻 1
Any feedback here? Cc'ing @little-megabyte-1074 @mammoth-bear-12532
l
@big-carpet-38439 @bulky-soccer-26729 @echoing-airport-49548 do any of you have thoughts on the best approach here?
b
I mean. We want to be able to build opinionated product workflows and make assumptions around a standard set of ownership types going forward
If we make it a free for all, we kinda restrict our ability to do so
The producer / consumer case is interesting.. In what case should a consumer be considered an owner? Basically I'm wondering if ownership is the right concept in the first place to model this relationship
Or if there's a better way to do the access control flow that you want to model, without leveraging this overriden concept of being an "owner"
This above being said, I think it's probably okay to have a "base set" of ownership types, and an additional set which is comprised of custom (providing the name AND description for rendering somewhere) extensions. One way to achieve this is to add a "CUSTOM" OwnershipType enum value, and another freeform string field called "customOwnershipType" that is populated if type === CUSTOM. Then in the UI we can allow you to click an 'Advanced' dropdown to define a custom ownership type. Would something like this suffice?
w
In what case should a consumer be considered an owner?
This is indeed a good point. As mentioned before, in our organization data can be produced by a given team while data is actually owned by some other. So 
DATAOWNER
and 
PRODUCER
are very relevant to us. Somehow, ones owns the data itself (the content) while the other owns the dataset (all metadata such as schema, descriptions, etc). I guess 
CONSUMER
appears here just contrasting 
PRODUCER
. And we use it to model teams with read access.
I think it’s probably okay to have a “base set” of ownership types, and an additional set which is comprised of custom (providing the name AND description for rendering somewhere) extensions.
That would be great and work for us!
This above being said, I think it's probably okay to have a "base set" of ownership types, and an additional set which is comprised of custom (providing the name AND description for rendering somewhere) extensions.
Hi @big-carpet-38439 Long time since we had this conversation. I'm raising the topic again because I'm scared in every release that deprecated ownership types disappear 😱 Is there any way to track this feature request? Note my main concern is not with the feature request but with the risk of introducing a breaking change that would be critical for us.
2 Views
Open in Slack
PreviousNext
Powered by