The Current State of Affairs
These are the latest and very much experimental branches.
Tuque: https://github.com/nigelgbanks/tuque/tree/break_out_implementation_fedora4
Islandora:https://github.com/nigelgbanks/islandora/commits/7.x-tuque-dev
What Changes Have Been Made:
Backwards compatibility is important to Islandora going forward. The members of the Islandora Community want to be able to use various versions of Fedora with the Latest Islandora/Tuque. The Fedora REST API changed significantly between Fedora 3 and Fedora 4 in its structure and functionality. To accommodate this we split Tuque into two wholly separate implementations that are wrapped by a generic interface, so that the Islandora module ecosystem could simultaneously use with both versions of Fedora. This has been completed, and Fedora 3 is fully functional, many of the Fedora 4 rest endpoints have are functional.
This had some far reaching but thankfully shallow implications across our module ecosystem, some 30 some odd modules required changes so they didn't refer to objects and low level repository functions directly, and instead used the abstract objects and interfaces.
Using Tuque directly one can:
- Get a description of the repository.
- Get an objects properties.
- Get a list the data-streams belonging to an object.
- Get a data-stream's content.
- Get a data-stream's properties.
- Create objects.
- Create data-streams.
- Modify a objects properties.
- Modify a data-streams properties.
- Modify a data-streams content.
- Reserve a number of PID'S.
- Purge objects.
- Purge data-streams.
What remains to be done:
The Hierarchy of display is often but not exclusively governed by fedora:isMemberOf and fedora:isMemberOfCollection relationships. There are users out there whom rely on other relationships. Most implementations of Islandora are tree like in nature, but some utilize a graph structure. Likely this will be remedied using JCR properties. It might be nice if the Fedora Ontology from Fedora 3 was supported in Fedora 4 though JCR properties.
The flow of control and logic within Islandora and its derivative modules is based heavily on the Content Model's of the given object. At some point Islandora will mimic content model types by using JCR properties.
Tuque did ingestion though FOXML this is no longer supported. So now Tuque ingestions though several steps, this should be changed into a single transaction.
The hierarchal PID's in Fedora 4 cause problems with Drupal's menu routing, it's likely we'll have to change the behaviour of all of our URL's to take a GET parameter rather than including the PID as part of URI path. This will pretty much affect 30+ modules, and how we do automatic loading of objects and data streams for Menu callbacks.
Islandora/Tuque is build upon the assumption that certain default object properties and data-streams existed such as DC, we need to investigate possible bugs from the defaults no longer being present.
- Drupal filter support
- Islandora uses ITQL and SPARQL for generating collection views of objects. These will all have to be converted to using SPARQL.
- Find a replacement for XACML.
- Find a replacement for GSearch's SOLR implementation.
- Expose an interface in Tuque for using Transactions.
