All Versions
- DSpace 7.x (Current Release)
- DSpace 8.x (Unreleased)
- DSpace 6.x (EOL)
- DSpace 5.x (EOL)
- More Versions...
...
This is breaks down like this:
Date and time, milliseconds | 2002-11-11 08:11:32,903 |
Level (FATAL, WARN, INFO or DEBUG) | INFO |
Java class | org.dspace.app.webui.servlet.DSpaceServlet |
@ | |
User email or anonymous | anonymous |
: | |
Extra log info from context | session_id=BD84E7C194C2CF4BD0EC3A6CAD0142BB |
: | |
Action | view_item |
: | |
Extra info | handle=1721.1/1686 |
The above format allows the logs to be easily parsed and analyzed. The [dspace]/bin/log-reporter
script is a simple tool for analyzing logs. Try:
...
Some examples to illustrate this are shown below:
| Will change storage | ||
| Will not change storage (context aborted) | ||
| The new name will not be stored since update was not invoked | ||
| The bitstream will be included in the bundle, since update doesn't need to be called |
Instantiating some content objects also causes other content objects to be loaded into memory.
...
Below is the specific syntax that DSpace expects various fields to adhere to:
Element | Qualifier | Syntax | Helper Class |
date | Any or unqualified | ISO 8601 in the UTC time zone, with either year, month, day, or second precision. Examples:_2000 2002-10 2002-08-14 1999-01-01T14:35:23Z _ | DCDate |
contributor | Any or unqualified | In general last name, then a comma, then first names, then any additional information like "Jr.". If the contributor is an organization, then simply the name. Examples:_Doe, John Smith, John Jr. van Dyke, Dick Massachusetts Institute of Technology _ | DCPersonName |
language | iso | A two letter code taken ISO 639, followed optionally by a two letter country code taken from ISO 3166. Examples:_en fr en_US _ | DCLanguage |
relation | ispartofseries | The series name, following by a semicolon followed by the number in that series. Alternatively, just free text._MIT-TR; 1234 My Report Series; ABC-1234 NS1234 _ | DCSeriesNumber |
...
The primary classes are:
org.dspace.content.WorkspaceItem | contains an Item before it enters a workflow |
org.dspace.workflow.WorkflowItem | contains an Item while in a workflow |
org.dspace.workflow.WorkflowService | responds to events, manages the WorkflowItem states. There are two implementations, the traditional, default workflow (described below) and Configurable Workflow. |
org.dspace.content.Collection | contains List of defined workflow steps |
org.dspace.eperson.Group | people who can perform workflow tasks are defined in EPerson Groups |
org.dspace.core.Email | used to email messages to Group members and submitters |
The default workflow system models the states of an Item in a state machine with 5 states (SUBMIT, STEP_1, STEP_2, STEP_3, ARCHIVE.) These are the three optional steps where the item can be viewed and corrected by different groups of people. Actually, it's more like 8 states, with STEP_1_POOL, STEP_2_POOL, and STEP_3_POOL. These pooled states are when items are waiting to enter the primary states. Optionally, you can also choose to enable the enhanced, Configurable Workflow, if you wish to have more control over your workflow steps/states. (Note: the remainder of this description relates to the traditional, default workflow. For more information on the Configurable Workflow option, visit Configurable Workflow.)
...
The primary classes are:
org.dspace.authorize.AuthorizeService | does all authorization, checking policies against Groups |
org.dspace.authorize.ResourcePolicy | defines all allowable actions for an object |
org.dspace.eperson.Group | all policies are defined in terms of EPerson Groups |
The authorization system is based on the classic 'police state' model of security; no action is allowed unless it is expressed in a policy. The policies are attached to resources (hence the name ResourcePolicy,) and detail who can perform that action. The resource can be any of the DSpace object types, listed in org.dspace.core.Constants (BITSTREAM, ITEM, COLLECTION, etc.) The 'who' is made up of EPerson groups. The actions are also in Constants.java (READ, WRITE, ADD, etc.) The only non-obvious actions are ADD and REMOVE, which are authorizations for container objects. To be able to create an Item, you must have ADD permission in a Collection, which contains Items. (Communities, Collections, Items, and Bundles are all container objects.)
...
DSpace is able to support OpenSearch. For those not acquainted with the standard, a very brief introduction, with emphasis on what possibilities it holds for current use and future development.
...
How Can It Be Used
Flexible, interesting RSS FeedsBecause Feeds. Because one of the formats that OpenSearch specifies for its results is RSS (or Atom), you can turn any search query into an RSS feed. So if there are keywords highly discriminative of content in a collection or repository, these can be turned into a URL that a feed reader can subscribe to. Taken to the extreme, one could take any search a user makes, and dynamically compose an RSS feed URL for it in the page of returned results. To see an example, if you have a DSpace with OpenSearch enabled, try:
Code Block |
---|
http://dspace.mysite.edu/open-search/?query=<your query> |
The default format returned is Atom 1.0, so you should see an Atom document containing your search results.
You can extend the syntax with a few other parameters, as follows:
Parameter | Values |
---|---|
format | atom, rss, html |
scope | handle of a collection or community to restrict the search to |
rpp | number indicating the number of results per page (i.e. per request) |
start | number of page to start with (if paginating results) |
sort_by | number indicating sorting criteria (same as DSpace advanced search values |
Multiple parameters may be specified on the query string, using the "&" character as the delimiter, e.g.:
Code Block |
---|
http://dspace.mysite.edu/open-search/?query=<your query>&format=rss&scope=123456789/1 |
Configuration is through the dspace.cfg
file. See OpenSearch Support for more details.
...