Versions Compared

Version Old Version 51 New Version 52
Changes made by

Kathleen Gerdink

Kathleen Gerdink

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0
Section
Column
width50%

1. Overview

Document Store for OLE is a content management system with features like checkin, checkout, versioning, locking etc for library records such as Bibliographic, Instance (Holdings and Items), Patron, License etc. Most of the records are in XML format but the Document Store is format agnostic in that it stores the content as is without any type conversion. Furthermore indexing of the stored data is also supported for efficient search and retrieval. Although the Document Store is an independent system that comes with basic UI to enable supported operations, majority of interaction happens from OLE such as ingest of new records, editing of existing records, search and retrievals. 

Column
width50%
Panel
borderColor#97A0A9
bgColor#F8FCFF
titleBGColor#F2F8FF
borderStyledashed
Page Tree
rootOLE:@self
expandCollapseAlltrue
startDepth3
searchBoxFalse

...


1 - Denotes the 1st level of content hierarchy under the root node which represents document categories. Here its is "Work" 

2 - Denotes the 2nd level which represents the document types such as "Bibliographic" and "Instance"

3 - Denotes the 3rd level which represents the document formats such as "MARC" and "Dublin Core" for Bibliographic records and "OLEML" (OLE Markup Language defined) for Instance records.


Info
titleFile System Analogy

Content hierarchy in the docstore can be thought of as a file system with folders and files. Wherever it says "nt:folder" - think of it as behaving like a folder that can contain one or more folders and files. Wherever it says "nt:file" one can think of it as a file with actual content in it. For the MARC content hierarchy represented in the picture on the left, at L1 there can be 1 or up to 1K folders. Each MARC folder can in turn have one or up to 1K more MARC folders at L2. Each MARC folder at L2 can then have 1 or up to 1K more MARC folders at L3. Each MARC folder at L3 can then have up to 1K actual MARC files. 


L1 - This denotes level 1 where you can have up to 1K nodes.

L2 - This denotes level 2 where you can have up to 1k nodes.

L3 - This denotes level 3 where you can have up to 1K nodes.

Info
titleTotal number of MARC records at L1

Jackrabbit recommends small number of nodes per parent node for efficiency.

The total number of nodes (i.e. resulting number of files) that can be accommodated at L3 is 1M (1K * 1K), L2 is 1000M (1000 *1M) and so at L1 we can expect to handle 1000M nodes or records.

Turning on versioning for a particular node results in the creation of ~4 more nodes to maintain version info. So we can expect four times growth for data that has versioned turned on.
















Info
titleInstance Content Management & Meta Data Information

Instance content hierarchy is similar to the MARC content hierarchy explained above. For Instance data even though it may be represented as one single document, within the docstore the content is broken down and stored in the respective folders and files as shown in the picture on the left. At L1 there can be one or unto 1K OLEML folders. Each OLEML at L1 in turn can have one or up to 1K further OLEML folders at L2. Each OLEML folder at L2 can then have 1 or up to 1K Instance folders at L3. Each Instance folder can have one Instance file to store instance specific content and a folder for Holdings. Each Holdings folder can can contain one ore more Item files with Item specific content. The Holdings folder further contains a Holdings file with Holding specific information.
Meta data about each record for instance "dateLastUpdated", "fastAddFlag", "supressFromPublic" etc that can be part of the Instance/Holdings/Item records itself are stripped out and added as properties on the node. This can be thought of adding properties on a regular folder like the name and any other attributes.


 
L1 - This denotes leve 1 with a parent node and corresponding child nodes.

L2 - This denotes level 2 with up to 1K nodes.

L3 - This denotes level 3 with un to 1K nodes.

Info
titleTotal number of Instance records at L1

Jackrabbit recommends small number of nodes per parent node for efficiency.

The total number of nodes (i.e. resulting number of files) that can be accommodated at L3 is 1M (1k * 1K), L2 is 1000M (1000 * 1M) and so at L1 we can expect to handle 1000M nodes or records.

Turning on versioning for a particular node results in the creation of ~4 more nodes to maintain version info. So we can expect four times growth for data that has versioned turned on.
  

 

 

 

 


Linking within the docstore is achieved by adding reference properties on the nodes themselves to indicate which node is linked to which other node. In Jackrabbit linking is supported by property called "Reference". In regards to the linking of Bib and Instance records, there can be 1 - Many, Many - Many linking as depicted in the picture. 

Green Dots - 1 Bib - 1 Instance
Blue Dots - Many Bibs - 1 Instance
Not shown - There can be many instances with 1 Bib as well

This is the general logic model for instance in DocStore, It is showing that the business rules in the DocStore:
From one bib can link to multiple instances;
One instance may be linked by multiple bibs;
One instance has one holding, and multiple items.

 

 

...