https://datahubproject.io logo
Join Slack
Powered by
hi guys, did you plan to include listings of inbou...
# ui
f
hi guys, did you plan to include listings of inbound relationships to glossary terms as well (so, something like "Contained by", "Inherited by") ... this would improve user experience when navigating and discovering relationships in glossary. It would be enough to list it in read only fashion. Please see the picture attached. I've seen you have meaningfully improved the Related Entities tab (now including datasets not only linked to a base glossary term but also glossary terms that inherit the base term ) so this functionality would be a missing piece to round up discoverability features of Business Glossary UI. Apologies, if this is already an existing request, i didn't check it up ... currently that page is not available (404)
b
Hey! yes this definitely makes sense and is something we're thinking about. Would you actually mind making a quick feature request for this? I could certainly see others wanting this read only functionality at least as well for incoming relationships
f
Thnx, i will post a feature request!
thank you 1
Hey, i just wanted to mention that i've posted this as a feature request, as agreed. https://feature-requests.datahubproject.io/p/list-inbound-relationships-to-glossary-terms
b
Perfect. Thanks!
f
Hi @bulky-soccer-26729... did you maybe have time to review how hard would be to implement this ? This feature request was kinda long ago (4 months) but it would prove useful for us (and i believe others) in many glossary use cases. It would encourage & boost usability of contains & inherits relationships in business glossary since it would be handy to view them in both directions. I naivly believe you already have it in model and that it's just a matter of surfacing it in UI. I might be wrong though 🙂 Some things we could model in this way would be ... 1. we have a lot of special classification terms (for instance PII.ContactData) and we make every individual term that falls into this category (for instance Employee Mobile Number, Employee Email, Customer Email, Customer Street Address) inherit this special classification term. I would be really nice if a user can navigate to this special classification term, go to Related Terms tab and see all the individual terms that have is-a (inherits) relationship to it by clicking on "Inherited by" 2. A glossary user can have a lot of "specialized" concepts ... for example we have Revenue and other specialized (inherited) terms like Logged Revenue, Invoiced Revenue, Deffered Revenue, ... scattered in different places in glossary tree. "Inherited by" when looking for Related Terms for Revenue would group them together 3. We could model that a compound metric is calculated using other metrics (represented by their own terms) by using "Contains" relationship. If we do that, than we could use "Contained by" in Related Terms to see what compound metrics are depended on (are calculated from) the metric we are looking at These are just some examples where having the ability to look at related terms in both direction would prove useful. Purpose of this thread post is just to gently remind you guys of this idea and maybe have it reconsidered for some future releases. If it is indeed "simple" to implement it feels like a missed opportunity to further enhance already good discoverability features between glossary terms in a simple fashion.
b
hey there! yes that all makes tons of sense and thank you so much for clarifying it. I haven't had a chance yet to dig into exactly how much of a lift it would be, but my hunch is it wouldn't be too too tough (hard to say without digging into it more). However, with limited folks working on the core datahub team and lots of important requests coming in through the community, it's really tough prioritizing exactly what gets worked on. I appreciate you making the feature request above and I see that it's starting to pick up a bit of steam with more upvotes! to be honest I can't guarantee that this will be built in the immediate future, but your feedback is highly appreciated and it's certainly going to come with me in my upcoming prioritization meetings when we're slotting what's on our roadmap! in the meantime I would highly suggest checking out whether you think you or someone on your team would be able to build this as a community contribution 🙂
f
hey, chris, i'm glad you found it useful. I understand all you wrote. not sure our team is equipped to deliver it by themselves, but i'll comment this with them
hey, Chris, just a little update of this topic. i did some investigation what GraphQL query you trigger when the user visits Related Terms tab (by analysing network traffic in Chrome Developer Tools) and found out that you already fetch incoming IsA relationships, as well as outgoing IsA and outgoing HasA relationships in the same GraphQL query - you just don't present it on UI Here are 3 terms in your demo environment i've used to test https://demo.datahubproject.io/glossaryNode/urn:li:glossaryNode:83688c48-1b08-4ce8-833a-bd1a0db3d52b/Contents?is_lineage_mode=false Term 1.1.1. inherits Term 1.1. inherits Term 1 And i've attached graphQL query that gets triggered when you visit Related Terms tab (for Term 1.1.) You can just paste it GraphiQL and see the results
Copy code
# Nenad Dragojlović : this is displaying how you already fetch incoming IsA relationships
# but you just don't show it on UI of Related Terms Tab - qraphQL query is catched from
# Chrome when accesing Related Terms tab.
# It is shown for the Term 1.1. (urn:li:glossaryTerm:a6c0064e-8f76-4a06-aa12-661a43d3bf8f)
# Term 1.1.1 inherits Term 1.1 inherits Term 1
# It would be completely analogous addition for incoming HasA relationship as well

{
  glossaryTerm(urn: "urn:li:glossaryTerm:a6c0064e-8f76-4a06-aa12-661a43d3bf8f") {
    urn
    type
    hierarchicalName
    properties {
        name
        description
    }
    isRelatedTerms:relationships (input: {types: ["IsA"], direction: OUTGOING, start: 0, count: 10}) 
    {
      start
      count
      total
      relationships{
        entity{
          ... on GlossaryTerm{
            urn
            properties {
                name     	
            }
            __typename
          }
         __typename
        }
      __typename
      }
      __typename
    }
    isAChildren:relationships (input: {types: ["IsA"], direction: INCOMING, start: 0, count: 10}) 
    {
      start
      count
      total
      relationships{
        entity{
          ... on GlossaryTerm{
            urn
            properties {
                name     	
            }
            __typename
          }
         __typename
        }
      __typename
      }
      __typename
    }
     hasRelatedTerms:relationships (input: {types: ["HasA"], direction: OUTGOING, start: 0, count: 10}) 
    {
      start
      count
      total
      relationships{
        entity{
          ... on GlossaryTerm{
            urn
            properties {
                name     	
            }
            __typename
          }
         __typename
        }
      __typename
      }
      __typename
    }
  }
}
@bulky-soccer-26729 Hope the above helps. Knowing this and assuming that you still find this addition would make total sense , my question is : should i keep looking for UI developers in my company that could potentially be able to contribute this code addition or is it simple enough/relevant enough and more sensible for you to put it on the list of future small UI improvements. I've already posted a reference to a original feature request that we discuss here (above in a thread). Just reposting it here for convenience https://feature-requests.datahubproject.io/p/list-inbound-relationships-to-glossary-terms
b
thanks Nenad! yeah this all makes sense and helps actualize the scope of how it would be to build this thing (not too bad by the looks of it). let me talk to my team about whether or not we want to go through with this and if so I'll let you know if we think we can squeeze it in as a small UX improvement or if it makes sense for you to find someone to contribute. I will say that we always welcome contributions and something like this would just save us time and energy and could be a good candidate for community contribution 🙂
Open in Slack
PreviousNext
Powered by