I can filter / define a backlink Property

(User Story, Investigate , Priority: Medium, Test Status: No automated tests yet , Reported By Justin du Coeur, )
Data Model
Summary: This is still a bit vague, but the core notion is that we probably want to provide better support for cross-links, such as the "Stories" property here.
One thing I'm finding as I use Querki more is that, despite the system preferring uni-directional links (for data-consistency reasons), you often wind up with bi-directional ones, especially when there are many-to-many relationships. A fine example is the relationship between the Stories and Features Properties in this Space -- Stories is a Feature's list of the upcoming Issues, in order, and Features is an Issue's set of the Features it applies to. These don't strictly have to match (and often won't do so exactly), but more often than not should do so, and it would be Very Nice to provide some support for that.
Very similar example: the relationship between Game and External Page in the Period Games Space. Again, it's technically a many-to-many relationship, but most of the time an External Page will pertain to exactly one Game, just as an Issue tends to have one Feature.
There are two UI enhancements that seems useful, which may be the same concept under the hood:
  • When A has a List/Set of B, it should be able to filter the candidates to only be Bs that have Property P set to A.
For example, the Stories property of Feature has become unwieldy: the list of candidates is enormous. And I only actually want to list Issues that have this Feature in their Features list.
  • When A is creating a B, it should be able to pre-set Property P as a back-link.
In the same example, when I am editing a Feature, and adding to the Stories list, the newly-created item should have its Features set pre-populated with this.
It is not clear whether I should be clever and general here, allowing arbitrary QL expressions for the filter. It may be 95% as effective, and far easier to use, to simply add an "Backlink" meta-Property, providing the inverse Property. That is, Stories would have Features as its Backlink. This wouldn't be hard-enforced, but it is a hint to the UI that we expect all candidate Stories to have a Feature that points back here. When we are showing candidate values for Stories, we only list items whose Features match; when creating a Story (that is, creating an Issue from a Feature's Story list), we pre-populate this backlink into the Feature field.
I like this idea: it provides good Querkish flexibility (the lack of guarantees is entirely appropriate and in keeping with Querki style), while addressing the UI-level maintenance problems.