Manipulating eprints in 3.2
- An eprint (all small letters) is our top level object which contains documents which, in turn, contain files.
- EPrints (big E, big P) is the name for the software.
A single eprint may be titled “My Really Cool Web Project” where the 1st document is the web page, which contains files like index.html, style.css etc. A second document could be the access.log (file) from the website.
This a complex example however and most people are using the one file per document paradigm, e.g. a collection of images would be one image per document. The eprint would then be the collection and would have metadata about the title of the collection. The “type” of the eprint would be “collection” or “image collection” or “thesis” etc. So a thesis collection in DSpace is simply a “type” field in EPrints.
The EPrints Submission Workflow
EPrints has 3 main states at which an eprint can live, and you can bypass the middle one:
* inbox: A users work area * buffer: The editorial buffer, after a user has finished with it but before publication, a user can sometimes control an item in the buffer, e.g. change or delete it. * archive: A live published item.
There is also a deletion stage, but that is not important, just useful.
So for a repository without an editorial buffer there is an inbox and an archive.
eprints, documents and files are all types of dataobj thus they inherit many properties from the dataobj class.
All good code should subclass and inherit a lot and thus you need to keep an eye out for this when doing development and looking at documention.
The EPrints API
As well as eprints, documents and files you can also directly manipulate the repository (used to be called session) via API calls. To find out the available calls it is best to take a look at the documentation.
I would recommend a good starting place being the API Page