Base Repository

<H3 CLASS="western" STYLE="page-break-before: always">Base repository with naming scheme.</H3> If the storage mechanism is disregarded for a moment, and we have a set of models with an id. A repository is represented with repos://. In order to add a set of files (which makes a model) to the repository, a directory named with a random UUID must be created, which the set of files are added into there. This directory named with a random UUID could go into the repos:// root, but to a casual user listing the models, it would be a meaningless listing of a string of numbers. These directories could be stored under repos://id/ to group them as model directories with UUID. Example: repos://id/d89ffd26-02e9-4ca9-928d-f6967fe9fe29/ Now, are the model creators want to remember which UUID they stored their models in? It may be quite cumbersome to remember which is what, hence model creators may desire their directories to be named with human readable language. While natural language names are readable, different people may name similar items with the same name, which causes name collision issues. However, if there is only one person doing the naming, s/he could sort out such self collisions rather quickly. One solution is to give all model creators their personal directory (could be either repos://home/ or repos://user/) and let them name items in their natural language. Example: repos://home/john/pendulum_model/ It is possible to tie these two items together via a file linkage mechanism offered the storage system (e.g. symlinks, aliases). There should be some sort of method that shows the relationship between named model versus UUID models (for now, 1:1 to show this naturally named model links to which UUID model and vice versa). Example: repos://home/john/pendulum_model/ == repos://id/d89ffd26-02e9-4ca9-928d-f6967fe9fe29/ Given a repository is not different than an ordinary filesystem without version control (aside from ZFS and other esoteric filesystems), there needs to be implemented somehow (could leverage existing technologies such as CVS or Subversion), and an URI must be exposed. One idea was a global revision identifier that increments by one when a set of updates is checked into the repository (which is an update). There needs to be URIs that points to previous revisions. Example: repos://!rev/10/home/john/pendulum_model/ == repos://!rev/10/id/d89ffd26-02e9-4ca9-928d-f6967fe9fe29/ If a revision did not update this set of files, pointing to that particular revision will return the set of files from the last update before the particular revision. Example: If revision 11 is a commit of a different model, accessing repos://!rev/11/home/john/pendulum_model/ will return the same set of files as repos://!rev/10/home/john/pendulum_model/ assuming revision 10 is the last update to pendulum_model before revision 11. There also exists a publishing mechanism, where a human readable URI can link to a directory of a specific revision. repos://publication/doe_2007_1/ -> repos://!rev/10/home/john/pendulum_model/ The link itself is versioned, which will show where the published link once point to. repos://!rev/11/publication/doe_2007_1/ -> repos://!rev/10/home/john/pendulum_model/ repos://!rev/17/publication/doe_2007_1/ -> repos://!rev/14/home/john/pendulum_model/ repos://publication/doe_2007_1/ -> repos://!rev/14/home/john/pendulum_model/ There also needs to be permission level set, and for now we use standard *nix permission set (read/write, user/group/other). Permission can be set per revision, but only read access is granted as it is not possible to write to data from previous revisions (which are frozen). Write access can only be granted by the owner (or superuser) to a file. Write access enables the check-in of a file. <H3 CLASS="western">Example Workflow</H3> This section is not comprehensive. John creates a model, has either of these URIs as primary (not yet decided on which is primary, it could be either one or both, which all leads to slightly different consequences). repos://home/john/pendulum_model/ == repos://id/d89ffd26-02e9-4ca9-928d-f6967fe9fe29/ He is owner of the model, default permission is read/write access by him only. He could give read access to any/all revision of that model by his choice (this should not bump the revision counter since it's permission metadata). He makes several revisions. repos://!rev/2/home/john/pendulum_model/ repos://!rev/6/home/john/pendulum_model/ repos://!rev/7/home/john/pendulum_model/ repos://!rev/10/home/john/pendulum_model/ John could grant read permission to a specific revision, or for the whole model. John publishes his model, which gives read permission to the reviewers group. He could either publish a specific revision, or the latest version, or any or whole revision history. Generally, publishing a model involves giving a URI to the reviewers, either of a previous revision. An alias URI could be created at John's option. The model was accepted by a peer-reviewed journal, John updates the model's metadata and commits that change, the repository is notified of the publication and a new alias is created at repos://publication/doe_2007_1/ that points to the specific revision John just published his model by. repos://publication/doe_2007_1/ -> repos://!rev/10/home/john/pendulum_model/ OR repos://publication/doe_2007_1/ -> repos://!rev/10/id/d89ffd26-02e9-4ca9-928d-f6967fe9fe29/ This has the advantage of freezing good changes, and so if John made several work-in-progress to fix some minor bugs in the model to the copy in his home directory, it will not affect the published model until he updates the pointer. A history log can be generated from that published link to show how many times and when did John updated the model post-publication. Model approved and published, with metadata updated with the citation information. repos://publication/doe_2007_1/ -> repos://!rev/14/home/john/pendulum_model/ Mary notices issues with the model that was published. She creates a copy of John's published model at repos://publication/doe_2007_1/, which points to repos://!rev/14/home/john/pendulum_model/, in her home directory. Since it's a copy/branch of an original model, she creates a new model, and a new ID is generated, which Mary could associate a name with it in her home directory. Since: repos://publication/doe_2007_1/ -> repos://!rev/14/home/john/pendulum_model/ A copy of repos://!rev/14/home/john/pendulum_model/ is made, results in: repos://home/mary/john_doe_pendulum_model/ == repos://id/5dfb2127-dfcd-4d4a-ac45-9860b7e7af5c/ History logs will reflect the copy to show the origin of repos://home/mary/john_doe_pendulum_model/. Other users could do the same thing if they want to experiment with building a separate branch of that particular model. Mary corrects the model and got John to check it. When John agrees and grants Mary the permission (in the repository, since he owns the publication link), she indicates to the repository that the corrected version of repos://publication/doe_2007_1/ should now point to repos://!rev/24/home/mary/john_doe_pendulum_model/, or repos://!rev/24/id/5dfb2127-dfcd-4d4a-ac45-9860b7e7af5c. John also merges Mary's changes into his own model, and invites Mary to collaborate with him, so write access to repos://home/john/pendulum_model/ (repos://id/d89ffd26-02e9-4ca9-928d-f6967fe9fe29/) was granted by John to her. History of repos://publication/doe_2007_1/ may look like this: <OL>

<LI>repos://!rev/10/home/john/pendulum_model/ <LI>repos://!rev/14/home/john/pendulum_model/



<LI>repos://!rev/24/home/mary/john_doe_pendulum_model/ <LI>repos://!rev/30/home/john/pendulum_model/

</OL> Those actual URIs are listed, which points users to immutable versions of what once was published, latest "stable" version, and optionally they can access repos://home/john/pendulum_model/ or repos://home/mary/john_doe_pendulum_model/ to see the latest revisions either John or Mary made, given read permissions to them are granted. <H3 CLASS="western">Finding relationship between the models</H3> It will need to be done. Implementation details still being discussed. <H3 CLASS="western">Web-site</H3> It could expose just the publication section, an index.html is rendered, or a automatically generated listing of the files of the model could be shown, complete with metadata. This is open to discussion. <H3 CLASS="western">Software Considerations</H3> It is possible to use Subversion to implement the above features, but a wrapper in front of the server will be needed to provide the required permission management and even the naming features. It may be possible to provide enough features for a standard Subversion client to interface with the repository. As for a distributed repository of models, Git may be worth considering.