Export Data in a Clear and Acessible Format

Hookmark Feature Requests
1

I know that Hookmark has the ability to export data, as stressed here: Topic

But, the output is a plist with a lot of noise. For sure I can parse it with regex, but this will give me some headache. Also, I inspect the .sqlite file of Hookmark and saw that parsing it to recover my data will, again, cause me even more headaches.

My main use of HookMark is deeplink in PDF's, especially when I need some easy access to quotes.

The problem is: I am also afraid if Hookmark goes away and I will just have thousands of dead-links. For me, it is a critical dealbreaker any kind of software that lock my data or do not offer a clear export formar (xml, json, csv, whatever).

The point is that the export of Hookmark is not clear, since has a lot of noise, as I pointed out. What I really want is an clear format export, for example, if it is a xml, I would expect something like this:

<root>
    <link>
       <id>Id Link</id>
       <file>File Name</file>
       <path>Path</path>
       <extra>Extra for item type</extra>
       <connections>Other hooked files by Id</connections>
    </link>
</root>

In the PDF case, as hook put the page, x and y attribute, I would like the extra field to have something like this:

<extra>
  <p>Page</p>
  <x>X position</x>
  <y>Y position</x>
</extra>

For the other hooked files, I would expect the tag connections to have something like this:

<connections>
  <id>Id Link</id>
  <id>Id Link</id>
  <id>Id Link</id>
  [...]
</connections>

With a clear and clear way to parse my data, I would reconsider using the app again, but the actual export format is very far from it. I really do not want to have headaches recovering tons of data. Also, the xml is just an example, for sure this could be done in json, csv or whenever (but I personally believe that xml is the best war to store complex data).

So, I would like to ask if the developers have any plans to improve this part. The app functionally is awesome, do not take me wrong. But more precious than this is the time that we spend in the app making data, that is why I am really concerned about this topic.

2

To be fair, the canonical source of hooks is, unless I’m completely wrong, the SQLite database. SQLite has been around for a long time and is unlikely to disappear off the face of the Internet. What would help no end, however, is that it’s use by Hookmark be fully documented, both internally and externally. Some ERDs wouldn’t go amiss either. A little trick here, learnt from hard experience, is put as much as possible into the database itself.

Doing that would open possibilities beyond merely building some views to make the contents less opaque.

1 Like
3

We address the issues here: Hookmark: Interoperability at its finest.

The export format is just designed to be used by Hookmark to reset the database, and as an alternative way to migrate between Macs (though we recommend using Sync for that). And you can use it for backup restore purposes (though Hookmark also maintains a backup of its DB in ~/Library/Application\ Support/com.cogsciapps.hook/). The export file is not really meant to be human readable or used for other purposes than that.

With AppleScript you can get data in and out of Hookmark:

We also have on our product road map to provide a Netscape style export of bookmarks. This is not a complete representation of Hookmark data since Hookmark has information that is unique to it, such as hooks.

We may provide other export formats in the future. But again, with AppleScript one can get the data and do whatever one wants with it.

Again, our policy so far has been to direct users to the AppleScript API for getting the data in and out, allowing CogSci Apps to change the DB schema as needed without inconveniencing customers. Having said that, we will take your request under consideration.

4

I can fully understand the desire to isolate Hook’s data schema from public gaze; as you said encapsulating it behind an API allows it to be changed without issues arising. On the other hand as applications mature, so their database schemata tend to stabilise; its features using data rather than new types of data that get added. I’d hope Hook is in this position.

Letting third parties access Hook data through a set of well documented (read only) views might be a good middle course. It would, for example, allow anyone with a penchant to do so to experiment with graph views or pull all the files related to some project with a graph walk. There are bindings to SQLite in just about every programming language under the sun, whereas AppleScript, although good for what it sets out to do — automation, is by no means the best general purpose language.

As an aside, database views can, of course, be read/ write if you implement INSTEAD OF triggers, but I suspect you’d prefer to maintain encapsulation.

1 Like
5

The point of this request is not because I have any kind of suspicious about Hookmark or I think that the company will disappear tomorrow.

When I deal with digital data, I have a golden rule:

- Nerver, [NERVER] use any kind of tool that lock your data.

That is why I will never user softwares like Thinderbox, Bookends and the like, that have crazy proprietaries formats and is a hell to get our complete data (not few exporting options) from the app.

In this sense, I think that Hookmark is a software that builds (and read) databases. The database of Hookmark is to link all sort of files in our system. So far, again, a wonderful and useful software.

Here comes my concern, because my database will grow following the time I use the app. And more it grows, more important for me. If tomorrow I decide to move back to Linux, for example, I will do not have access to all my relations made by Hookmark and this is a real dealbreaker for me.

The success of Obsidian, for example, is because the app just operate above the data and never lock it, this also helps to build trust between the app and costumers. Again, I use(d) hookmark exactly because it is elegant and well made application and I, myself, do not want the headache to write from scratch a relational database (my custom reference manager and notes scripts are more than enough for my head). For sure, me and any other user, will keep using Hookmark anyway, because we need a tool to build the database and Hookmark is excellent in this aspect.

Apple script is somewhat middle level between the unix philosophy and the lack of automation in the crap Windows. With all its craziness, it is being clearly depreciated by Apple in favor of other automation tools, especially Shortcuts. By the way, “simulating” GUI actions through scripts would never be a good idea, after all :smile:. For sure, would not be a good option for any API.

Not need for all this, I think that the automation provided by Hookmark via the Shortcut apps is very good and interact well with other applications. For sure, for more sophisticated demands, a true API would be required, not the AppleScript.

Again, my requirement is not an API for automation, it is just a simple way to export data that we produce in hookmark in an easy way to serialize it. I think that this will not be a challenge for the developers, since you have full access to the program and just need to parse it in a xml, json or whatever.

I will follow this development, if any progress, I will reconsider hookmark.