Well, that was relatively painless. Only sticking point was that a tree link must have a URI that describes it. I have a table of URIs, editable by the user, and the ids 1-1000 are reserved by the boatree app itself as being system constants. So I populate the URI table with two newly-minted URIs:
I will need to author LinkTypeTerm.rdf, which will describe what the URIs mean (ie: that they are used internally by the boatree system for links that are not visible to the user).
I need to build the “workspace” system. In particular, I have managed to tangle it up with the notion of a user-built tree. I think that I can get away with one “workspace” per user … but then again, maybe not. My previous idea was that a workspace would be built on top of a tree – the “tree that you were working on”. This being the case, we will need multiple per user. The concept was that when a workspace was checked in, only those nodes that were part of the tree that the workspace was built on would be versioned. And it might be nice for users to have different workspaces if they have different areas in the same tree – one for their current edits to Vombatus, another for their work on Cestoda.
A key consideration is the ability for a user to work on something they don’t have access to modify.
We need to make it possible for a user to pull out the AFD Cestoda taxon, fiddle with it, check it in, and then for the curators of AFD to take that checked-in tree and accept it. This is the main motivation behind “user trees”.
Another oopsie is that I have said that the tree roots are invisible to allow for classifications to have multiple unrelated root nodes. A fine example is (again) AFD, which has “root” nodes ANIMALIA and PROTISTA at present. (see http://biodiversity.org.au/afd/mainchecklist). The problem is that you need to be able to edit these roots for precisely this reason.
I think I may need to go back to the notion of a root node and a “tag” node. Tags are nodes that connect to other nodes with fixed or tracking links – they are never versioned. Their purpose is to provide a persistent id for structures that may change over time.
The effect of this is that the “tree” object … damn. I don’t want to hook it to the root node because If I do, I’ll have to write special cases to keep them up-to-date when versioning occurs, and the entire point of the system is to not no have to do that. It’s just that now I have about five node types:
- regular nodes
- ’nuff said
- tag nodes
- Have a persistent, well-known URI
- Are never versioned, are never have versioning sublinks
- Are never used as a subnode, except perhaps as the subnode of another tag
- When used as the subnode of another tag, the subnodes are understood to form an unordered set
- Do I really need this?
- tree roots
- Just like a tag, except that every regular node “belongs to” one tree, and every workspace is a workspace “of” some particular tree
- as per above
It’s 1:30AM. Probably time for a break of a few hours.