Defn. Repository

When the word 'repository' tends to have two distinct meanings, depending very much on the person who hears it. It either means:

• A 'repository' is the CRUD, search and browse application that relies on a database to store the data it uses. (I'd like to term this the 'EPrints' view)
  

Or,

• A 'repository' is a place where the data is held, and there may be software on top of that providing access to the data. (Likewise, I'd call this the 'Fedora' view)

Personally, I am a 'Fedora' person. The repository is where I stick my objects. The way people get access to these objects is through the services I provide, such as a search engine (Solr) or a web-interface written in PHP or python(coming soon).

I see much more mileage and possibility in this separation between data, store and access services, than in the monolithic approach. I do think that software like EPrints.org is monolithic and to be honest, old-fashioned. It's not like MVC architecture is a fad, or a silly idea after all and this is all I am proposing, but moved into the a new context:

• The Model is the HTTP accessible store - providing access via sensible URLs
• The Controller is defined by the data providing services, such as text-based search or RDF queries ('Get me all the objects that are in a given collection') alongside intrinsic access control mechanisms and so forth.
  
• The View is up to the end user really. The model gives access to all the parts of an object that the user can see (metadata and data alike) and the controller can deliver all sorts of ways of browsing and providing contextual information to power the view.

Is this a new idea? No. In fact, I was born in the year that this idea was apparently delivered. But from now on, when I say 'repository', I mean what I define above as the Model.