WLWB Internal Registry (Bobolink)

1. WLWB Internal Registry (Bobolink) What Internal, MS-Access-based WLWB document database

2. Why • Provide local access to electronic registry documentsRemoves the dependency on MV website, but adds a new one between Wekweeti and Yellowknife • Combine registry and internal documents in one repositoryDoes so, but the registry documents could remain remote and be accessed virtually (look the same, access via hyperlink). 6900 WLWB documents on registry only. • Increased searchabilityDoes allow more doc types in one place. By adding 3rd party tool for full-text searching, or tag / keyword searching, you’d enhance search. As is, will only find a word if it’s in the doc title or category. • Information gainRight now most fields are simply duplicating registry fields. New fields include doc tracking, 3rd and 4th-level categories. Potential for more doc and project fields that the registry simply doesn’t need to track.

3. How • An MS Access database on WLWB server tracks all documents (including metadata) within WLWB z:\ • Users access and update db from desktop copies • Newly added documents or metadata are updated to MV Registry • MV Registry updates (document and metadata) are meant to be pushed to the z:\ on WLWB server

4. Considerations • SharePoint Registry need not be forever • ORS Integration - will eventually be used for mass document uploads • 2-way vs 1-way transfer? (bandwidth usage, registry as an editing tool) • Initial transfer from registry to z:\ (12GB for WLWB) - automate • Requires MS Access on users’ desktops • Good potential to add value to the registry for staff • Notes to File (file-tracking) • Reporting Requirements • Difficult to integrate between boards, but maybe that isn’t a requirement?

5. Registry Feeds

6. Relationships