As long as your additional elements are correctly injected into the DC datastream, the first choice will probably be your easiest route. As far as I am aware, an index rebuild should do the job.
As far as alternatives to RI, we have to distinguish here between the Resource Index (RI) and Mulgara, which comes included with the out-of-the-box Fedora install to be your RI. Folks certainly use other triple-stores (I know MPT (based on PostgreSQL) was popular at one time and I'm sure folks use others as well). Typically those are managed as replacements for Mulgara, but the updating code is still that which is included with Fedora, and still subject to its limitations. If you want to completely replace the RI and its updaters, you'll need to supply some gear that can do the indexing you want. One alternative might be to write additions for GSearch that would perform that indexing. Another might be to use Fedora's JMS messaging directly to trigger off appropriate workflows instantiated in whatever technology you like. In either case, you'll need to supply code to select the appropriate datastreams and offer triples to your index instance in whatever form is appropriate. Keep in mind also that Fedora's use of RDF is right now subject to some careful limitations. Most importantly, the current RI will not index triples that don't have a Fedora object as their subject. This is to avoid certain updating problems. See: https://wiki.duraspace.org/display/FCREPO/Supporting+the+Semantic+Web+and+Linked+Data If you want to write your own indexing code, do be careful of those pitfalls. --- A. Soroka Digital Research and Scholarship R & D and Online Library Environment the University of Virginia Library On Nov 9, 2010, at 6:23 AM, Walker Sampson wrote: > Ben and A. Soroka, > > Thanks for the help! Yes, the extended metadata (and the RDF triples > we want to index) is from a non-compulsory datastream we have made > ourselves for each object in the repository. So, this seems to explain > why we can't see these triples from queries in RI. > > As I understand, Fedora 3.4.x allows for the DC datastream to be > Managed Content and thus be larger in size. One solution we are > considering is to append this extended metadata to the DC datastream > for each object and switch that stream to Managed Content. If we did > so, would the RI then detect and index those new RDF triples on a > rebuild? > > Another solution may be to use another indexer for the RDF triples of > our objects, one we could point to all the datastreams. Are there > suggested alternatives to RI for Fedora? > > Thanks again for your help, > > Matthew > > Walker > > > On Fri, Nov 5, 2010 at 11:59 AM, Benjamin Armintor <armin...@gmail.com> wrote: >> Matthew: >> >> The RI is automatically indexed with the content of three datastreams: >> DC >> RELS-EXT (a set of triples for which the object is the subject) >> RELS-INT (a set RDF descriptions for which the object's datastreams >> are the subject) >> >> If you have data in any other datastreams, you'll have to insert the >> triples via some other mechanism. >> >> - Ben >> >> On Fri, Nov 5, 2010 at 12:53 PM, Matthew McKinley >> <matthewjamesmckin...@gmail.com> wrote: >>> Fedora listserv, >>> >>> I've implemented the Resource Index >>> (https://wiki.duraspace.org/display/FCR30/Resource+Index) and risearch can >>> search for and return the basic dc metadata but is not returning metadata >>> from another XML file we created with extended dc:terms metadata. It is >>> returning the dc:terms XML file as a datastream but is not "parsing" the >>> file into its component metadata. The XML file is being generated >>> automatically but does not appear to have any errors that would prevent the >>> RI from recognizing it. Does anyone have any ideas what is going on? I now >>> this isn't a ton of info to go on but I'm happy to answer questions. Thanks! >>> >>> -- >>> Matthew McKinley >>> MSIS Candidate, 2010 >>> University of Texas School of Information >>> matthewjamesmckin...@gmail.com >>> >>> ------------------------------------------------------------------------------ >>> The Next 800 Companies to Lead America's Growth: New Video Whitepaper >>> David G. Thomson, author of the best-selling book "Blueprint to a >>> Billion" shares his insights and actions to help propel your >>> business during the next growth cycle. Listen Now! >>> http://p.sf.net/sfu/SAP-dev2dev >>> _______________________________________________ >>> Fedora-commons-users mailing list >>> Fedora-commons-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-users >>> >>> >> >> ------------------------------------------------------------------------------ >> The Next 800 Companies to Lead America's Growth: New Video Whitepaper >> David G. Thomson, author of the best-selling book "Blueprint to a >> Billion" shares his insights and actions to help propel your >> business during the next growth cycle. Listen Now! >> http://p.sf.net/sfu/SAP-dev2dev >> _______________________________________________ >> Fedora-commons-users mailing list >> Fedora-commons-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/fedora-commons-users >> > > ------------------------------------------------------------------------------ > The Next 800 Companies to Lead America's Growth: New Video Whitepaper > David G. Thomson, author of the best-selling book "Blueprint to a > Billion" shares his insights and actions to help propel your > business during the next growth cycle. Listen Now! > http://p.sf.net/sfu/SAP-dev2dev > _______________________________________________ > Fedora-commons-users mailing list > Fedora-commons-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/fedora-commons-users ------------------------------------------------------------------------------ The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev _______________________________________________ Fedora-commons-users mailing list Fedora-commons-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
