(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.
Previous discussions
2014-10-02 - Fedora Committer Meeting
2014-10-09 - Fedora Committer Meeting
2014-10-16 - Fedora Committer Meeting
The issue
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.
Michael Durbin, Unknown User (escowles@ucsd.edu), Stefano Cossu brought up the issue and expressed interest
Possible solutions
- 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.
Proposed implementation
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.
8 Comments
Egbert Gramsbergen
Maybe I am missing something, but what is the added value of the OLO ontology above using standard rdf Collections? After all, that is, despite it's name, exactly an ordered list of items. For use cases like pages of a book, or a list of authors of an article, I see no need for anything more than an rdf Collection (http://www.w3.org/TR/rdf-schema/#ch_collectionvocab).
Andrew Woods
Stefano Cossu can speak more to what he has had in mind with OLO, but the difference that jumps out is that of strict ordering offered by OLO. In any case, it was decided that F4 will not incorporate OLO, by offering native OLO behavior. Like any ontology, users can apply OLO to F4 resources. However, to F4, they will be treated like any other predicates or RDF classes. The task of ordering is being left to the upper-level applications... for the foreseeable future.
Egbert Gramsbergen
I see. So this is not really a hot topic now. Anyway, OLO' s development seems to have stopped at version 0.72 in 2010 with a number of open TODOs. In their document they show the advantage above rdf:Seq, which is obvious. A comparison with rdf Collections would be more interesting because it's more different while achieving much of the same goal. Picking item #n with a SPARQL query is more practical in OLO, I guess. That's the strict ordering argument you mentioned? Still I find the design of rdf:Collection more elegant, but I might just be a stubborn old git.
Stefano Cossu
The original idea was to have Fedora support the machinery to provide functionality such as list size information, and automatic numbering on creation and resorting; while this has been considered to be out of the Fedora scope, I still think it is valuable to have some add-on module which does that so every implementer doesn't have to rewrite their own middleware for these very common patterns.
Since no active development has been done in this direction yet, I believe that whether OLOs are a good fit for this purpose is still an open discussion. I just offered that based on a discussion with Unknown User (escowles@ucsd.edu) but you are free to propose some other system I may have not considered. You bring up a good point about the lack of recent support of the project.
Unknown User (escowles@ucsd.edu)
Since we last talked about ordering, there has been some Hydra modeling work focusing on using ore:Proxy for ordering instead of OLO:
https://docs.google.com/document/d/1o-Iq1oKN_W5NXXDQC81pxkhibOz_AhZlY7IShxPTR5M/edit#heading=h.y88mwepgfcal
In this case, we decided to use iana:next/iana:prev links for a doubly-linked list, but it was also noted that the ore:Proxy node could also hold a numeric ordering property like olo:index.
One key advantage of both OLO and ore:Proxy ordering (compared to rdf:List) is that it is easy to retrieve all of the triples related to ordering, without having to walk through the entire sequence. ore:Proxy has the advantage of being completely optional and independent of the normal linking, so it can be ignored when order isn't important.
I agree that it's still an open discussion about whether any of these ordering systems are best for a particular use case. And until we want to build repository functionality around one of them, it seems like everyone is free to use whatever ordering strategies work best for them.
Egbert Gramsbergen
Interesting. The Hydra approach is structurally not that different from an rdf Collection superimposed on the original triples that would be there without the ordering. See a work with a list of creators, schematically (as you know, the ordering of author is important in scientific publishing): https://drive.google.com/file/d/0B-1KuNAiN-8kVmw4OVR0UHgxLWc/view
Unknown User (escowles@ucsd.edu)
Egbert Gramsbergen: Yes, that does look very similar. In the Hydra discussions we only talked about ordering Works and Files, but I had discussed using the same approach for ordering authors of our research datasets at UCSD. Our current approach isn't very good (PI identified with a special role, all other authors listed alphabetically, and a separate citation with a manually-edited author list). So we think using something like the ore:Proxy ordering will be a much better approach.
A. Soroka
This conversation is currently going on here as part of the main documentation. I encourage those who would like to continue it to do so at that location.