(See here for the current location of conversations about ordering. 17 August 2016)
This article summarizes some requirements and proposed solutions for handling ordered lists in Fedora.
There is no standardized way in Fedora to present a list of nodes in an arbitrary order defined by the user and stored in a dedicated property.
- Using MPTT/Nested Sets
- + Flexible
- + Commonly used in relational database design
- - Complicated and maybe redundant in functionality
- - Slow updating nodes
- Using Ordered List Ontology
- + Basic but effective
- + Uses RDF syntax that can be more easily integrated in Fedora
Given the pros and cons, OLO seems to be a better fit. Implementation proposal below applies to the OLO solution.
The plan I am proposing here is to add some CND definitions that allow content creators to identify a node as a list or a list slot.
A draft CND is available here: https://github.com/aic-collections/aicdams-lake/blob/test-ontology/fcrepo-webapp/src/aic/resources/cnd/aic-lists.cnd
This file contains definitions for olo:OrderedLists, olo:Slots (elements ordered in a list) and aiclist:Items (nodes that can be referenced in a list - this is optional).
Fedora should do two things behind the scene:
- Infer some properties for olo:OrderedList and olo:Slot nodes - such as olo:prev, olo:next etc (see @TODO comments in CND draft).
- olo:index can be user-provided or automated, e.g. if a Slot is added to a List without an index, Fedora assigns it the highest olo:index value in the list; or if olo:index is updated for a olo:Slot, all the other slots are update to ensure a consistent indexing.
- Either olo:ordered_list in a Slot can be inferred from olo:slot values in a OrderedList, or the other way around. This CND assumes the first scenario.
- Provide a presentation mechanism that returns nodes in a list ordered by olo:index value. This is only applicable to certain output types such as JSON or XML.