We don't have any UI that exposes the ability to relate objects. Also the content repository has a lighter-weight way of relating content objects that competes with acs-relationships - this is purely due to the fact that the CMS/CR was originally written as a standalone application and later grafted to ACS 4.0 without sufficient integration.
I think acs-relationships are the way to go because the CR stuff's limited to cr_items and obviously we want to be able to relate any two objects in the system, particularly people and content.
They're heavier-weight than I'd like as each row's an object.
On the other hand this allows one to use permissions to control access to knowledge links. In general this strikes me as being too fine-grained but I've not had to build a complex system of this sort so I may be wrong.
Along similar lines is the notion of "general ranking", allowing one to define ranking dimensions and to hook ranking to any object in the system. "mirror mirror on the wall, who's the cutest of them all" Why ... none of them, they're all geeks, one star max! Ranking of anything, yep ...
I have the tarball of some very minimalistic steps in that direction taken by someone who'd hoped to have time to complete a general rankings package but ended up landing a large contract to work on a java-based knowledge management system instead.
Anyway ... implementation of the kind of relationships Dirk mentions along with a completed general rankings package would give us a quite a base for doing "knowledge management" type stuff. The content repository also implements the kind of dynamic type extension stuff, complete with help to automate form building and handling neede for something like ShareNet, though we're not quite sure how well it works (Jeff Davis is investigating this as part of his work in implementing a module for dotLRN)
