Asked @Lydia_Pintscher about the data on usage of this feature:

taken from https://grafana.wikimedia.org/d/000000290/wikidata-query-service-ui?orgId=1

@Lydia_Pintscher I also looked at the numbers (based on the Grafana dashboard) over the past 6 months and polestar is the 4th most used (< 10% out of the total views). Not insignificant like @Anton.Kokh said but also not significant. Happy to see if there has been a bunch of feedback from the community asking to fix this? That might help decide whether it makes sense to put effort into this now.

If that isn't the case, I don't think it makes much sense to invest time into fixing this now. Maybe we just remove it, especially if it's brokwn? If there is a user need going forward, we can then come back and find a solution.

Is there anything blocking us from doing this later? (Might not be possible? Might be a lot more work?)

But it’s not broken at the moment, is it? If I understand correctly, it would break if we took down query.wikidata.org (but AFAIK that’s not even the plan – it will just become equivalent to query-main.wikidata.org), but it seems to work fine so far. And in that case I don’t see why we should expect any feedback from community members asking to fix it – I expect that whoever uses it (I don’t know who, but apparently plenty of people according to the tracking) is happy with it and might not even realize that it’ll be affected by the graph split.

@Lucas_Werkmeister_WMDE I thought the functionality hadn't been working as expected on query.wikidata.org either and then I would have hoped for some feedback on that from the users but not the case but thanks

@Tarrow

the graph-builder functionality will be impacted already on https://query-main.wikidata.org/ and https://query-scholarly.wikidata.org/ since graph builder is making requests to the different dataset on query.wikidata.org

According to Lucas' comment above, it shouldn't be an issue on query-main.wikidata.org?

So, that leaves the questions -

1. Are we sure the scholarly articles sub graph will have this issue?
2. Handing back to WBC - do y'all think you want to ship the query service without this as one of the visualisation options and wait for feedback from your community or would you prefer to have this functionality?

I can then prioritize it accordingly

@Lucas_Werkmeister_WMDE @Ifrahkhanyaree_WMDE
The results that the graph builder on query-main and query-scholarly will actually come from query. So it wouldn't break, but the results won't be the same as you see in the table view, which I guess is not the expected behavior?

But it’s not broken at the moment, is it? If I understand correctly

I think it is right? Take for example this query:

select * WHERE {
  {
    SELECT *{
      ?a wdt:P31 wd:Q18918145 # a journal article
    } LIMIT 5
  }
  UNION
  {
    SELECT * {
      ?a wdt:P31 wd:Q146 # a cat
    } LIMIT 5
   }
   SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],mul,en". }
}

it only gets 5 results on main or scholarly but 10 results appear in the graph builder on both of those UIs

do y'all think you want to ship the query service without this as one of the visualisation options and wait for feedback from your community

Probably Anton's call but I imagine we want to maintain compatibility with Wikidata; if they sunset graph builder we'd probably also sunset; if they want to ship one for main and one for scholarly then we'd also ship it functional

Thought a small image might also help show the issue. See 10 results where 5 are claimed:

Based on the conversation and the data, we're going to look into https://phabricator.wikimedia.org/T291928 and see how much effort it is. Seems not too much work, so we might pull it into next sprint, but will update here tomorrow.

Did you see T291928#10323465 suggesting that voyager probably isn't a long term solution?

In any case I wonder if this ticket is or isn't resolved already? I'm not sure who's responsibility it is to make the decision about the outcome of "Investigate value of retaining graph builder functionality" but am I understanding correctly that from your perspective @Ifrahkhanyaree_WMDE you're thinking "yes! keep it!"?

If so we could probably close this as resolved and then open more tickets about the technical stuff to do if we've decided we want to keep it?

I did, we pulled that ticket ( T291928) in and see what we can do.

By closing "this" ticket you mean the one we're chatting on? I would say yes since the investigation has been concluded and we're working on the solution.

I think WPP engineers can make any other relevant tech tickets based on what they decide to do with T291928. You're of course free to make any tickets that might be relevant for Cloud