I remember your talk at Austin and have just reviewed it. I think the idea and its rationale are very good. In the case of GSearch, a first step could be to create Fedora objects that would hold the configuration files as datastreams. I will consider this in more detail soon.
Gert On 12/10/2011, at 16.41, <[email protected]> wrote: > 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. > > > --- > A. Soroka > Online Library Environment > the University of Virginia Library > > > > > On Oct 12, 2011, at 10:07 AM, Gert Schmeltz Pedersen wrote: > >> This message is meant to open for a discussion of the roadmap for GSearch. >> It started in a small group, but we invite participation from the wider >> group of fedora-developers. I copy this message to the fedora-users list so >> that GSearch users are informed about the discussion, but to follow it >> onwards and to contribute they have to subscribe to the fedora-developers >> list. >> >> I will initiate the discussion with a status. GSearch 2.2 has been the >> current release since December 2008. At OR2011 in Austin in June 2011 I >> presented a plan for development of GSearch, see >> https://conferences.tdl.org/or/OR2011/OR2011main/paper/view/416/127 . >> Following that, I have provided GSearch 2.3, and the official release is >> near. You can get the source at https://github.com/fcrepo/gsearch and >> fedoragsearch.war from the DTU prerelease site at >> http://www.cvt.dk/fedoragsearch/ and see the documentation page at >> http://miranth.cvt.dk/fedoragsearch/ . >> >> Next step in the plan is to provide GSearch 2.4 by the end of the year. I >> will use the issue tracker at >> https://jira.duraspace.org/secure/IssueNavigator.jspa?mode=hide&requestId=10311 >> to track the work, and I invite your feedback and contributions. Potential >> committers may be enrolled, I already had some responses to my invitation to >> potential committers at OR2011. Some of you may have heard at OR2011, that I >> will retire by the end of the year. However, I will continue part-time to >> support GSearch users on the fedora-users list and continue to develop for >> GSearch and Fedora in partnerships with people, who have an interest in that. >> >> The post-2.4 roadmap discussion can both be on this list and as new or >> modified issues at the issue tracker. I think that members of the initial >> small group will soon bring up issues. >> >> Gert >> ------------------------------------------------------------------------------ >> All the data continuously generated in your IT infrastructure contains a >> definitive record of customers, application performance, security >> threats, fraudulent activity and more. Splunk takes this data and makes >> sense of it. Business sense. IT sense. Common sense. >> http://p.sf.net/sfu/splunk-d2d-oct_______________________________________________ >> Fedora-commons-developers mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2d-oct > _______________________________________________ > Fedora-commons-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ Fedora-commons-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
