This issue is created in response to the message below. I want to implement a simple "solution" to these needs. The "solution" consists in creating Fedora objects to hold the current configuration files as datastreams. In this way, they can be managed with Fedora tools, and they can be part of RELS-EXT and RELS-INT relationships and XACML policy controls. Whether the "solution" covers the needs fully can be an interesting discussion.
From: "firstname.lastname@example.org" <email@example.com>
Date: 12. okt 2011 16.41.11 CEST
To: "firstname.lastname@example.org Developers" <email@example.com>
Cc: Support and info exchange list for Fedora users. <firstname.lastname@example.org>
Subject: Re: [fcrepo-dev] GSearch planning
Reply-To: "email@example.com" <firstname.lastname@example.org>
Here's a less straightforward idea, which I haven't put into a Jira issue because it warrants discussion, if it evenis to become part of the roadmap.
At OR in Austin, I presented an indexing system (based partly on ideas from GSearch, but not on the GSearch codebase) that we at UVa are working on. One of the key principles of this system is that because discovery and presentation for repository contents are increasingly based on indexes, and because discovery and presentation are parts of curation (viewed broadly), it is worthwhile to move the configuration of indexing workflows inside the repository being indexed, so that indexing configuration "lives" alongside the indexed contents and can be managed through the same services. (In the example of our system, RELS-INT RDF connects metadata datastreams in indexable objects with indexer objects that contain indexing transformations.)
I'd like to propose that the roadmap for GSearch include the task of making it possible for users to move configuration for indexing transformations (not necessarily configuration for the connections between indexes and repositories, but only the configuration of indexing transformations) inside the repositories being indexed.
One key affordance that would become available would be to manage indexing transformations through the same APIs as are used for repository contents. Because changing an index transformation would no longer require altering material in the local GSearch install, but only the repository, all of the wonderful functionality that Fedora already supplies in of the core repository services would become available (e.g. XACML policy controls, metadata associations, a nice RESTful API, etc.).
Doing this would require much careful thought as to how to model and structure representations of indexing transformations in the repository context, but it could have great benefits, as tools to manage indexing would be able to rely on work already done and in progress for the management of ordinary repository contents.
Online Library Environment
the University of Virginia Library