Previous Entry Share Next Entry
Feature looking for opinions: Backlinks
querki
jducoeur wrote in querki_project
In pondering some workflow annoyances, I just wound up inventing a new feature, tentatively called Backlink -- a way of saying that Properties P and Q are rough inverses of each other. That is, P is a Link/Tag from Model A to Model B, and Q is a Link/Tag from B to A; the Backlink meta-Property would tell the system that it should make some assumptions based on that.

The notion is that this wouldn't be rigidly enforced -- as always, Querki intentially allows your data to be a bit messy -- but would be a hint to the UI, to make these relationships work correctly by default. The actual Story, linked above, gives a couple of examples.

Thoughts? This is very new and ill-formed, but it seems to be a plausible approach to some annoyances I'm finding as my Spaces get bigger and more complex. Comments (either here or in the Story's conversations) would be welcomed...

  • 1
My understanding is if you're going to name the feature Backlink, there is going to be some pre-loaded connotations from existing uses. The most familiar use I have is for a link connecting back to the original source for re-posted material or commentary. (although I could also be misusing the term.)

This can also be a potential mess. =) What you'd want is a way for the links to auto-update if there is a page rename or move on either side. Which is presumably not too hard within a Space, but difficult between Spaces in the same server cloud and nigh impossible between server clouds.

My understanding is if you're going to name the feature Backlink, there is going to be some pre-loaded connotations from existing uses. The most familiar use I have is for a link connecting back to the original source for re-posted material or commentary. (although I could also be misusing the term.)

Hmm -- interesting point. I'm not sure whether it's an overwhelming argument, but you're right that the term is sometimes used that way. I'll need to think about whether that rules it out for this usage.

This can also be a potential mess. =) What you'd want is a way for the links to auto-update if there is a page rename or move on either side. Which is presumably not too hard within a Space, but difficult between Spaces in the same server cloud and nigh impossible between server clouds.

Well, it's explicitly a "soft" link -- more a hint to the UI than something that is rigidly enforced. All of the use cases I've come up with so far are actually many-to-many, so it *can't* be terribly restrictive, and I don't think I'd want to be. That may influence the name decision: possibly I should call a spade a spade, and call it something like "Backlink Hint".

That said, maintaining a Link is trivial: Links are actually OID-based, not Name-based, and OIDs never change. Tags are potentially more problematic (since they *are* Name-based), but this is just a special case of the more general problem of maintaining Tags, which I'll wrestle with eventually.

Links/tags across Spaces are not currently possible, and I'm not at all sure I'm going to *make* them possible: they are a thorny problem at best, and so far I haven't come up with likely use cases.

There are currently no plans for multiple Querki server clouds (which I think of as Federated Querki Instances); I'm mainly focused on building the primary service as a business. I'm open to the idea of federating with open-source instances elsewhere, but it's enough work that I'm not likely to motivate it until somebody pushes hard. (And is willing to help with the development effort enough to make it worth it.) At this point, I'm not even entirely sure what it *means*.

There will be some fairly interesting architectural discussions before that happens. I suspect that, if we open that can of worms, I will encourage us to think in terms of federating via an open protocol, rather than hard-coding the assumptions too much. Don't know whether quite the right protocol exists yet or not...

  • 1
?

Log in

No account? Create an account