Matt, you've written a really excellent article there. It really gets
to the heart of the problem. Since Solr's query language is so
comprehensive, you're right -- as long as the index is looked after, it
should be able to feed me all the info I need on my application.
With this strategy, the only times I should have to interact with the
repo directly are when I'm:
* requesting a specific asset
* ingesting and purging
In a related matter - what about object permissions? Do you recommend
handling that entirely with fedora policy? That would seem a bit of a
burden, although I admit I was impressed by the way islandora deals with
it (adding a filter to permit fedora to lookup user roles from the
client application db).
Matthew Zumwalt wrote:
> IMO this is the right approach. Use the Fedora PIDs as your unique
> identifiers across all client applications. If you need broader
> assurances of uniqueness, you could look at Ben O'Steen's work
> on UUIDs & Fedora
> <
http://oxfordrepo.blogspot.com/2008/01/conclusions-on-uuids-and-local-ids-in.html>.
>
>
> Most people index their metadata in Solr and run searches against
> that. This solves your problem of ensuring that queries are handled
> by software that's optimized for searching. Of course, then you will
> have to get the metadata into Solr and ensure that Solr is kept up to
> date. This blog post
> <
http://yourmediashelf.com/blog/2010/03/01/blacklight-activefedora-and-shelver-interplay-between-searching-managing-and-indexing-in-a-repository-solution/> might
> provide some helpful info in that area.
>
> You could also put the relationship info into the Resource Index
> (Fedora's bundled triplestore) and use SPARQL or iTQL to query against
> that. By default, Fedora will index any triples that you assert in
> the RELS-EXT datastream, putting them into the Resource Index (if the
> Resource Index is turned on).
>
> Matt Zumwalt
> MediaShelf, LLC
>
http://www.yourmediashelf.com
>