...
- In-memory Data Structure
- All three will perform equally well for iteration from first to last.
- Triple Store Data Structure
- Doubly linked list + order index will perform better for fetch N items. However, this is likely to not be significant at low N. Not sure how large N needs to be before this becomes an issue.
- Doubly linked list + order index Triple Store Data Structure will perform much better for fetch page X.
Use Case: Add additional information to ListItemInfo before display
Scenario:
Display information is not part of ORE triples. For example, proxyFor is a URI to a book which has a DC.title, DC.description, etc. Would like to be able to add this information to each ListItemInfo structure and pass that to the UI code for display.
Operations:
- Fetch occurs according to previous user case.
- Before display,
- traverse the loaded items, fetch(rdf_subject=ListItemInfo.proxyFor)
- get object values to be displayed
- add to ListItemInfo hash structure
- Send updated ListItemInfo structures to UI for display
Analysis:
- In-memory Data Structure
- All three will perform equally well for traverse and update.
- See also analysis of Fetch N items use case.
- Triple Store Data Structure
- Both will perform equally well for traverse and update
- See also analysis of Fetch N items use case.
Use Case: Move position of an item in the list
Scenario:
User is browsing the list and drags an item to a new position in the list.
Operations:
- KNOWN: ListItemInfo.uri of item being moved (from id of item in display list) – could also use ListItemInfo.position
- KNOWN: ListItemInfo.uri of item preceding position of insert – could also use ListItemInfo.position
- update links of old prev item, old next item, new prev item, new next item, and item being moved (and potentially list first or last if needed)
- persist all modified resources (perhaps triggered by user clicking Save button or auto-save with each change)
Analysis:
- In-memory Data Structure
- Hash is most efficient with direct access by ListItemInfo.uri (key of hash) and no moves are required within the data structure. Only links are updated.
- Doubly linked list is less efficient as the list has to be traversed to find the items to update. No moves are required within the data structure as only links are updated.
- Array is the least efficient. Direct access using ListItemInfo.position can be used to locate the items, but the array will need to be reordered to reflect the change in order of the list items. (Assumes reorder operation is more expensive than traversal operation.)
- Triple Store Data Structure
- Both will perform equally well for move.
Use Case: Add (append) item to end of list
...
Scenario:
User is browsing the catalog and decides to add one or more bibliographic references to the list. Add items defaults to append to end of list.
Operations:
- create new instance of ORE::Proxy
- fetch ListHeaderInfo.last
- update list items prev and next links and list last
- persist all three resources
Analysis:
- In-memory Data Structure
- All three will perform equally well for append.
- Triple Store Data Structure
- Both will perform equally well for append.
Use Case: Sort list items by value not stored in list.
Scenario:
User chooses to sort list items by a display value that is not stored as part of the triples associated with the ORE list triples. For example, the list is aggregating bibliographic references. The properties of the bibliographic references may be stored in a separate triplestore. Example sort criteria are title, publication date,
Operations:
Analysis:
- In-memory Data Structure
- ???
- Triple Store Data Structure
- ???
...
List Header Info Structure
...