Named links and other ideas borrowed from triple stores

I’ve been following the Hook developments for a while but only recently started using it. I’m not sure I have an immediate use for this but I had to think about how partly what Hook provides is a graph database or a triplestore in a sense (along with the scripts to construct and resolve hook urls). Borrowing from those concepts, in a triplestore you have a collection of subjectpredicateobject. The predicate in this could just be link, like it’s now, but could be interesting to allow these to be customised. So for example you have a document that was from a more conceptual phase, since then it has been superceded by a more mature draft, but you still want to know where did the ideas come from. I guess if you are linking more, it can be interesting to qualify those links, what is the nature of the link?

This leads me to another thought, I think files in the finder now have the concept of versions. Are you linking to a specific version of this file or are they considered the same file? What about other versioning systems? Can you have a link to a file in a specific branch of a git repository? Anyway, a version could potentially be modelled as a named link, but that might be taking it too far.

Welcome to the Hook Productivity Forum, @jorisjh . Thanks for these questions/thoughts.

This idea comes up every now and then, including when three of us here were on a related project at Simon Fraser University many moons ago, and during private beta of Hook, and since then (even on the forum during public beta, I think).

One use for this would be when the user wants to rename a link that is part of a particular hook without updating the entire bookmark.

First some background. When a user hooks two items together, hook creates a bookmark for each one and bidirectionally links them. The bookmarks are not yet exposed in the interface, but you can get them through the API (introduced recently , updated in Hook 1.6, and to be enhanced , probably this supper).

We will soon introduce the ability to rename a bookmark. This will affect all the hooks for an item. (Related: Hook autoupdates hook://file bookmarks when user renames them on the file system, and will soon auto-update non-file bookmarks when possible, again assuming the user has not renamed the bookmark.)

To get back to your triples, a user might want to rename the hook linking A to B without renaming the hook linking C to B. That is something that we’ve been considering since the early days of Hook.

Also, for graphing networks of items linked by Hook, for which there is some demand, an advanced feature would be renaming labels.

Hook does not do anything special to deal with versions. Hook’s file-tracking behavior is similar to aliases / bookmarks, but there’s extra logic , eg to deal with cases where aliases break but the filename remains the same.

I’ve written this quickly, hopefully not too many typos.