My comments below are just part of the discussion, not meant to express a preference.
Hook relies on more information than the path (e.g., if docs move their path is different, and Hook links normally remain valid–i.e., are pretty robust).
Some people like tags, but most people do not use them. (Well , most people don’t use Hook either yet). This is not to say that Hook will not accommodate tags within the next year.
Hook currently has a simple ontology. One can jump into using Hook without defining tags or projects. One can quickly create links with very little cognitive inertia (little strategizing about the shape of a network).
Hook can serve many ways of working. I have found that URL centric link navigation meets most of my needs, but I am not the only user of Hook.
The concept of mesh and project has come up in the past on the forum (and behind the scenes over the years I’ve explored them, but thought we should release Hook initially without them since there’s already so much functionality that covers so many use cases). One way of using Hook is to identify a core project document (or other resource) as hub.
But even then my hypothesis is that most of the time for most users most links will actually define small disjoint networks, often pairs of documents. (I say hypothesis because I’m inviting colleagues to use Hook for research on personal information management [with consenting users of course, which would call for a research-variant of Hook, like we did w SomnoTest, a research version of mySleepButton ].
Empirical research on users would probably reveal many ways of using Hook – more than I had imagined. And when we introduce other forms of meta-information ( ) , I’m sure that many users will available themselves of them. The automation of Hook itself might also enable developers to build tools to support other meta-information.
Sorry this is not meant to be circumlocution. I can’t put a time line on the other forms of meta information, and meanwhile we’re listening to suggestions.