Details

    • Type: Story Story
    • Status: Closed Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: GSearch 2.4
    • Fix Version/s: GSearch 2.4
    • Component/s: GSearch
    • Labels:
      None

      Description

      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: "ajs6f@virginia.edu" <ajs6f@virginia.edu>
      Date: 12. okt 2011 16.41.11 CEST
      To: "fedora-commons-developers@lists.sourceforge.net Developers" <fedora-commons-developers@lists.sourceforge.net>
      Cc: Support and info exchange list for Fedora users. <fedora-commons-users@lists.sourceforge.net>
      Subject: Re: [fcrepo-dev] GSearch planning
      Reply-To: "fedora-commons-developers@lists.sourceforge.net" <fedora-commons-developers@lists.sourceforge.net>

      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

        Activity

        Hide
        Gert Schmeltz Pedersen added a comment -
        Adam,
        I am proposing that you perform as much of a review of this issue as you can take the time for, since you came up with it.
        The "solution" is in github as branch fcrepo-1018 and consists in one action that copies the fgsconfigFinal files into datastreams of a Fedora object, where they can be modified (and even further datastreams be created), and one action that copies the datastreams into the fgsconfigFinal files, where the modifications will take effect immediately.
        You may consider it without running it. If you want to run it, you need to checkout the branch, build for local test with the demo objects, and perform the two actions. Ask me, if you need assistance or clarifications.
        I look forward to your views on this, related to the needs that you envisioned.
        Best, Gert
        Show
        Gert Schmeltz Pedersen added a comment - Adam, I am proposing that you perform as much of a review of this issue as you can take the time for, since you came up with it. The "solution" is in github as branch fcrepo-1018 and consists in one action that copies the fgsconfigFinal files into datastreams of a Fedora object, where they can be modified (and even further datastreams be created), and one action that copies the datastreams into the fgsconfigFinal files, where the modifications will take effect immediately. You may consider it without running it. If you want to run it, you need to checkout the branch, build for local test with the demo objects, and perform the two actions. Ask me, if you need assistance or clarifications. I look forward to your views on this, related to the needs that you envisioned. Best, Gert

          People

          • Assignee:
            Gert Schmeltz Pedersen
            Reporter:
            Gert Schmeltz Pedersen
            Reviewer:
            A. Soroka
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: