By far the most difficult task in DataNav Builder is the construction of a large, coherent data archive. This section offers tips on how to go about building one.
Before you even open Builder, spend some time thinking about what data you want to store in your data hub, what views you’ll define, how you might establish a sequence of views that will “drill down” from a top-level view of the hub down to the more nitty-gritty details. While testing and evaluating the lab’s previous incarnation of a “data portal”, we typically constructed a hub to encompass all of the experiments and data collected for a particular published paper, and that is perhaps a good starting point for the new Builder app as well -- e.g., one of the figures in the paper, possibly in a simplified form, would serve as the figure template for one of the hub’s views.
Focus on one navigation view at a time, starting with the top-level "entry-point" view. For each view, decide what its instance configuration will be. This forces you to think about how the individual “data instances” are tagged -- about how the experimental data is logically organized. Design the view’s template figure in Figure Composer (or in the figure editor dialog within Builder itself), using examples of actual data for the various placeholder sets. Be sure to give the placeholders meaningful IDs, so that you’ll recognize them readily when you construct the view. At this point, you could go ahead and create a hub with this view in Builder. There’s no need to spend a lot of time composing the perfect title and description for hub and view, because those are easy to edit later on.
Next, develop the Matlab script that will scour the relevant raw or processed experimental data, create data instances to be displayed in the view, and use dn_vibatch() to store those instances in a view instance data batch file. This is the most difficult task, but once you have it working satisfactorily, you may be able to reuse it to create instance data for future experiments of the same type, or use it as a "template" for scripts that generate instance data for other views. Be sure to read the Matlab help for dn_vibatch() carefully before you attempt to use it. Finally, reopen the hub view in Builder and load the data from the instance batch file(s) your script created. Then use the navigation view editor to “test” your view, browsing your experimental data via the navigation panels to make sure the view does what you intended it to do.
Repeat this process for each navigation view you add to your hub. Typically, you'll link the views in a hierarchical fashion in the hub's navigation map within the hub editor component. Each top-down pathway in this map should represent a logical path for exploring the hub's data.
While you’re actively constructing a hub and its views, save the .fyp files defining the view templates, your Matlab scripts and all of the view instance batch files in a dedicated folder so that, if necessary, you can reconstruct your data hub from scratch.
Once you're satisfied with the content and operation of your hub in Builder, then it's time to "publish" it to your portal. If you haven't already done so, define the portal locale in Builder. Select that locale and login to the portal. Then use the Edit|Mount command to upload a hub from the Local Archives locale to the selected portal, where it is mounted in the portal's archive vault. A progress dialog will block the user interface while the upload is performed. Once the upload has finished successfully and the archive is mounted on the portal, the archive will show up in the portal locale and will be removed from your Local Archives. Be sure to mark the archive as public (when first mounted, it is marked as private) if you want it to be accessible to the general public.
Later on you may want to add one or more navigation views to your hub, or add data collected on additional subjects. To make revisions to an existing portal archive, you must first logon and "check out" the archive via the Edit|Check out command. The portal server makes an internal copy of the checked-out archive; all revisions you make are applied to that internal copy, which is accessible only to you when you're logged into the portal. Meanwhile, the archive itself remains "live" on the portal but cannot be "checked out" for revisions by any other user. Thus, if multiple authors collaborate on the construction and maintenance of a complex archive, no author can "step on" the revisions made by another. When you're finished making changes to the archive, simply login again and use the Edit|Check in command to check-in the revisions (or discard them altogether); the internal copy containing all revisions will replace the old version of the archive, and the checkout lock is released.