https://wiki.eprints.org/w/api.php?action=feedcontributions&user=LesCarr&feedformat=atomEPrints Documentation - User contributions [en-gb]2024-03-28T17:56:38ZUser contributionsMediaWiki 1.31.8https://wiki.eprints.org/w/index.php?title=New_Stuff&diff=5902New Stuff2007-12-14T12:38:24Z<p>LesCarr: </p>
<hr />
<div>= Discussing EPrints Development =<br />
<br />
Please use eprints-devel to discuss future development. To review changes to our tickets and repository, subscribe to eprints-changes.<br />
<br />
To subscribe to the lists, send a mail with one of the following lines in the message body to [mailto:majordomo@ecs.soton.ac.uk majordomo@ecs.soton.ac.uk]<br />
<br />
subscribe eprints-devel<br />
subscribe eprints-changes<br />
<br />
WARNING: eprints-changes may be HIGH traffic.<br />
<br />
= Release Plans = <br />
<br />
Exact schedules are not yet decided.<br />
<br />
We plan to release a beta of EPrints 3.1 in the first few months of 2008. <br />
<br />
3.1 will be a one way upgrade from 3.0 but with minimal hassle. A few config. files may require tweaks, and the database structure may be slightly changed. 3.1 will introduce new features.<br />
<br />
Once the first 3.1 beta is released we will make a branch. We will then develop new features for 3.2 while providing bug fix releases for 3.1 and 3.0. Once 3.1 appears to be reliable, we declare it stable, and stop providing bug fix releases for 3.0. In theory no new features will be added after 3.1 beta-1, but this may be a rule we bend. A more fixed rule is that no new features will be added to 3.1 after 3.1.0 is released, so we can aim for stability. (phew)<br />
<br />
3.1.x releases will, like 3.0.x, only provide bug fixes and very small changes, such as minor configuration options, which will not change the behavior unless you set them.<br />
<br />
Quite a few parts of EPrints 3.1 will be Plugins or sets of plugins and cgi scripts. The collective term for these is "extensions". A bunch of files together which can be added to EPrints to add functionality, without requiring hacking the core code. Where possible we will release the extensions and plugins individually on EPrints Files. This serves two purposes:<br />
# Sites which don't yet want to upgrade to an unstable release can get the key feature they need.<br />
# It means each extension will get tested by more sites, earlier.<br />
<br />
= New Features Planned for EPrints 3.1 =<br />
This page is to collect the features that we have planned or had requested to appear in EPrints 3.1 . This page does NOT constitute any form of guarantee as to the features that will actually appear!<br />
<br />
This page shows both planned and proposed features.<br />
* Planned features are features that will be in 3.1 unless they run into difficulty or priorities shift. <br />
* Proposed features are features that we'd like to do, but probably won't. <br />
* ... as extension; these are new features which can be packaged up entirely as an extension, with no change to the core code. These are intended to be included in the final 3.1.0 release, but may be released separately on files.eprints.org before that time. If things slip they make not make it into the 3.1 series, but will be available from files.eprints.org.<br />
<br />
Roughly speaking, planned things need to actually have a specification, whereas proposed things can be a bit vauge.<br />
<br />
== Scalability ==<br />
<br />
===Planned as extension===<br />
* [http://trac.eprints.org/trac/ticket/2857 Subjects input component that doesn't load everything at once - AJAX fetching of lower levels]<br />
<br />
===Planned===<br />
* Handling HUGE authority lists (use SQL database with index; just document this, no code needed)<br />
* [http://trac.eprints.org/trac/ticket/3162 Eliminate need to run generate_abstracts: by detecting when a flag has changed and rebuilding abstract page on demand. ]<br />
<br />
===Proposed===<br />
* Eliminate need to run generate_views by rebuilding pages on request if they are more than N hours old.<br />
: I think the ideal would be to only rebuild view pages when necessary -- eg when new subjects have been added or new eprints have been added, just regenerate the views in which they need to appear. Is there some reason that can't be done? It would still be up to the admin to re-run g_v after some more serious configuration change which affects the views. Better yet, do away with the static pages and make EPrints fast enough to generate everything on the fly :) [[User:Ben|Ben]] 23:06, 11 December 2007 (GMT)<br />
<br />
== Increased Interoperability ==<br />
<br />
No final decision yet on exact set of new plugins. May just come down to "those that are ready when we go to beta."<br />
<br />
* More importers to improve the ease of deposit by leveraging existing editorial effort in external services (e.g. arxiv, ACM Digital Library, IEEE Digital Library, Web of Science, DSpace, Fedora, ORE, PDF and Office metadata extractors)<br />
* Extending data-entry quality with more Name Authorities (e.g. Conferences) and other auto-completion (uncontrolled keywords). <br />
* Increase the value of holdings with a wider range of exporters (e.g. wordprocessors, spreadsheets, email, ZIP, MP3 for podcasting, RDF for the Semantic Web, DSpace, Fedora, ORE)<br />
<br />
== Repository-scale Quality Management: ==<br />
<br />
=== Planned ===<br />
<br />
* [http://trac.eprints.org/trac/ticket/3167 Add a QA Screen similar to admin screen, which will be a place holder for QA tasks]<br />
* Find a nice way to add a QA role (possibly separate from editor role)<br />
* generate and email warnings about anomalous metadata states (e.g. items "in press" for more than 24 months) as trialed in ECS<br />
<br />
=== Proposed as extensions ===<br />
<br />
* duplicate detection<br />
* legacy metadata correction using name authorities and authoritative sources such as CrossRef<br />
* efficient batch checking and editing including one-step search and replace across the whole repository, e.g. replace "DeRoure" with "De Roure" in all Creator.Surname fields or batch editing - allowing a single metadata field to be efficiently checked and corrected in multiple eprints, e.g. a screen containing editable Journal Name fields from 100 separate eprints.<br />
<br />
== Administration Configuration Management ==<br />
<br />
=== Planned as extensions ===<br />
<br />
* User interface control panels for some (hopefully, eventually, all) repository configuration that are currently performed by editing configuration files.<br />
* Config file browser<br />
* Config file editor <br />
* EPrints config reloader <br />
* EPrints abstracts regnerator <br />
<br />
These should all check that the config is OK.. config file should revert if needed.<br />
<br />
Possibly these will require some uber-admin role.<br />
<br />
=== Proposed as extensions ===<br />
<br />
* HTML Visualisation of configuration files (workflow, phrases etc.)<br />
* Skins manager for branding.<br />
* Manager for object types (e.g. article, thesis) and metadata fields (e.g. "experimental technician" for a data set or "director" for a multimedia object.)<br />
* Multilingual phrase editor.<br />
* Deposit Workflow editor.<br />
* Process Workflow editor (see below)<br />
* Subject Hierachy editor (already exists)<br />
* Browse View and Bespoke Search editors<br />
* Plugin Manager to control non-core software.<br />
<br />
== Desktop Integration ==<br />
<br />
Making EPrints work better with the authors' desktop environemnt (laptop / Microsoft Office / file system browser.<br />
<br />
=== Planned as extension ===<br />
<br />
* A drag-and-drop-interface client for submitting files, using SWORD. This would create a basic record in the repository.<br />
* Read-only interface via webdav<br />
<br />
=== Proposed as extension ===<br />
<br />
* Read/Write webdav interface.<br />
<br />
== Web 2.0 ==<br />
<br />
Pending outcomes from [http://www.eprints.org/software/web2.php Web 2 meeting]<br />
<br />
== Other Features ==<br />
<br />
=== Planned ===<br />
<br />
* More built-in metadata for scientific data applications.<br />
** URIs for documents.<br />
** Need some advice from the experts on this one. ie. The guys who've already been doing this stuff.<br />
* the ability to search subobjects and related items, eg. search eprints by document format (already done)<br />
* Elimination of need for generate_static (this is mostly done)<br />
* Improved generate_views to produce variations of a view (by first author, by year etc.)<br />
* Action icons for delete/deposit/edit etc on "Manage Items" and "Review". This is done, but the icons could be nicer :-)<br />
* EPrints Toolkit - a service-level API that is available through scripting and REST interfaces. This is done, but still requires security and may gain some features before 3.1<br />
* Export and RSS feeds for view pages.<br />
* add_field and remove_field bin scripts.<br />
* ZIP , wget and .tar.gz feature for file upload.<br />
* Custom templates for searches, views and abstract pages for basic collection styling.<br />
<br />
=== Proposed ===<br />
<br />
* Process Workflow: as well as the deposit workflow, a process workflow will manage the various sequences of actions that an eprint can undergo from creation to final deposit (and beyond). This may include collaborative authoring, problem management, refereeing, copyright clearance, security clearance, IPR checking, metadata quality checks, e-journal and conference workflows. (EPrints currently allows, but does not manage, process workflows.)<br />
* Plugin "masking" - to allow an installed plugin to subclass an existing plugin but to be called '''instead''' of it. This would be very useful for the DC plugin.<br />
* AJAX autocompletion on search fields.<br />
<br />
=== Proposed as Extension ===<br />
<br />
* Virtual Collections: an individual eprint may be represent a collection of other eprint items; mainly used for image collections, workshop proceedings or learning objects composed of teaching assets. This may be achievable just with a new default type.<br />
* Calendar view: calendar screen to track all embargo and license expirations, plus other planned events and timeouts.<br />
* Increased support for "eprints application profile" Dublin Core recommendations.<br />
* Web Services interface: currently in beta, awaiting debugging of the .NET SOAP interface.<br />
* Better Semantic Web support (see Harry Mason's PhD work)<br />
* Integration with Google Scholar or Web of Science (for citation capture and analysis.<br />
** Gather citation data (score) from somewhere<br />
** Provide view<br />
** Provide search/order facility on this.<br />
* Map widgets for input/output of location metadata<br />
* Interoperable Statistics: statistics on the download use of individual eprints, eprint collections (per user, per research group, per community) or whole repository. (This is already provided as a separate IRStats package.)<br />
* Validation Workflow Component (needs some bugs ironing out)<br />
* Extra metadata fields</div>LesCarrhttps://wiki.eprints.org/w/index.php?title=Web2.0&diff=5901Web2.02007-12-14T08:58:51Z<p>LesCarr: </p>
<hr />
<div>== Outcomes from the Web 2.0 Pow-wow 13th December 2007 ==<br />
<br />
The talk of the day mainly focused on Web 2 as a user-centric approach to creating web applications.<br />
<br />
* The [http://beta.richtags.net/ Richtags project] have produced a wonderful interface to multiple EPrints repositories to facilitate social interaction.<br />
<br />
* Connotea (Nature) already has an established EPrints user interface component<br />
<br />
* ULCC has the [http://sneep.ulcc.ac.uk/ SNEEP project] and the [http://www.linnean-online.org/ Linnaean society repository]. They have been developing comments and bookmarking facilities.<br />
<br />
* The [http://edspace.eprints.org EDSPACE project] is developing a user-centric approach to learning object repository.<br />
<br />
* The [http://www.faroes.ecs.soton.ac.uk/index.php FARAOES project] are developing a repository user interface that follows the best-practice principles of Web 2.0 sites<br />
<br />
Web 2.0 facilities could be (are already in some EPrints repositories) handled by external services (Digg, del.icio.us, Connotea). The advantage of this approach is that there is little complexity in the repository itself, but equally, there is little benefit (value add) that the repository can offer the user.<br />
<br />
It may be better to implement tagging and comment and other facilities within the repository, so that (for example) items can be ranked by the number of comments, or their digg-style 'score'.<br />
<br />
The accumulated commenting and tagging data that such an approach gathers might be better managed in separate user area - the user has their own area of the database where their comments an their tags are stored. There is already a user dataset in EPrints - perhaps its role needs to be enlarged.<br />
<br />
Alternatively, these items can be managed as a separate table (by separate processes and user interfaces and services if necessary) and EPrints can just interpret the fields in the table as if they were readonly eprint metadata.<br />
<br />
On the other ''other'' hand, EPrints can provide a category of metadata items that behave as normal (accessible through the standard API and user interface) but don't trigger changes in the metadata history or last-changed time. After all, an article doesn't change just because someone rates it.</div>LesCarrhttps://wiki.eprints.org/w/index.php?title=Web2.0&diff=5900Web2.02007-12-13T16:40:02Z<p>LesCarr: </p>
<hr />
<div>== Outcomes from the Web 2.0 Pow-wow 13th December 2007 ==<br />
<br />
User-centric approach to a web application. The accumulated data that such an approach gathers might be better managed in separate user area - the user has their own area of the database.<br />
<br />
* The [http://beta.richtags.net/ Richtags project] have produced a wonderful interface to multiple EPrints repositories to facilitate social interaction.<br />
<br />
* Connotea (Nature) already has an established EPrints user interface component<br />
<br />
* ULCC has the [http://sneep.ulcc.ac.uk/ SNEEP project] and the [http://www.linnean-online.org/ Linnaean society repository]. They have been developing comments and bookmarking facilities.<br />
<br />
* The [http://edspace.eprints.org EDSPACE project] is developing a user-centric approach to learning object repository.<br />
<br />
* The [http://www.faroes.ecs.soton.ac.uk/index.php FARAOES project] are developing a repository user interface that follows the best-practice principles of Web 2.0 sites</div>LesCarrhttps://wiki.eprints.org/w/index.php?title=Web2.0&diff=5899Web2.02007-12-13T16:39:44Z<p>LesCarr: </p>
<hr />
<div>== Outcomes from the Web 2.0 Pow-wow 13th December 2007 ==<br />
<br />
User-centric approach to a web application. The accumulated data that such an approach gathers might be better managed in separate user area - the user has their own area of the database.<br />
<br />
* The [http://beta.richtags.net/ Richtags project] have produced a wonderful interface to multiple repositories to facilitate social interaction.<br />
<br />
* Connotea (Nature) already has an established EPrints user interface component<br />
<br />
* ULCC has the [http://sneep.ulcc.ac.uk/ SNEEP project] and the [http://www.linnean-online.org/ Linnaean society repository]. They have been developing comments and bookmarking facilities.<br />
<br />
* The [http://edspace.eprints.org EDSPACE project] is developing a user-centric approach to learning object repository.<br />
<br />
* The [http://www.faroes.ecs.soton.ac.uk/index.php FARAOES project] are developing a repository user interface that follows the best-practice principles of Web 2.0 sites</div>LesCarrhttps://wiki.eprints.org/w/index.php?title=Web2.0&diff=5898Web2.02007-12-13T16:34:10Z<p>LesCarr: </p>
<hr />
<div>== Outcomes from the Web 2.0 Pow-wow 13th December 2007 ==<br />
<br />
User-centric approach to a web application. The accumulated data that such an approach gathers might be better managed in separate user area - the user has their own area of the database.<br />
<br />
* The [http://beta.richtags.net/ Richtags project] have produced a wonderful interface to multiple repositories to facilitate social interaction.<br />
<br />
* Connotea (Nature) already has an established EPrints user interface component<br />
<br />
* ULCC has the [http://sneep.ulcc.ac.uk/ SNEEP project] and the [http://www.linnean-online.org/ Linnaean society repository]. They have been developing comments and bookmarking facilities.</div>LesCarrhttps://wiki.eprints.org/w/index.php?title=Web2.0&diff=5897Web2.02007-12-13T16:31:17Z<p>LesCarr: </p>
<hr />
<div>== Outcomes from the Web 2.0 Pow-wow 13th December 2007 ==<br />
<br />
User-centric approach to a web application. The accumulated data that such an approach gathers might be better managed in separate user area - the user has their own area of the database.<br />
<br />
* The [[Richtags project] http://beta.richtags.net/] have produced a wonderful interface to multiple repositories to facilitate social interaction.<br />
<br />
* Connotea (Nature) already has an established EPrints user interface component<br />
<br />
* ULCC has the [[SNEEP project] http://sneep.ulcc.ac.uk/] and the [[Linnaean society repository] http://www.linnean-online.org/]. They have been developing comments and bookmarking facilities.</div>LesCarrhttps://wiki.eprints.org/w/index.php?title=Web2.0&diff=5896Web2.02007-12-13T16:20:50Z<p>LesCarr: </p>
<hr />
<div>== Outcomes from the Web 2.0 Pow-wow 13th December 2007 ==<br />
<br />
User-centric approach to a web application. The accumulated data that such an approach gathers might be better managed in separate user area - the user has their own area of the database.<br />
<br />
Richtags<br />
<br />
Connotea (Nature).<br />
<br />
ULCC: SNEEP project, Linnaean society repository.<br />
<br />
OpenID</div>LesCarrhttps://wiki.eprints.org/w/index.php?title=New_Stuff&diff=5860New Stuff2007-12-11T17:53:45Z<p>LesCarr: /* Planned as extension */</p>
<hr />
<div>= New Features Planned for EPrints 3.1 =<br />
This page is to collect the features that we have planned or had requested to appear in EPrints 3.1 . This page does NOT constitute any form of guarantee as to the features that will actually appear!<br />
<br />
This page shows both planned and proposed features.<br />
* Planned features are features that will be in 3.1 unless they run into difficulty or priorities shift. <br />
* Proposed features are features that we'd like to do, but probably won't. <br />
* ... as extension; these are new features which can be packaged up entirely as an extension, with no change to the core code. These are intended to be included in the final 3.1.0 release, but may be released separately on files.eprints.org before that time. If things slip they make not make it into the 3.1 series, but will be available from files.eprints.org.<br />
<br />
Roughly speaking, planned things need to actually have a specification, whereas proposed things can be a bit vauge.<br />
<br />
== Scalability ==<br />
<br />
===Planned as extension===<br />
* Subjects input component that doesn't load everything at once - AJAX fetching of lower levels: http://trac.eprints.org/trac/ticket/2857<br />
<br />
===Planned===<br />
* Handling HUGE authority lists (use SQL database with index; just document this, no code needed)<br />
* Eliminate need to run generate_abstracts: by detecting when a flag has changed and rebuilding abstract page on demand.<br />
<br />
===Proposed===<br />
* Eliminate need to run generate_views by rebuilding pages on request if they are more than N hours old.<br />
<br />
== Increased Interoperability ==<br />
<br />
No final decision yet on exact set of new plugins. May just come down to "those that are ready when we go to beta."<br />
<br />
* More importers to improve the ease of deposit by leveraging existing editorial effort in external services (e.g. arxiv, ACM Digital Library, IEEE Digital Library, Web of Science, DSpace, Fedora, ORE, PDF and Office metadata extractors)<br />
* Extending data-entry quality with more Name Authorities (e.g. Conferences) and other auto-completion (uncontrolled keywords). <br />
* Increase the value of holdings with a wider range of exporters (e.g. wordprocessors, spreadsheets, email, ZIP, MP3 for podcasting, RDF for the Semantic Web, DSpace, Fedora, ORE)<br />
<br />
== Repository-scale Quality Management: ==<br />
<br />
=== Planned ===<br />
<br />
* Add a QA Screen similar to admin screen, which will be a place holder for QA tasks<br />
* Find a nice way to add a QA role (possibly separate from editor role)<br />
* generate and email warnings about anomalous metadata states (e.g. items "in press" for more than 24 months) as trailed in ECS<br />
<br />
=== Proposed as extensions ===<br />
<br />
* duplicate detection<br />
* legacy metadata correction using name authorities and authoritative sources such as CrossRef<br />
* efficient batch checking and editing including one-step search and replace across the whole repository, e.g. replace "DeRoure" with "De Roure" in all Creator.Surname fields or batch editing - allowing a single metadata field to be efficiently checked and corrected in multiple eprints, e.g. a screen containing editable Journal Name fields from 100 separate eprints.<br />
<br />
== Administration Configuration Management ==<br />
<br />
=== Planned as extensions ===<br />
<br />
* User interface control panels for some (hopefully, eventually, all) repository configuration that are currently performed by editing configuration files.<br />
* Config file browser<br />
* Config file editor <br />
* EPrints config reloader <br />
* EPrints abstracts regnerator <br />
<br />
These should all check that the config is OK.. config file should revert if needed.<br />
<br />
Possibly these will require some uber-admin role.<br />
<br />
=== Proposed as extensions ===<br />
<br />
* HTML Visualisation of configuration files (workflow, phrases etc.)<br />
* Skins manager for branding.<br />
* Manager for object types (e.g. article, thesis) and metadata fields (e.g. "experimental technician" for a data set or "director" for a multimedia object.)<br />
* Multilingual phrase editor.<br />
* Deposit Workflow editor.<br />
* Process Workflow editor (see below)<br />
* Subject Hierachy editor (already exists)<br />
* Browse View and Bespoke Search editors<br />
* Plugin Manager to control non-core software.<br />
<br />
== Desktop Integration ==<br />
<br />
Making EPrints work better with the authors' desktop environemnt (laptop / Microsoft Office / file system browser.<br />
<br />
=== Planned as extension ===<br />
<br />
* A drag-and-drop-interface client for submitting files, using SWORD. This would create a basic record in the repository.<br />
* Read-only interface via webdav<br />
<br />
=== Proposed as extension ===<br />
<br />
* Read/Write webdav interface.<br />
<br />
== Web 2.0 ==<br />
<br />
Pending outcomes from [http://www.eprints.org/software/web2.php Web 2 meeting]<br />
<br />
== Other Features ==<br />
<br />
=== Planned ===<br />
<br />
* More built-in metadata for scientific data applications.<br />
** URIs for documents.<br />
** Need some advice from the experts on this one. ie. The guys who've already been doing this stuff.<br />
* the ability to search subobjects and related items, eg. search eprints by document format (already done)<br />
* Elimination of need for generate_static (this is mostly done)<br />
* Improved generate_views to produce variations of a view (by first author, by year etc.)<br />
* Action icons for delete/deposit/edit etc on "Manage Items" and "Review". This is done, but the icons could be nicer :-)<br />
* EPrints Toolkit - a service-level API that is available through scripting and REST interfaces. This is done, but still requires security and may gain some features before 3.1<br />
* Export and RSS feeds for view pages.<br />
<br />
=== Proposed ===<br />
<br />
* Process Workflow: as well as the deposit workflow, a process workflow will manage the various sequences of actions that an eprint can undergo from creation to final deposit (and beyond). This may include collaborative authoring, problem management, refereeing, copyright clearance, security clearance, IPR checking, metadata quality checks, e-journal and conference workflows. (EPrints currently allows, but does not manage, process workflows.)<br />
<br />
=== Proposed as Extension ===<br />
<br />
* Virtual Collections: an individual eprint may be represent a collection of other eprint items; mainly used for image collections, workshop proceedings or learning objects composed of teaching assets. This may be achievable just with a new default type.<br />
* Calendar view: calendar screen to track all embargo and license expirations, plus other planned events and timeouts.<br />
* Increased support for "eprints application profile" Dublin Core recommendations.<br />
* Web Services interface: currently in beta, awaiting debugging of the .NET SOAP interface.<br />
* Better Semantic Web support (see Harry Mason's PhD work)<br />
* Integration with Google Scholar or Web of Science (for citation capture and analysis.<br />
** Gather citation data (score) from somewhere<br />
** Provide view<br />
** Provide search/order facility on this.<br />
* Map widgets for input/output of location metadata<br />
* Interoperable Statistics: statistics on the download use of individual eprints, eprint collections (per user, per research group, per community) or whole repository.</div>LesCarrhttps://wiki.eprints.org/w/index.php?title=New_Stuff&diff=5859New Stuff2007-12-11T17:51:47Z<p>LesCarr: /* Desktop Integration */</p>
<hr />
<div>= New Features Planned for EPrints 3.1 =<br />
This page is to collect the features that we have planned or had requested to appear in EPrints 3.1 . This page does NOT constitute any form of guarantee as to the features that will actually appear!<br />
<br />
This page shows both planned and proposed features.<br />
* Planned features are features that will be in 3.1 unless they run into difficulty or priorities shift. <br />
* Proposed features are features that we'd like to do, but probably won't. <br />
* ... as extension; these are new features which can be packaged up entirely as an extension, with no change to the core code. These are intended to be included in the final 3.1.0 release, but may be released separately on files.eprints.org before that time. If things slip they make not make it into the 3.1 series, but will be available from files.eprints.org.<br />
<br />
Roughly speaking, planned things need to actually have a specification, whereas proposed things can be a bit vauge.<br />
<br />
== Scalability ==<br />
<br />
===Planned as extension===<br />
* Subjects input component that doesn't load everything at once - AJAX fetching of lower levels: http://trac.eprints.org/trac/ticket/2857<br />
<br />
===Planned===<br />
* Handling HUGE authority lists (use SQL database with index; just document this, no code needed)<br />
* Eliminate need to run generate_abstracts: by detecting when a flag has changed and rebuilding abstract page on demand.<br />
<br />
===Proposed===<br />
* Eliminate need to run generate_views by rebuilding pages on request if they are more than N hours old.<br />
<br />
== Increased Interoperability ==<br />
<br />
No final decision yet on exact set of new plugins. May just come down to "those that are ready when we go to beta."<br />
<br />
* More importers to improve the ease of deposit by leveraging existing editorial effort in external services (e.g. arxiv, ACM Digital Library, IEEE Digital Library, Web of Science, DSpace, Fedora, ORE, PDF and Office metadata extractors)<br />
* Extending data-entry quality with more Name Authorities (e.g. Conferences) and other auto-completion (uncontrolled keywords). <br />
* Increase the value of holdings with a wider range of exporters (e.g. wordprocessors, spreadsheets, email, ZIP, MP3 for podcasting, RDF for the Semantic Web, DSpace, Fedora, ORE)<br />
<br />
== Repository-scale Quality Management: ==<br />
<br />
=== Planned ===<br />
<br />
* Add a QA Screen similar to admin screen, which will be a place holder for QA tasks<br />
* Find a nice way to add a QA role (possibly separate from editor role)<br />
* generate and email warnings about anomalous metadata states (e.g. items "in press" for more than 24 months) as trailed in ECS<br />
<br />
=== Proposed as extensions ===<br />
<br />
* duplicate detection<br />
* legacy metadata correction using name authorities and authoritative sources such as CrossRef<br />
* efficient batch checking and editing including one-step search and replace across the whole repository, e.g. replace "DeRoure" with "De Roure" in all Creator.Surname fields or batch editing - allowing a single metadata field to be efficiently checked and corrected in multiple eprints, e.g. a screen containing editable Journal Name fields from 100 separate eprints.<br />
<br />
== Administration Configuration Management ==<br />
<br />
=== Planned as extensions ===<br />
<br />
* User interface control panels for some (hopefully, eventually, all) repository configuration that are currently performed by editing configuration files.<br />
* Config file browser<br />
* Config file editor <br />
* EPrints config reloader <br />
* EPrints abstracts regnerator <br />
<br />
These should all check that the config is OK.. config file should revert if needed.<br />
<br />
Possibly these will require some uber-admin role.<br />
<br />
=== Proposed as extensions ===<br />
<br />
* HTML Visualisation of configuration files (workflow, phrases etc.)<br />
* Skins manager for branding.<br />
* Manager for object types (e.g. article, thesis) and metadata fields (e.g. "experimental technician" for a data set or "director" for a multimedia object.)<br />
* Multilingual phrase editor.<br />
* Deposit Workflow editor.<br />
* Process Workflow editor (see below)<br />
* Subject Hierachy editor (already exists)<br />
* Browse View and Bespoke Search editors<br />
* Plugin Manager to control non-core software.<br />
<br />
== Desktop Integration ==<br />
<br />
Making EPrints work better with the authors' desktop environemnt (laptop / Microsoft Office / file system browser.<br />
<br />
=== Planned as extension ===<br />
<br />
* A drop-interface for submitting files, using SWORD. This would create a basic record in the repository.<br />
* Read-only interface via webdav<br />
<br />
=== Proposed as extension ===<br />
<br />
* Read/Write webdav interface.<br />
<br />
== Web 2.0 ==<br />
<br />
Pending outcomes from [http://www.eprints.org/software/web2.php Web 2 meeting]<br />
<br />
== Other Features ==<br />
<br />
=== Planned ===<br />
<br />
* More built-in metadata for scientific data applications.<br />
** URIs for documents.<br />
** Need some advice from the experts on this one. ie. The guys who've already been doing this stuff.<br />
* the ability to search subobjects and related items, eg. search eprints by document format (already done)<br />
* Elimination of need for generate_static (this is mostly done)<br />
* Improved generate_views to produce variations of a view (by first author, by year etc.)<br />
* Action icons for delete/deposit/edit etc on "Manage Items" and "Review". This is done, but the icons could be nicer :-)<br />
* EPrints Toolkit - a service-level API that is available through scripting and REST interfaces. This is done, but still requires security and may gain some features before 3.1<br />
* Export and RSS feeds for view pages.<br />
<br />
=== Proposed ===<br />
<br />
* Process Workflow: as well as the deposit workflow, a process workflow will manage the various sequences of actions that an eprint can undergo from creation to final deposit (and beyond). This may include collaborative authoring, problem management, refereeing, copyright clearance, security clearance, IPR checking, metadata quality checks, e-journal and conference workflows. (EPrints currently allows, but does not manage, process workflows.)<br />
<br />
=== Proposed as Extension ===<br />
<br />
* Virtual Collections: an individual eprint may be represent a collection of other eprint items; mainly used for image collections, workshop proceedings or learning objects composed of teaching assets. This may be achievable just with a new default type.<br />
* Calendar view: calendar screen to track all embargo and license expirations, plus other planned events and timeouts.<br />
* Increased support for "eprints application profile" Dublin Core recommendations.<br />
* Web Services interface: currently in beta, awaiting debugging of the .NET SOAP interface.<br />
* Better Semantic Web support (see Harry Mason's PhD work)<br />
* Integration with Google Scholar or Web of Science (for citation capture and analysis.<br />
** Gather citation data (score) from somewhere<br />
** Provide view<br />
** Provide search/order facility on this.<br />
* Map widgets for input/output of location metadata<br />
* Interoperable Statistics: statistics on the download use of individual eprints, eprint collections (per user, per research group, per community) or whole repository.</div>LesCarrhttps://wiki.eprints.org/w/index.php?title=New_Stuff&diff=5858New Stuff2007-12-11T17:49:47Z<p>LesCarr: /* Planned */</p>
<hr />
<div>= New Features Planned for EPrints 3.1 =<br />
This page is to collect the features that we have planned or had requested to appear in EPrints 3.1 . This page does NOT constitute any form of guarantee as to the features that will actually appear!<br />
<br />
This page shows both planned and proposed features.<br />
* Planned features are features that will be in 3.1 unless they run into difficulty or priorities shift. <br />
* Proposed features are features that we'd like to do, but probably won't. <br />
* ... as extension; these are new features which can be packaged up entirely as an extension, with no change to the core code. These are intended to be included in the final 3.1.0 release, but may be released separately on files.eprints.org before that time. If things slip they make not make it into the 3.1 series, but will be available from files.eprints.org.<br />
<br />
Roughly speaking, planned things need to actually have a specification, whereas proposed things can be a bit vauge.<br />
<br />
== Scalability ==<br />
<br />
===Planned as extension===<br />
* Subjects input component that doesn't load everything at once - AJAX fetching of lower levels: http://trac.eprints.org/trac/ticket/2857<br />
<br />
===Planned===<br />
* Handling HUGE authority lists (use SQL database with index; just document this, no code needed)<br />
* Eliminate need to run generate_abstracts: by detecting when a flag has changed and rebuilding abstract page on demand.<br />
<br />
===Proposed===<br />
* Eliminate need to run generate_views by rebuilding pages on request if they are more than N hours old.<br />
<br />
== Increased Interoperability ==<br />
<br />
No final decision yet on exact set of new plugins. May just come down to "those that are ready when we go to beta."<br />
<br />
* More importers to improve the ease of deposit by leveraging existing editorial effort in external services (e.g. arxiv, ACM Digital Library, IEEE Digital Library, Web of Science, DSpace, Fedora, ORE, PDF and Office metadata extractors)<br />
* Extending data-entry quality with more Name Authorities (e.g. Conferences) and other auto-completion (uncontrolled keywords). <br />
* Increase the value of holdings with a wider range of exporters (e.g. wordprocessors, spreadsheets, email, ZIP, MP3 for podcasting, RDF for the Semantic Web, DSpace, Fedora, ORE)<br />
<br />
== Repository-scale Quality Management: ==<br />
<br />
=== Planned ===<br />
<br />
* Add a QA Screen similar to admin screen, which will be a place holder for QA tasks<br />
* Find a nice way to add a QA role (possibly separate from editor role)<br />
* generate and email warnings about anomalous metadata states (e.g. items "in press" for more than 24 months) as trailed in ECS<br />
<br />
=== Proposed as extensions ===<br />
<br />
* duplicate detection<br />
* legacy metadata correction using name authorities and authoritative sources such as CrossRef<br />
* efficient batch checking and editing including one-step search and replace across the whole repository, e.g. replace "DeRoure" with "De Roure" in all Creator.Surname fields or batch editing - allowing a single metadata field to be efficiently checked and corrected in multiple eprints, e.g. a screen containing editable Journal Name fields from 100 separate eprints.<br />
<br />
== Administration Configuration Management ==<br />
<br />
=== Planned as extensions ===<br />
<br />
* User interface control panels for some (hopefully, eventually, all) repository configuration that are currently performed by editing configuration files.<br />
* Config file browser<br />
* Config file editor <br />
* EPrints config reloader <br />
* EPrints abstracts regnerator <br />
<br />
These should all check that the config is OK.. config file should revert if needed.<br />
<br />
Possibly these will require some uber-admin role.<br />
<br />
=== Proposed as extensions ===<br />
<br />
* HTML Visualisation of configuration files (workflow, phrases etc.)<br />
* Skins manager for branding.<br />
* Manager for object types (e.g. article, thesis) and metadata fields (e.g. "experimental technician" for a data set or "director" for a multimedia object.)<br />
* Multilingual phrase editor.<br />
* Deposit Workflow editor.<br />
* Process Workflow editor (see below)<br />
* Subject Hierachy editor (already exists)<br />
* Browse View and Bespoke Search editors<br />
* Plugin Manager to control non-core software.<br />
<br />
== Desktop Integration ==<br />
<br />
Making EPrints work from a desktop.<br />
<br />
=== Planned as extension ===<br />
<br />
* A drop-interface for submitting files, using SWORD. This would create a basic record in the repository.<br />
* Read-only interface via webdav<br />
<br />
=== Proposed as extension ===<br />
<br />
* Read/Write webdav interface.<br />
<br />
== Web 2.0 ==<br />
<br />
Pending outcomes from [http://www.eprints.org/software/web2.php Web 2 meeting]<br />
<br />
== Other Features ==<br />
<br />
=== Planned ===<br />
<br />
* More built-in metadata for scientific data applications.<br />
** URIs for documents.<br />
** Need some advice from the experts on this one. ie. The guys who've already been doing this stuff.<br />
* the ability to search subobjects and related items, eg. search eprints by document format (already done)<br />
* Elimination of need for generate_static (this is mostly done)<br />
* Improved generate_views to produce variations of a view (by first author, by year etc.)<br />
* Action icons for delete/deposit/edit etc on "Manage Items" and "Review". This is done, but the icons could be nicer :-)<br />
* EPrints Toolkit - a service-level API that is available through scripting and REST interfaces. This is done, but still requires security and may gain some features before 3.1<br />
* Export and RSS feeds for view pages.<br />
<br />
=== Proposed ===<br />
<br />
* Process Workflow: as well as the deposit workflow, a process workflow will manage the various sequences of actions that an eprint can undergo from creation to final deposit (and beyond). This may include collaborative authoring, problem management, refereeing, copyright clearance, security clearance, IPR checking, metadata quality checks, e-journal and conference workflows. (EPrints currently allows, but does not manage, process workflows.)<br />
<br />
=== Proposed as Extension ===<br />
<br />
* Virtual Collections: an individual eprint may be represent a collection of other eprint items; mainly used for image collections, workshop proceedings or learning objects composed of teaching assets. This may be achievable just with a new default type.<br />
* Calendar view: calendar screen to track all embargo and license expirations, plus other planned events and timeouts.<br />
* Increased support for "eprints application profile" Dublin Core recommendations.<br />
* Web Services interface: currently in beta, awaiting debugging of the .NET SOAP interface.<br />
* Better Semantic Web support (see Harry Mason's PhD work)<br />
* Integration with Google Scholar or Web of Science (for citation capture and analysis.<br />
** Gather citation data (score) from somewhere<br />
** Provide view<br />
** Provide search/order facility on this.<br />
* Map widgets for input/output of location metadata<br />
* Interoperable Statistics: statistics on the download use of individual eprints, eprint collections (per user, per research group, per community) or whole repository.</div>LesCarrhttps://wiki.eprints.org/w/index.php?title=Preservation_Support&diff=5841Preservation Support2007-12-09T19:49:59Z<p>LesCarr: </p>
<hr />
<div>= Preservation Support in EPrints 3 =<br />
<br />
EPrints version 3 introduces a number of features that will help support the preservation of digital objects stored in repositories. We refer here to preservation as providing for the long-term access to digital objects.<br />
<br />
The features described here have been jointly developed with the [http://preserv.eprints.org/ Preserv project], with coding on the METS and Creative Commons (CC) licensing components by Preserv. The features are designed to allow an EPrints repository to support preservation through a specialist service provider. The key actions covered include:<br />
<br />
* Recording changes to a repository object by updating its 'preservation metadata' (History Module)<br />
* Enabling the service provider to download all the files and metadata comprising an object (METS and DIDL export plugins)<br />
* Notifying the service provider of any rights it has to copy and act on the content of an object (CC licencing)<br />
<br />
== Complex-Object Export: METS and DIDL plugins ==<br />
<br />
There are many ways to disseminate digital objects stored in an EPrints repository, depending on whether the request for an object comes from a human user or a machine (e.g. a search engine robot), and on what service is requested. The request may be for a full-text document, or for the data to be presented in some other format.<br />
<br />
To increase the number of 'export' formats available in EPrints v3 it is possible to write ''plugins'' - modular bits of code that are dynamically loaded into the system. Plugins are a new mechanism for customising and extending EPrints by writing code that interacts with the core software but is not part of it. In this way plugins can be written and implemented independently, and made available for others to use. These modules are written in Perl and can perform a number of roles: importing and exporting from and to arbitrary formats, converting documents from one format to another (for full-text indexing) and user interface widgets. Plugins sit in their own directory and are registered by EPrints when the system is run.<br />
<br />
EPrints export plugins convert ''repository objects'' (things that contain metadata and files) into streamed data, in most cases XML. Objects can be exported through the EPrints Web interface (in search results, abstract pages or from the user's workspace), the [http://www.openarchives.org/ OAI-PMH] interface, or from the command-line `export` script. <br />
<br />
There are already a number of object types in EPrints that are supported by export plugins, as shown in Figure 1. The OpenURL !ContextObject export plugin can also be used to export ''!AccessLog objects'', which enables access logs to be harvested from EPrints. ''Document objects'' are exported as part of an EPrint object. (There are several other EPrint objects available in EPrints - ''Users, saved searches and History'' - but these aren't yet exportable, until export plugins have been written to support them.)<br />
<br />
[[Image:eprints_exports.png]]<br />
<br />
'''Figure 1. Export formats suported by EPrints plugins'''<br />
<br />
If the request to export an object from a repository is from a preservation service provider, it will need to obtain all the files associated with the object. Objects that have more than one file are often referred to as 'complex objects'.<br />
<br />
To support more efficient transfer of complex objects, two formats that may be used to disseminate objects for digital preservation are Metadata Encoding Transmission Standard [http://www.loc.gov/standards/mets/ METS] and MPEG-21 Digital Item Declaration Language [http://www.chiariglione.org/mpeg/standards/mpeg-21/mpeg-21.htm DIDL]. Examples of the XML exports for these two formats are shown in Figures 2 and 3.<br />
<br />
The METS export plugin is derived from work done by the [http://www.inf.aber.ac.uk/bridge/ Repository Bridge] project, who implemented a METS export for EPrints 2. This has been updated for the new plugin architecture and data model in EPrints 3.<br />
<br />
[[Image:eprints_mets.png]]<br />
<br />
'''Figure 2. METS export format example'''<br />
<br />
DIDL support has been built by Chris Gutteridge (the lead developer on EPrints) as the result of collaboration with researchers from the [http://www.dlib.org/dlib/november03/bekaert/11bekaert.html Los Alamos National Laboratory] who have utilised MPEG-21 DIDL to build digital library systems. While DIDL is less well known in the digital preservation field, it serves a similar purpose and may well end up being more widely used (given the strength of backing of media companies in MPEG standards).<br />
<br />
[[Image:eprints_didl.png]]<br />
<br />
'''Figure 3. MPEG-21/DIDL export format example'''<br />
<br />
== History Module ==<br />
<br />
EPrints v3 introduces a new 'history' function that documents all changes made to records, from the point of deposit (when the record was first created) onwards. Currently this feature is used to provide an audit trail for editorial purposes, but as digital preservation services are developed they will need to modify the content of repositories, e.g. to migrate file formats, and such actions must be recorded to inform later preservation decisions. To keep track of what has happened to a record the repository will need to store both the object itself and all actions that have been performed on it over time.<br />
<br />
Figure 4 visualises changes that have been made to an object. In this instance a new 'Document' has been added to the record, with the consequent addition of new files.<br />
<br />
[[Image:eprints_history.png]]<br />
<br />
'''Figure 4. History module shows the addition of a new document in the record for an object'''<br />
<br />
== Preservation Rights Declaration ==<br />
<br />
An issue raised by the British Library, a partner acting as a prospective preservation service provider in the Preserv project, is that it needs appropriate permissions to handle materials for preservation purposes. With this in mind a 'license' option has been added to the EPrints deposit process allowing the depositing user to provide an explicit license for access to their deposited materials (Figures 5 and 6). Based on [http://creativecommons.org/ Creative Commons], these licenses have been included in the EPrints v3 beta version. If an explicit license is required for preservation purposes (e.g. the right of a third party to store and act on the material, e.g. perform migration, etc.) this can easily be included.<br />
<br />
[[Image:preserv_file_upload.png]]<br />
<br />
'''Figure 5. Part of EPrints deposit form showing License field'''<br />
<br />
[[Image:preserv_file_upload_license.png]]<br />
<br />
'''Figure 6. Drop-down options from License field'''</div>LesCarrhttps://wiki.eprints.org/w/index.php?title=Manual&diff=5840Manual2007-12-09T19:49:01Z<p>LesCarr: /* Misc */</p>
<hr />
<div>See the [[Main Page]] for other areas of this wiki.<br />
<br />
= Introduction to EPrints 3 =<br />
<br />
* [[Introduction]]<br />
* How to Get Help/Support<br />
* [[History]] <br />
<br />
<table cellpadding="10"><tr><td width="33%" valign="top"><br />
<br />
= Installation and First Steps =<br />
<br />
== Download ==<br />
{{Download}}<br />
<br />
== Installing EPrints From Binary ==<br />
* [[Installing EPrints 3 via Redhat RPM]]<br />
* [[Installing EPrints 3 via Fedora RPM]]<br />
* [[Installing EPrints 3 via apt (Debian/Ubuntu)]]<br />
<br />
== Using the Live CD ==<br />
* [[Ubuntu Live CD Help]]<br />
<br />
== Installing EPrints From Source (.tar.gz) ==<br />
<br />
* [[Recommended Platforms]]<br />
* [[Required software]]<br />
* Install Guides<br />
** [[Installing Eprints 3 on Fedora Core 7]] (also applicable to FC6)<br />
** [[Installing EPrints 3 on RedHat Enterprise 4]]<br />
** [[Installing EPrints 3 on OS X]]<br />
** [[Debian from source | Installing EPrints 3 on Debian/Ubuntu - The Quick Way]]<br />
** [[Installing EPrints 3 on Ubuntu 6.10]]<br />
** [[Installing EPrints 3 on Debian]]<br />
** [[Installing in a chroot Debian/Ubuntu]]<br />
** [[:Category:Installation|Installing]] EPrints on various platforms.<br />
* [[Https3 | Installing EPrints 3 with an https server]]<br />
<br />
==Post Installation==<br />
<br />
* [[Upgrading EPrints 3 versions | Upgrading from an earlier version of EPrints3]]<br />
* [[Migration|Migrating from EPrints 2.3]]<br />
<br />
==Getting Started==<br />
* [[Getting Started with EPrints 3|Getting Started]] <br />
<br />
* Maintenance <br />
** [[Backups]]<br />
** [[Generate Scripts]]<br />
** [[Alerts]]<br />
** [[Log Files]]<br />
** [[Automating your maintenance]]<br />
<br />
* [[Troubleshooting]]<br />
</td><td width="33%" valign="top" style="border-left: solid 1px #ccc; border-right: solid 1px #ccc;"><br />
<br />
= How-to Guides =<br />
<br />
''[http://en.wikipedia.org/wiki/Howto What is a how-to?]<br />
<br />
* Orientation <span style="color: #f94; font-size: 130%">(Start here)</span><br />
** [[Configuration orientation|New to EPrints 3?]] - ''before diving into the how-tos, take some time to read through this brief orientation guide and familiarise yourself with the EPrints configuration landscape...''<br />
** [[EPrints_3_Configuration_orientation_for_EPrints_2_administrators|Migrated from EPrints 2?]] - ''this orientation guide is intended to help you re-orient yourselves in your new EPrints 3 set up...'' <br />
* [[Front Page Warning | Removing the Front Page Warning]] - Your first go at branding<br />
* [[Branding with confidence]] - ''one of the most common EPrints customisations is to add your own institution's branding and "look and feel" to the interface...''<br />
** [[Branding, the next level]] - ''how to completely change the interface to your own design''<br />
* [[OAI]]<br />
* [[Adding new views]]<br />
* Workflow<br />
* Deposit Types<br />
** [[Removing types]]<br />
* Metadata<br />
* Subjects (fold in with Organisation Hierarchy under "controled vocabularies")<br />
* [[EPrints_3_Organisation_Hierarchy|Organisation Hierarchy]] - ''how to put your own organisation's Hierarchy into EPrints 3''<br />
* Searches<br />
* [[Autocompletion and Authority Files (Romeo Autocomplete)]] - ''add autocomplete functionality to the Publication Title input field based on an authority file downloaded from EPrints Romeo...''<br />
* [[Create Export Plugins]] - ''create a Perl Module that will export your data...''<br />
* [[Login-Only Repository]] - ''require a username and password to access all pages (including search, browse, and the front page)...''<br />
* [[Change Deposit Status in Bulk]] - ''move a large number of deposits from inbox to archive<br />
* [[Customisation|more]]<br />
<br />
= How-to contribute =<br />
<br />
There's a number of different ways you can contribute to the EPrints project. This section covers all the ones we can think of...<br />
<br />
Always make an entry on http://files.eprints.org/ for your contribution, even if you don't upload the files. This will make it the one-stop place for people to find EPrints extensions.<br />
<br />
* [[Contribute: Plugins | Plugins]]<br />
* [[Contribute: Scripts | Scripts]]<br />
* [[Contribute: Themes | Themes]]<br />
* [[Contribute: Translations | Translations]]<br />
* [[Contribute: Other | Other neighbourly things to do]]<br />
* [[Extension Packages]]<br />
<br />
= Misc =<br />
<br />
* [[Preservation Support]] in EPrints 3<br />
* [[i18n]]<br />
</td><td valign="top" width="33%"><br />
<br />
= Technical Reference =<br />
<br />
* [[EPrints Directory Structure]] - will be linked somewhere better, later.<br />
<br />
* [[Metadata]] - configuring metadata fields.<br />
* [[Archives/ARCHIVEID/cfg/|Repository Configuration]]<br />
* [[XML Configuration]] Files<br />
** [[EPScript]] - documentation for the EP3 Scripting language (for use in citations and workflow files).<br />
** [[EPrints Control Format]] - the structure used to embed EPScript in an XML configuration file.<br />
** [[Citation Format]]<br />
** [[Workflow Format]] - the structure of the EP3 workflow files<br />
** [[Phrase Format]]<br />
** [[Template Format]]<br />
** [[XPAGE Format]]<br />
* [[XML Export Format]]<br />
* EPrints data structure <br />
** of the software<br />
** of the database (relating the dataobjects to each other using eprints fields)<br />
* [[Data Object]]s and data sets<br />
** The [[EPrint Object]]<br />
** The [[User Object]]<br />
** The [[Document Object]]<br />
** The [[Subject Object]]<br />
** The [[Saved Search Object]]<br />
** The [[History Object]]<br />
** The [[Access Object]]<br />
** The [[Request Object]]<br />
* Plugins<br />
** Import<br />
** [[Export Plugins]]<br />
** Components<br />
** [[Screen Plugins]]<br />
** Convert<br />
* [[Autocompletion]]<br />
** [[Understanding IDs in Workflow Forms]]<br />
* [[API]]<br />
* [[Dynamic Template System]]<br />
</td></tr></table></div>LesCarrhttps://wiki.eprints.org/w/index.php?title=New_Stuff&diff=5839New Stuff2007-12-08T22:50:41Z<p>LesCarr: </p>
<hr />
<div>= New Features Planned for EPrints 3.1 =<br />
This page is to collect the features that we have planned or had requested to appear in EPrints 3.1 . This page does NOT constitute any form of guarantee as to the features that will actually appear!<br />
<br />
== Already In ==<br />
* the ability to search subobjects and related items, eg. search eprints by document format<br />
* the improved way gen_static works so that most pages can be rebuilt automatically to save running the script all the time (current exception= auto js and auto css but that's doable)<br />
* improved generate_views with new features<br />
* the action icons for delete/deposit/edit etc on "Manage Items" and "Review"<br />
* API Toolkit - a service-level API that is available through scripting and REST interfaces<br />
* Interoperable Statistics: statistics on the download use of individual eprints, eprint collections (per user, per research group, per community) or whole repository. <br />
<br />
== Increased Interoperability ==<br />
* More importers to improve the ease of deposit by leveraging existing editorial effort in external services (e.g. arxiv, ACM Digital Library, IEEE Digital Library, Web of Science, DSpace, Fedora, ORE, PDF and Office metadata extractors)<br />
* Extending data-entry quality with more Name Authorities (e.g. Conferences) and other auto-completion (uncontrolled keywords). <br />
* Increase the value of holdings with a wider range of exporters (e.g. wordprocessors, spreadsheets, email, ZIP, MP3 for podcasting, RDF for the Semantic Web, DSpace, Fedora, ORE)<br />
<br />
== Repository-scale Quality Management: ==<br />
* duplicate detection<br />
* legacy metadata correction using name authorities and authoritative sources such as CrossRef<br />
* efficient batch checking and editing including one-step search and replace across the whole repository, e.g. replace "DeRoure" with "De Roure" in all Creator.Surname fields or batch editing - allowing a single metadata field to be efficiently checked and corrected in multiple eprints, e.g. a screen containing editable Journal Name fields from 100 separate eprints.<br />
<br />
== Administration Configuration Management ==<br />
User interface control panels for all repository configuration that are currently performed by editing configuration files.<br />
* Skins manager for branding.<br />
* Manager for object types (e.g. article, thesis) and metadata fields (e.g. "experimental technician" for a data set or "director" for a multimedia object.)<br />
* Multilingual phrase editor.<br />
* Deposit Workflow editor.<br />
* Process Workflow editor (see below)<br />
* Subject Hierachy editor (already exists)<br />
* Browse View and Bespoke Search editors<br />
* Plugin Manager to control non-core software.<br />
<br />
== Other Features ==<br />
* Process Workflow: as well as the deposit workflow, a process workflow will manage the various sequences of actions that an eprint can undergo from creation to final deposit (and beyond). This may include collaborative authoring, problem management, refereeing, copyright clearance, security clearance, IPR checking, metadata quality checks, e-journal and conference workflows. (EPrints currently allows, but does not manage, process workflows.)<br />
* Virtual Collections: an individual eprint may be represent a collection of other eprint items; mainly used for image collections, workshop proceedings or learning objects composed of teaching assets.<br />
* Calendar view: calendar screen to track all embargo and license expirations, plus other planned events and timeouts.<br />
* Increased support for "eprints application profile" Dublin Core recommendations.<br />
* Web Services interface: currently in beta, awaiting debugging of the .NET SOAP interface.<br />
* Integration with Researcher's Desktop (the repository is just another Network Place via WebDAV).<br />
* Web 2.0 support (see outcomes from [http://www.eprints.org/software/web2.php] Web 2 meeting]<br />
* Better Semantic Web support (see Harry Mason's PhD work)<br />
* Integration with Google Scholar or Web of Science (for citation capture and analysis)<br />
* More built-in metadata for scientific data applications.<br />
* Map widgets for input/output of location metadata</div>LesCarrhttps://wiki.eprints.org/w/index.php?title=New_Stuff&diff=5838New Stuff2007-12-08T18:28:43Z<p>LesCarr: </p>
<hr />
<div>= New Features Planned for EPrints 3.1 =<br />
This page is to collect the features that we have planned or had requested to appear in EPrints 3.1 . This page does NOT constitute any form of guarantee as to the features that will actually appear!<br />
<br />
== Already In ==<br />
* the ability to search subobjects and related items, eg. search eprints by document format<br />
* the improved way gen_static works so that most pages can be rebuilt automatically to save running the script all the time (current exception= auto js and auto css but that's doable)<br />
* improved generate_views with new features<br />
* the action icons for delete/deposit/edit etc on "Manage Items" and "Review"<br />
* API Toolkit - a service-level API that is available through scripting and REST interfaces<br />
* Interoperable Statistics: statistics on the download use of individual eprints, eprint collections (per user, per research group, per community) or whole repository. <br />
<br />
== Increased Interoperability ==<br />
* More importers to improve the ease of deposit by leveraging existing editorial effort in external services (e.g. arxiv, ACM Digital Library, IEEE Digital Library, Web of Science, DSpace, Fedora, ORE, PDF and Office metadata extractors)<br />
* Extending data-entry quality with more Name Authorities (e.g. Conferences) and other auto-completion (uncontrolled keywords). <br />
* Increase the value of holdings with a wider range of exporters (e.g. wordprocessors, spreadsheets, email, ZIP, MP3 for podcasting, RDF for the Semantic Web, DSpace, Fedora, ORE)<br />
<br />
== Repository-scale Quality Management: ==<br />
* duplicate detection<br />
* legacy metadata correction using name authorities and authoritative sources such as CrossRef<br />
* efficient batch checking and editing including one-step search and replace across the whole repository, e.g. replace "DeRoure" with "De Roure" in all Creator.Surname fields or batch editing - allowing a single metadata field to be efficiently checked and corrected in multiple eprints, e.g. a screen containing editable Journal Name fields from 100 separate eprints.<br />
<br />
== Administration Configuration Management ==<br />
User interface control panels for all repository configuration that are currently performed by editing configuration files.<br />
* Skins manager for branding.<br />
* Manager for object types (e.g. article, thesis) and metadata fields (e.g. "experimental technician" for a data set or "director" for a multimedia object.)<br />
* Multilingual phrase editor.<br />
* Deposit Workflow editor.<br />
* Process Workflow editor (see below)<br />
* Subject Hierachy editor (already exists)<br />
* Browse View and Bespoke Search editors<br />
* Plugin Manager to control non-core software.<br />
<br />
== Other Features ==<br />
* Process Workflow: as well as the deposit workflow, a process workflow will manage the various sequences of actions that an eprint can undergo from creation to final deposit (and beyond). This may include collaborative authoring, problem management, refereeing, copyright clearance, security clearance, IPR checking, metadata quality checks, e-journal and conference workflows. (EPrints currently allows, but does not manage, process workflows.)<br />
* Virtual Collections: an individual eprint may be represent a collection of other eprint items; mainly used for image collections, workshop proceedings or learning objects composed of teaching assets.<br />
* Calendar view: calendar screen to track all embargo and license expirations, plus other planned events and timeouts.<br />
* Increased support for "eprints application profile" Dublin Core recommendations.<br />
* Web Services interface: currently in beta, awaiting debugging of the .NET SOAP interface.<br />
* Integration with Researcher's Desktop (the repository is just another Network Place via WebDAV).<br />
* Web 2.0 support (see outcomes from [http://www.eprints.org/software/web2.php] Web 2 meeting]<br />
* Better Semantic Web support (see Harry Mason's PhD work)<br />
* Integration with Google Scholar or Web of Science</div>LesCarrhttps://wiki.eprints.org/w/index.php?title=New_Stuff&diff=5837New Stuff2007-12-07T17:58:53Z<p>LesCarr: </p>
<hr />
<div>= New Features Planned for EPrints 3.1 =<br />
This page is to collect the features that we have planned or had requested to appear in EPrints 3.1 . This page does NOT constitute any form of guarantee as to the features that will actually appear!<br />
<br />
== Already In ==<br />
* the ability to search subobjects and related items, eg. search eprints by document format<br />
* the improved way gen_static works so that most pages can be rebuilt automatically to save running the script all the time (current exception= auto js and auto css but that's doable)<br />
* the action icons for delete/deposit/edit etc on "Manage Items" and "Review"<br />
* API Toolkit - a service-level API that is available through scripting and REST interfaces<br />
* Interoperable Statistics: statistics on the download use of individual eprints, eprint collections (per user, per research group, per community) or whole repository. <br />
<br />
== Increased Interoperability ==<br />
* More importers to improve the ease of deposit by leveraging existing editorial effort in external services (e.g. arxiv, ACM Digital Library, IEEE Digital Library, Web of Science, DSpace, Fedora, ORE, PDF and Office metadata extractors)<br />
* Extending data-entry quality with more Name Authorities (e.g. Conferences) and other auto-completion (uncontrolled keywords). <br />
* Increase the value of holdings with a wider range of exporters (e.g. wordprocessors, spreadsheets, email, ZIP, MP3 for podcasting, RDF for the Semantic Web, DSpace, Fedora, ORE)<br />
<br />
== Repository-scale Quality Management: ==<br />
* duplicate detection<br />
* legacy metadata correction using name authorities and authoritative sources such as CrossRef<br />
* efficient batch checking and editing including one-step search and replace across the whole repository, e.g. replace "DeRoure" with "De Roure" in all Creator.Surname fields or batch editing - allowing a single metadata field to be efficiently checked and corrected in multiple eprints, e.g. a screen containing editable Journal Name fields from 100 separate eprints.<br />
<br />
== Administration Configuration Management ==<br />
User interface control panels for all repository configuration that are currently performed by editing configuration files.<br />
* Skins manager for branding.<br />
* Manager for object types (e.g. article, thesis) and metadata fields (e.g. "experimental technician" for a data set or "director" for a multimedia object.)<br />
* Multilingual phrase editor.<br />
* Deposit Workflow editor.<br />
* Process Workflow editor (see below)<br />
* Subject Hierachy editor (already exists)<br />
* Browse View and Bespoke Search editors<br />
* Plugin Manager to control non-core software.<br />
<br />
== Other Features ==<br />
* Process Workflow: as well as the deposit workflow, a process workflow will manage the various sequences of actions that an eprint can undergo from creation to final deposit (and beyond). This may include collaborative authoring, problem management, refereeing, copyright clearance, security clearance, IPR checking, metadata quality checks, e-journal and conference workflows. (EPrints currently allows, but does not manage, process workflows.)<br />
* Virtual Collections: an individual eprint may be represent a collection of other eprint items; mainly used for image collections, workshop proceedings or learning objects composed of teaching assets.<br />
* Calendar view: calendar screen to track all embargo and license expirations, plus other planned events and timeouts.<br />
* Increased support for "eprints application profile" Dublin Core recommendations.<br />
* Web Services interface: currently in beta, awaiting debugging of the .NET SOAP interface.<br />
* Integration with Researcher's Desktop (the repository is just another Network Place via WebDAV).<br />
* Web 2.0 support (see outcomes from [http://www.eprints.org/software/web2.php] Web 2 meeting]<br />
* Better Semantic Web support (see Harry Mason's PhD work)</div>LesCarrhttps://wiki.eprints.org/w/index.php?title=New_Stuff&diff=5836New Stuff2007-12-07T17:57:13Z<p>LesCarr: </p>
<hr />
<div>= New Features Planned for EPrints 3.1 =<br />
This page is to collect the features that we have planned or had requested to appear in EPrints 3.1 . This page does NOT constitute any form of guarantee as to the features that will actually appear!<br />
<br />
== Already In ==<br />
* the ability to search subobjects and related items, eg. search eprints by document format<br />
* the improved way gen_static works so that most pages can be rebuilt automatically to save running the script all the time (current exception= auto js and auto css but that's doable)<br />
* the action icons for delete/deposit/edit etc on "Manage Items" and "Review"<br />
* API Toolkit - a service-level API that is available through scripting and REST interfaces<br />
* Interoperable Statistics: statistics on the download use of individual eprints, eprint collections (per user, per research group, per community) or whole repository. <br />
<br />
== Increased Interoperability ==<br />
* More importers to improve the ease of deposit by leveraging existing editorial effort in external services (e.g. arxiv, ACM Digital Library, IEEE Digital Library, Web of Science, DSpace, Fedora, ORE, PDF and Office metadata extractors)<br />
* Extending data-entry quality with more Name Authorities (e.g. Conferences) and other auto-completion (uncontrolled keywords). <br />
* Increase the value of holdings with a wider range of exporters (e.g. wordprocessors, spreadsheets, email, ZIP, MP3 for podcasting, RDF for the Semantic Web, DSpace, Fedora, ORE)<br />
<br />
== Repository-scale Quality Management: ==<br />
* duplicate detection<br />
* legacy metadata correction using name authorities and authoritative sources such as CrossRef<br />
* efficient batch checking and editing including one-step search and replace across the whole repository, e.g. replace "DeRoure" with "De Roure" in all Creator.Surname fields or batch editing - allowing a single metadata field to be efficiently checked and corrected in multiple eprints, e.g. a screen containing editable Journal Name fields from 100 separate eprints.<br />
<br />
== Administration Configuration Management ==<br />
User interface control panels for all repository configuration that are currently performed by editing configuration files.<br />
* Skins manager for branding.<br />
* Manager for object types (e.g. article, thesis) and metadata fields (e.g. "experimental technician" for a data set or "director" for a multimedia object.)<br />
* Multilingual phrase editor.<br />
* Deposit Workflow editor.<br />
* Process Workflow editor (see below)<br />
* Subject Hierachy editor (already exists)<br />
* Browse View and Bespoke Search editors<br />
* Plugin Manager to control non-core software.<br />
<br />
== Other Features ==<br />
* Process Workflow: as well as the deposit workflow, a process workflow will manage the various sequences of actions that an eprint can undergo from creation to final deposit (and beyond). This may include collaborative authoring, problem management, refereeing, copyright clearance, security clearance, IPR checking, metadata quality checks, e-journal and conference workflows. (EPrints currently allows, but does not manage, process workflows.)<br />
* Virtual Collections: an individual eprint may be represent a collection of other eprint items; mainly used for image collections, workshop proceedings or learning objects composed of teaching assets.<br />
* Calendar view: calendar screen to track all embargo and license expirations, plus other planned events and timeouts.<br />
* Increased support for "eprints application profile" Dublin Core recommendations.<br />
* Web Services interface: currently in beta, awaiting debugging of the .NET SOAP interface.<br />
* Integration with Researcher's Desktop (the repository is just another Network Place via WebDAV).</div>LesCarrhttps://wiki.eprints.org/w/index.php?title=New_Stuff&diff=5835New Stuff2007-12-07T17:55:37Z<p>LesCarr: </p>
<hr />
<div>= New Features Planned for EPrints 3.1 =<br />
This page is to collect the features that we have planned or had requested to appear in EPrints 3.1 . This page does NOT constitute any form of guarantee as to the features that will actually appear!<br />
<br />
== Already In ==<br />
* the ability to search subobjects and related items, eg. search eprints by document format<br />
* the improved way gen_static works so that most pages can be rebuilt automatically to save running the script all the time (current exception= auto js and auto css but that's doable)<br />
* the action icons for delete/deposit/edit etc on "Manage Items" and "Review"<br />
* Integration with Researcher's Desktop (the repository is just another Network Place via WebDAV).<br />
* API Toolkit - a service-level API that is available through scripting and REST interfaces<br />
<br />
== Increased Interoperability ==<br />
* More importers to improve the ease of deposit by leveraging existing editorial effort in external services (e.g. arxiv, ACM Digital Library, IEEE Digital Library, Web of Science, DSpace, Fedora, ORE, PDF and Office metadata extractors)<br />
* Extending data-entry quality with more Name Authorities (e.g. Conferences) and other auto-completion (uncontrolled keywords). <br />
* Increase the value of holdings with a wider range of exporters (e.g. wordprocessors, spreadsheets, email, ZIP, MP3 for podcasting, RDF for the Semantic Web, DSpace, Fedora, ORE)<br />
<br />
== Repository-scale Quality Management: ==<br />
* duplicate detection<br />
* legacy metadata correction using name authorities and authoritative sources such as CrossRef<br />
* efficient batch checking and editing including one-step search and replace across the whole repository, e.g. replace "DeRoure" with "De Roure" in all Creator.Surname fields or batch editing - allowing a single metadata field to be efficiently checked and corrected in multiple eprints, e.g. a screen containing editable Journal Name fields from 100 separate eprints.<br />
<br />
== Administration Configuration Management ==<br />
User interface control panels for all repository configuration that are currently performed by editing configuration files.<br />
* Skins manager for branding.<br />
* Manager for object types (e.g. article, thesis) and metadata fields (e.g. "experimental technician" for a data set or "director" for a multimedia object.)<br />
* Multilingual phrase editor.<br />
* Deposit Workflow editor.<br />
* Process Workflow editor (see below)<br />
* Subject Hierachy editor (already exists)<br />
* Browse View and Bespoke Search editors<br />
* Plugin Manager to control non-core software.<br />
<br />
== Other Features ==<br />
* Process Workflow: as well as the deposit workflow, a process workflow will manage the various sequences of actions that an eprint can undergo from creation to final deposit (and beyond). This may include collaborative authoring, problem management, refereeing, copyright clearance, security clearance, IPR checking, metadata quality checks, e-journal and conference workflows. (EPrints currently allows, but does not manage, process workflows.)<br />
* Virtual Collections: an individual eprint may be represent a collection of other eprint items; mainly used for image collections, workshop proceedings or learning objects composed of teaching assets.<br />
* Interoperable Statistics: statistics on the download use of individual eprints, eprint collections (per user, per research group, per community) or whole repository. <br />
* Calendar view: calendar screen to track all embargo and license expirations, plus other planned events and timeouts.<br />
* Increased support for "eprints application profile" Dublin Core recommendations.<br />
* Web Services interface: currently in beta, awaiting debugging of the .NET SOAP interface.</div>LesCarrhttps://wiki.eprints.org/w/index.php?title=New_Stuff&diff=5834New Stuff2007-12-06T12:50:45Z<p>LesCarr: </p>
<hr />
<div>= New Features Planned for EPrints 3.1 =<br />
This page is to collect the features that we have planned or had requested to appear in EPrints 3.1 . This page does NOT constitute any form of guarantee as to the features that will actually appear!<br />
<br />
== Increased Interoperability ==<br />
* More importers to improve the ease of deposit by leveraging existing editorial effort in external services (e.g. arxiv, ACM Digital Library, IEEE Digital Library, Web of Science, DSpace, Fedora, ORE, PDF and Office metadata extractors)<br />
* Extending data-entry quality with more Name Authorities (e.g. Conferences) and other auto-completion (uncontrolled keywords). <br />
* Increase the value of holdings with a wider range of exporters (e.g. wordprocessors, spreadsheets, email, ZIP, MP3 for podcasting, RDF for the Semantic Web, DSpace, Fedora, ORE)<br />
<br />
== Repository-scale Quality Management: ==<br />
* duplicate detection<br />
* legacy metadata correction using name authorities and authoritative sources such as CrossRef<br />
* efficient batch checking and editing including one-step search and replace across the whole repository, e.g. replace "DeRoure" with "De Roure" in all Creator.Surname fields or batch editing - allowing a single metadata field to be efficiently checked and corrected in multiple eprints, e.g. a screen containing editable Journal Name fields from 100 separate eprints.<br />
<br />
== Administration Configuration Management ==<br />
User interface control panels for all repository configuration that are currently performed by editing configuration files.<br />
* Skins manager for branding.<br />
* Manager for object types (e.g. article, thesis) and metadata fields (e.g. "experimental technician" for a data set or "director" for a multimedia object.)<br />
* Multilingual phrase editor.<br />
* Deposit Workflow editor.<br />
* Process Workflow editor (see below)<br />
* Subject Hierachy editor (already exists)<br />
* Browse View and Bespoke Search editors<br />
* Plugin Manager to control non-core software.<br />
== Other Features ==<br />
* Process Workflow: as well as the deposit workflow, a process workflow will manage the various sequences of actions that an eprint can undergo from creation to final deposit (and beyond). This may include collaborative authoring, problem management, refereeing, copyright clearance, security clearance, IPR checking, metadata quality checks, e-journal and conference workflows. (EPrints currently allows, but does not manage, process workflows.)<br />
* Virtual Collections: an individual eprint may be represent a collection of other eprint items; mainly used for image collections, workshop proceedings or learning objects composed of teaching assets.<br />
* Interoperable Statistics: statistics on the download use of individual eprints, eprint collections (per user, per research group, per community) or whole repository. <br />
* Calendar view: calendar screen to track all embargo and license expirations, plus other planned events and timeouts.<br />
* Increased support for "eprints application profile" Dublin Core recommendations.<br />
* Web Services interface: currently in beta, awaiting debugging of the .NET SOAP interface.<br />
* Integration with Researcher's Desktop (the repository is just another Network Place via WebDAV).<br />
* API Toolkit - a service-level API that is available through scripting and REST interfaces</div>LesCarrhttps://wiki.eprints.org/w/index.php?title=Introduction&diff=5793Introduction2007-10-28T11:44:55Z<p>LesCarr: </p>
<hr />
<div>==What is EPrints?==<br />
EPrints 3.0 is generic repository building software developed by the University of Southampton. It is intended to create a highly configurable web-based repository.<br />
<br />
EPrints is often used as an open archive for research papers, and the default configuration reflects this, but it is also used for other things such as images, research data, audio archives - anything that can be stored digitally.<br />
<br />
The EPrints series began in early 2000 and is in use by over 200 sites!<br />
<br />
==Should I be installing EPrints 3, how much effort will it take?==<br />
<br />
Start by looking at http://demoprints3.eprints.org/ to get a feel for what the software does. <br />
<br />
You can get a vanilla install up and running quite easily, installation notes on the wiki should help you over any snags relating to your operating system. You'll need a UNIX-like machine (linux is good), and a root password is helpful.<br />
<br />
The task which will take longest is actually deciding what you want your repository to do (and not do). Many sites want to make significant customisations. EPrints creates a repository with a sensible default, but all our users want something slightly different.<br />
<br />
Installing and configuring the software isn't too hard, and we're working on admin tools to make it even easier.<br />
<br />
The time taken in running the archive day to day depends on your own policy. Do you want a very light touch on the data submitted or a formal review process on each item - that's up to you!<br />
<br />
==What will it run on?==<br />
<br />
We develop EPrints on Redhat Linux (both Fedora Core and Enterprise), but it is used on any number of Linux distributions, and other UNIX-like systems including OS-X. Thanks to support from Microsoft, it also runs on Windows Vista and XP.<br />
<br />
EPrints doesn't require any unusual hardware. It's slightly easier to run on a dedicated machine, but that's not essential, and should not affect performance.<br />
<br />
Don't forget to budget for a backup system, your data is valuable!</div>LesCarrhttps://wiki.eprints.org/w/index.php?title=History&diff=5792History2007-10-28T11:43:05Z<p>LesCarr: </p>
<hr />
<div>==A Brief History of EPrints==<br />
The EPrints project was created by Professor Stevan Harnad.<br />
<br />
<br />
; '''December 18 2006''' : GNU EPrints 3.0 RC-1 released.<br />
; '''December 5 2006''' : GNU EPrints 3.0 Beta-3 released.<br />
; '''November 14 2006''' : GNU EPrints 3.0 Beta-2 released.<br />
; '''October 26 2006''' : GNU EPrints 3.0 Beta-1 released.<br />
; '''July 25 2005''' : GNU EPrints 2.3.13 released.<br />
; '''May 24 2005''' : GNU EPrints 2.3.12 released.<br />
; '''March 8 2005''' : GNU EPrints 2.3.11 released.<br />
; '''March 2 2005''' : GNU EPrints 2.3.10 released.<br />
; '''February 17 2005''' : GNU EPrints 2.3.9 released.<br />
; '''February 16 2005''' : GNU EPrints 2.3.8 released.<br />
; '''November 25 2004''' : GNU EPrints 2.3.7 released.<br />
; '''August 9 2004''' : GNU EPrints 2.3.6 released.<br />
; '''August 6 2004''' : GNU EPrints 2.3.5 released.<br />
; '''July 6 2004''' : GNU EPrints 2.3.4 released.<br />
; '''March 4 2004''' : GNU EPrints 2.3.3 released.<br />
; '''February 25 2004''' : GNU EPrints 2.3.2 released.<br />
; '''February 5 2004''' : GNU EPrints 2.3.1 released.<br />
; '''January 12 2004''' : GNU EPrints 2.3.0 released.<br />
; '''October 31 2002''' : GNU EPrints 2.2 (Pumpkin) released. Added subject editors and GDOME support.<br />
; '''July 4 2002''' : GNU EPrints 2.1 (Pineapple) released. Added subscriptions and OAI 2.0 support.<br />
; '''July 1 2002''' : EPrints offically joins GNU Project.<br />
; '''Apr 17 2002''' : EPrints 2.0.1 (Tuna) released. Mostly bugfixes.<br />
; '''Feb 14 2002''' : EPrints 2.0 (Olive) released.<br />
; '''Jan 2002''' : EPrints 2 Alpha-2 (Pepperoni) released.<br />
; '''August 2001''' : EPrints 2 Alpha-1 (Anchovy) released.<br />
; '''June 2001''' : Mike Jewell joins EPrints, working primarily on installer software<br />
; '''January 2001''' : EPrints 1.1 released, contains OAI 1.0 support<br />
Work begins on EPrints 2<br />
; '''November 2000''' : EPrints 1.0 released, contains OAI 0.2 support<br />
Rob Tansley leaves the EPrints Project<br />
Christopher Gutteridge joins the EPrints Project<br />
; '''September 2000''' : EPrints beta-2 released<br />
; '''June 2000''' : EPrints beta-1 released<br />
Cogprints archive created. http://cogprints.soton.ac.uk/<br />
; '''April 2000''' : Rob Tansley begins work on EPrints<br />
; '''October 1999''' : A turnkey repository platform promised by Stevan Harnad & Les Carr at initial OAI (UPS) meeting in Santa Fe.<br />
<br />
{{todo}}</div>LesCarrhttps://wiki.eprints.org/w/index.php?title=Files/MapPlot_EPrints3_export_plugin.&diff=5791Files/MapPlot EPrints3 export plugin.2007-10-28T11:35:29Z<p>LesCarr: </p>
<hr />
<div>== MapPlot (aka Google Maps) Plugin ==<br />
<br />
[[Image:GoogleMaps.jpg]]<br />
<br />
This plugin produces the KML data to drive Google Maps from a list of eprint records. It assumes that each record has values for latitude and longitude (standard metadata in EPrints v3). Some derivation of this plugin (see the ECS "flightpath generator" which shows the notional path of travel across the globe for any researcher based on the locations of the conferences and workshops where they presented papers or posters) use a gazeteer to look up lat/long co-ordinates from named locations.<br />
<br />
''More details needed from DCT''</div>LesCarrhttps://wiki.eprints.org/w/index.php?title=File:GoogleMaps.jpg&diff=5790File:GoogleMaps.jpg2007-10-28T11:29:16Z<p>LesCarr: Small section of a screenshot of the results of the MapPlot (aka Google Maps) export plugin.</p>
<hr />
<div>Small section of a screenshot of the results of the MapPlot (aka Google Maps) export plugin.</div>LesCarr