Hylandora Discussion at RIRI 2011

Hylandora

Summary Slide Deck of Hylandora discussions (ppt file)

Conceptual Levels of Interoperation (From Austin discussion)

1. Islandora and Hydra sharing a Fedora Repository
2. Cross platform read access.
3. Drupal-input of Hydra Objects, Drupal views of Hydra Objects.
4. Cross platform update/mgmt of same objects.

Use Cases

1. Code sharing between platforms
2. Campuses that want (or already have) both systems in use.

Aspirations

• Sharing Code
  • Components
  • Interfaces
• Sharing Objects
• Sharing Specifications, Requirements and Use Cases
• Shared use of SOLR

Discussions

Stanford has 120 Drupal developers on campus! Would like to add repository services to support them. Would like to use Islandora components to provide Drupal interfaces in and out of the repository.

Social sciences data?

Exhibits and Events?

Notre Dame is treating the exhibit as a Fedora Object with configuration in it (PIDS, SOLR search, facets).

Could create a Drupal Multisite offerered to each user; users can create static pages, and when they start to attach files, Drupal hooks will redirect the file into Fedora. Can then create SOLR/Fedora interface to index the collection. Could also do a standard ITCL based browing interface.

Currently there is a Hydra form that allows user to attach an image (or other file), and enter additional metadata to create Fedora Objects. Possibility of having the form pushed to Drupal.

Also possible that the objects were already bulk loaded into Fedora; select the objects that you want for an exhibit.

Another model is to use a staging area; select the items for the exhibit and then push the exhibit into the repository.

Question: How get a Hydra index (SOLR) exposed to Drupal for Islandora? Potentially pretty easy to configure in existing Islandora.

Once object is located, how to you view it. Hydra content model doesn't store any display information; Islandora object would need to.

Hydra objects have MODS datastream, rights datastream, and then payload files as children objects (or a single child object).

Just need to add islandora cmodel at the collection level, and add an intermediary to the read path to add the necessary extras to the Hydra object for viewing.

(Collaboration on a diagram - this capture is very incomplete, somebody insert a photo, please)

Should we standardize the objects across the platforms (supports the fourth model).

Currently Islandora using XACML; Hydra using its own rights stream; would potentially have to update two sets of rights. Would add the hydra rights stream to the SOLR indexes and queries. Both projects would like to have the two streams and have updates to one update the other. Note that we might sidestep having to do the transforms from Hydra to/from XACML by using the latest FeSL; the XACML would point to the rights metadata, and then Fedora would enforce based on the rights metadata. This is attractive because rights metadata is indexing friendly and XACML is not.

Currently Hydra rights metadata allows: Discover, Read, View, Download, Print, Publish (extensible) across identifiers for Groups and People (generic, can come from LDAP, Shib, whatever). (Link to the wiki page for rights metadata goes here).

Note that Islandora would have to phase out direct use of XACML and adopt Hydra rights metadata support. We need to ensure that XACML referring to rights metadata works (check with Steve).

Would be ideal if the implementation were a plugin or extension to Fedora.

Phased approach where Hydra writes to XACML, and eventually Islandora adds Hydra rights.

Content Metadata has a tendency to get replicated across multiple objects.

Solr/Solarizer conversation

Solarizer on chart might be an error; perhaps the information wants to be in RDF for the RI. Solr flattens the datamodel; we may want to interoperate around finding objects and their relationships, as opposed to the browse/discovery nature of Solr.

If we have a drupal page that wants to find a Hydra object, we will be doing a Solr search; is it better to place in triple store and then index object.

Want to make a distinction between type of searches you use Solr for (user requests), and a different type of search that is about the associations between the object, and arguably these should be in the triple store and not in the index. However, there isn't a reason to preclude having the associations in Solr.

Note than in Drupal 7 you can run a SPARQL query against the triple store.

Recommendation for Hydra and interoperability (and possibly future ActiveFedora): SOLR only for search; all navigation between objects done by triplestore.

Desirable to explore how we model sets / series  for compatibility.

Conclusions and next steps

Solarizer as a general Fedora tool for indexing

Solarizer as it exists today expresses the model for building the SOLR indexes in Ruby. However, work has already been done to serialize these to XML. If these serializations were to be stored in Fedora (and Solarizer were to read them back during its initialization), then Solarizer would be closer to the model of ActiveRecord with a traditional RDBMS. In addition, the code that drives the actual index building could be driven by the XML models rather than the Ruby code, which means that it could potentially be repackaged without rails, conceivably as a JRuby .war file that could be dropped into Fedora. This is architecturally similar to current work in Islandora, and could lead to a shared solution. In addition, this solution could potentially cover some of the current GSearch usage.

XACML pointing to Hydra Rights Metadata stream

If a single, magic XACML file could be created that delegates to the contents of the Hydra Rights Metadata streams, then this access control solution could be shared across Hydra and Islandora.

Post code4lib meeting in Palo Alto

Assuming that early evaluations of the above two ideas prove positive, a meeting of key developers from both projects following code4lib is desirable.