Difference between revisions of "Manipulating eprints in 3.2"

From EPrints Documentation
Jump to: navigation, search
(Created page with '=EPrints Objects= * An '''eprint''' (all small letters) is our top level object which contains '''documents''' which, in turn, contain '''files'''. * '''EPrints''' (big E, big …')
 
m (adding category obsolete and eprints3.2)
 
(2 intermediate revisions by one other user not shown)
Line 1: Line 1:
 +
[[Category: Obsolete]]
 +
[[Category: Eprints3.2]]
 +
 
=EPrints Objects=
 
=EPrints Objects=
  
Line 31: Line 34:
  
 
I would recommend a good starting place being the [[API]] Page
 
I would recommend a good starting place being the [[API]] Page
 +
 +
=Traversing an EPrint=
 +
 +
  my $an_eprint = $repo->eprint( 23 );
 +
  my $title = $an_eprint->value("title");
 +
  my @docs = $an_eprint->get_all_documents();
 +
  foreach my $doc(@docs) {
 +
    foreach my $file (@{($doc->value("files"))}) {
 +
    }
 +
  }

Latest revision as of 00:48, 12 September 2018


EPrints Objects

  • 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.

DataObjs

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

Traversing an EPrint

 my $an_eprint = $repo->eprint( 23 );
 my $title = $an_eprint->value("title");
 my @docs = $an_eprint->get_all_documents();
 foreach my $doc(@docs) {
    foreach my $file (@{($doc->value("files"))}) {
    }
 }