hazza/DSpace
1
0
Fork 0
mirror of https://github.com/DSpace/DSpace.git synced 2025-10-07 01:54:22 +00:00
Code Issues Packages Projects Releases Wiki Activity

Final release for 1.7

Browse Source 
git-svn-id: http://scm.dspace.org/svn/repo/dspace/trunk@5974 9c30dcfa-912a-0410-8fc2-9e0234be79fd
This commit is contained in:
Jeffrey Trimble
2010-12-16 16:58:13 +00:00
parent 6cf82b0e86
commit eeeec6bd5b
1 changed files with 79 additions and 24 deletions
Download Patch File Download Diff File Expand all files Collapse all files

103
dspace/docs/html/Functional Overview.html
View File

@@ -16,19 +16,71 @@
</span>
</div>
<div class="pagesubheading">
This page last changed on Nov 06, 2010 by <font color="#0050B2">jtrimble</font>.
This page last changed on Dec 15, 2010 by <font color="#0050B2">mwood</font>.
</div>
<h1><a name="FunctionalOverview-DSpaceSystemDocumentation%3AFunctionalOverview"></a>DSpace System Documentation: Functional Overview</h1>
<p>The following sections describe the various functional aspects of the DSpace system.</p>
<style type='text/css'>/*<![CDATA[*/
div.rbtoc1292450544145 {margin-left: 0px;padding: 0px;}
div.rbtoc1292450544145 ul {list-style: none;margin-left: 0px;}
div.rbtoc1292450544145 li {margin-left: 0px;padding-left: 0px;}
/*]]>*/</style><div class='rbtoc1292450544145'>
<ul>
<li><span class='TOCOutline'>1</span> <a href='#FunctionalOverview-DataModel'>Data Model</a></li>
<li><span class='TOCOutline'>2</span> <a href='#FunctionalOverview-PluginManager'>Plugin Manager</a></li>
<li><span class='TOCOutline'>3</span> <a href='#FunctionalOverview-Metadata'>Metadata</a></li>
<li><span class='TOCOutline'>4</span> <a href='#FunctionalOverview-PackagerPlugins'>Packager Plugins</a></li>
<li><span class='TOCOutline'>5</span> <a href='#FunctionalOverview-CrosswalkPlugins'>Crosswalk Plugins</a></li>
<li><span class='TOCOutline'>6</span> <a href='#FunctionalOverview-EPeopleandGroups'>E-People and Groups</a></li>
<ul>
<li><span class='TOCOutline'>6.1</span> <a href='#FunctionalOverview-EPerson'>E-Person</a></li>
<li><span class='TOCOutline'>6.2</span> <a href='#FunctionalOverview-Groups'>Groups</a></li>
</ul>
<li><span class='TOCOutline'>7</span> <a href='#FunctionalOverview-Authentication'>Authentication </a></li>
<li><span class='TOCOutline'>8</span> <a href='#FunctionalOverview-Authorization'>Authorization</a></li>
<li><span class='TOCOutline'>9</span> <a href='#FunctionalOverview-IngestProcessandWorkflow'>Ingest Process and Workflow</a></li>
<ul>
<li><span class='TOCOutline'>9.1</span> <a href='#FunctionalOverview-WorkflowSteps'>Workflow Steps</a></li>
</ul>
<li><span class='TOCOutline'>10</span> <a href='#FunctionalOverview-SupervisionandCollaboration'>Supervision and Collaboration</a></li>
<li><span class='TOCOutline'>11</span> <a href='#FunctionalOverview-Handles'>Handles</a></li>
<li><span class='TOCOutline'>12</span> <a href='#FunctionalOverview-Bitstream%27Persistent%27Identifiers'>Bitstream 'Persistent' Identifiers</a></li>
<li><span class='TOCOutline'>13</span> <a href='#FunctionalOverview-StorageResourceBroker%28SRB%29Support'>Storage Resource Broker (SRB) Support</a></li>
<li><span class='TOCOutline'>14</span> <a href='#FunctionalOverview-SearchandBrowse'>Search and Browse</a></li>
<li><span class='TOCOutline'>15</span> <a href='#FunctionalOverview-HTMLSupport'>HTML Support</a></li>
<li><span class='TOCOutline'>16</span> <a href='#FunctionalOverview-OAISupport'>OAI Support</a></li>
<li><span class='TOCOutline'>17</span> <a href='#FunctionalOverview-OpenURLSupport'>OpenURL Support</a></li>
<li><span class='TOCOutline'>18</span> <a href='#FunctionalOverview-CreativeCommonsSupport'>Creative Commons Support</a></li>
<li><span class='TOCOutline'>19</span> <a href='#FunctionalOverview-Subscriptions'>Subscriptions</a></li>
<li><span class='TOCOutline'>20</span> <a href='#FunctionalOverview-ImportandExport'>Import and Export</a></li>
<li><span class='TOCOutline'>21</span> <a href='#FunctionalOverview-Registration'>Registration</a></li>
<li><span class='TOCOutline'>22</span> <a href='#FunctionalOverview-Statistics'>Statistics</a></li>
<ul>
<li><span class='TOCOutline'>22.1</span> <a href='#FunctionalOverview-SystemStatistics'>System Statistics</a></li>
<li><span class='TOCOutline'>22.2</span> <a href='#FunctionalOverview-Item%2CCollectionandCommunityUsageStatistics'>Item, Collection and Community Usage Statistics</a></li>
</ul>
<li><span class='TOCOutline'>23</span> <a href='#FunctionalOverview-ChecksumChecker'>Checksum Checker</a></li>
<li><span class='TOCOutline'>24</span> <a href='#FunctionalOverview-UsageInstrumentation'>Usage Instrumentation</a></li>
<li><span class='TOCOutline'>25</span> <a href='#FunctionalOverview-ChoiceManagementandAuthorityControl'>Choice Management and Authority Control</a></li>
<ul>
<li><span class='TOCOutline'>25.1</span> <a href='#FunctionalOverview-IntroductionandMotivation'>Introduction and Motivation</a></li>
<ul>
<li><span class='TOCOutline'>25.1.1</span> <a href='#FunctionalOverview-Definitions'>Definitions</a></li>
<li><span class='TOCOutline'>25.1.2</span> <a href='#FunctionalOverview-AboutAuthorityControl'>About Authority Control</a></li>
<li><span class='TOCOutline'>25.1.3</span> <a href='#FunctionalOverview-SomeTerminology'>Some Terminology</a></li>
</ul>
</ul>
</ul></div>
<h2><a name="FunctionalOverview-DataModel"></a>Data Model</h2>
<p><span class="image-wrap" style=""><img src="attachments/22022823/21954865.gif" style="border: 0px solid black"/></span></p>
<p>Data Model Diagram</p>
<p><b>Data Model Diagram</b></p>
<p>The way data is organized in DSpace is intended to reflect the structure of the organization using the DSpace system. Each DSpace site is divided into <em>communities</em>, which can be further divided into <em>sub-communities</em> reflecting the typical university structure of college, departement, research center, or laboratory.</p>
@@ -45,11 +97,12 @@
<li><em>THUMBNAILS</em> &#8211; thumbnails of any image bitstreams</li>
<li><em>TEXT</em> &#8211; extracted full-text from bitstreams in ORIGINAL, for indexing</li>
<li><em>LICENSE</em> &#8211; contains the deposit license that the submitter granted the host organization; in other words, specifies the rights that the hosting organization have</li>
<li><em>CC_LICENSE</em> &#8211; contains the distribution license, if any (a <a href="http://www.creativecommons.org" title="Creative Commons">Creative Commons</a> license) associated with the item. This license specifies what end users downloading the content can do with the content<br/>
Each bitstream is associated with one <em>Bitstream Format</em>. Because preservation services may be an important aspect of the DSpace service, it is important to capture the specific formats of files that users submit. In DSpace, a bitstream format is a unique and consistent way to refer to a particular file format. An integral part of a bitstream format is an either implicit or explicit notion of how material in that format can be interpreted. For example, the interpretation for bitstreams encoded in the JPEG standard for still image compression is defined explicitly in the Standard ISO/IEC 10918-1. The interpretation of bitstreams in Microsoft Word 2000 format is defined implicitly, through reference to the Microsoft Word 2000 application. Bitstream formats can be more specific than MIME types or file suffixes. For example, <em>application/ms-word</em> and <em>.doc</em> span multiple versions of the Microsoft Word application, each of which produces bitstreams with presumably different characteristics.</li>
<li><em>CC_LICENSE</em> &#8211; contains the distribution license, if any (a <a href="http://www.creativecommons.org" title="Creative Commons">Creative Commons</a> license) associated with the item. This license specifies what end users downloading the content can do with the content</li>
</ul>
<p>Each bitstream is associated with one <em>Bitstream Format</em>. Because preservation services may be an important aspect of the DSpace service, it is important to capture the specific formats of files that users submit. In DSpace, a bitstream format is a unique and consistent way to refer to a particular file format. An integral part of a bitstream format is an either implicit or explicit notion of how material in that format can be interpreted. For example, the interpretation for bitstreams encoded in the JPEG standard for still image compression is defined explicitly in the Standard ISO/IEC 10918-1. The interpretation of bitstreams in Microsoft Word 2000 format is defined implicitly, through reference to the Microsoft Word 2000 application. Bitstream formats can be more specific than MIME types or file suffixes. For example, <em>application/ms-word</em> and <em>.doc</em> span multiple versions of the Microsoft Word application, each of which produces bitstreams with presumably different characteristics.</p>
<p>Each bitstream format additionally has a <em>support level</em>, indicating how well the hosting institution is likely to be able to preserve content in the format in the future. There are three possible support levels that bitstream formats may be assigned by the hosting institution. The host institution should determine the exact meaning of each support level, after careful consideration of costs and requirements. MIT Libraries' interpretation is shown below:</p>
<div class='table-wrap'>
<table class='confluenceTable'><tbody>
@@ -113,7 +166,7 @@ Each bitstream is associated with one <em>Bitstream Format</em>. Because preserv
<p>A plugin is defined by a Java interface. The consumer of a plugin asks for its plugin by interface. A Plugin is an instance of any class that implements the plugin interface. It is interchangeable with other implementations, so that any of them may be "plugged in".</p>
<p>The mediafilter is a simple example of a plugin implementation. Refer to the Business Logic Layer for more details on Plugins.</p>
<p>The mediafilter is a simple example of a plugin implementation. Refer to the <a href="Business Logic Layer.html" title="Business Logic Layer">Business Logic Layer</a> for more details on Plugins.</p>
<h2><a name="FunctionalOverview-Metadata"></a>Metadata</h2>
@@ -121,9 +174,9 @@ Each bitstream is associated with one <em>Bitstream Format</em>. Because preserv
<p>Broadly speaking, DSpace holds three sorts of metadata about archived content:</p>
<ul>
<li><b>Descriptive Metadata</b>: DSpace can support multiple flat metadata schemas for describing an item.A qualified Dublin Core metadata schema loosely based on the <a href="http://www.dublincore.org/documents/library-application-profile/" title="Library Application Profile">Library Application Profile</a> set of elements and qualifiers is provided by default. The <a href="http://dspace.org/technology/metadata.html" title="set of elements and qualifiers used by MIT Libraries">set of elements and qualifiers used by MIT Libraries</a> comes pre-configured with the DSpace source code. However, you can configure multiple schemas and select metadata fields from a mix of configured schemas to describe your items.Other descriptive metadata about items (e.g. metadata described in a hierarchical schema) may be held in serialized bitstreams. <em>Communities</em> and <em>collections</em> have some simple descriptive metadata (a name, and some descriptive prose), held in the DBMS.</li>
<li><b>Administrative Metadata</b>: This includes preservation metadata, provenance and authorization policy data. Most of this is held within DSpace's relation DBMS schema. Provenance metadata (prose) is stored in Dublin Core records. Additionally, some other administrative metadata (for example, bitstream byte sizes and MIME types) is replicated in Dublin Core records so that it is easily accessible outside of DSpace.</li>
<li><b>Structural Metadata</b>: This includes information about how to present an item, or bitstreams within an item, to an end-user, and the relationships between constituent parts of the item. As an example, consider a thesis consisting of a number of TIFF images, each depicting a single page of the thesis. Structural metadata would include the fact that each image is a single page, and the ordering of the TIFF images/pages. Structural metadata in DSpace is currently fairly basic; within an item, bitstreams can be arranged into separate bundles as described above. A bundle may also optionally have a <em>primary bitstream</em>. This is currently used by the HTML support to indicate which bitstream in the bundle is the first HTML file to send to a browser.In addition to some basic technical metadata, bitstreams also have a 'sequence ID' that uniquely identifies it within an item. This is used to produce a 'persistent' bitstream identifier for each bitstream.Additional structural metadata can be stored in serialized bitstreams, but DSpace does not currently understand this natively.</li>
<li><b>Descriptive Metadata</b>: DSpace can support multiple flat metadata schemas for describing an item. A qualified Dublin Core metadata schema loosely based on the <a href="http://www.dublincore.org/documents/library-application-profile/" title="Library Application Profile">Library Application Profile</a> set of elements and qualifiers is provided by default. The <a href="http://dspace.org/technology/metadata.html" title="set of elements and qualifiers used by MIT Libraries">set of elements and qualifiers used by MIT Libraries</a> comes pre-configured with the DSpace source code. However, you can configure multiple schemas and select metadata fields from a mix of configured schemas to describe your items. Other descriptive metadata about items (e.g. metadata described in a hierarchical schema) may be held in serialized bitstreams. <em>Communities</em> and <em>collections</em> have some simple descriptive metadata (a name, and some descriptive prose), held in the DBMS.</li>
<li><b>Administrative Metadata</b>: This includes preservation metadata, provenance and authorization policy data. Most of this is held within DSpace's relational DBMS schema. Provenance metadata (prose) is stored in Dublin Core records. Additionally, some other administrative metadata (for example, bitstream byte sizes and MIME types) is replicated in Dublin Core records so that it is easily accessible outside of DSpace.</li>
<li><b>Structural Metadata</b>: This includes information about how to present an item, or bitstreams within an item, to an end-user, and the relationships between constituent parts of the item. As an example, consider a thesis consisting of a number of TIFF images, each depicting a single page of the thesis. Structural metadata would include the fact that each image is a single page, and the ordering of the TIFF images/pages. Structural metadata in DSpace is currently fairly basic; within an item, bitstreams can be arranged into separate bundles as described above. A bundle may also optionally have a <em>primary bitstream</em>. This is currently used by the HTML support to indicate which bitstream in the bundle is the first HTML file to send to a browser. In addition to some basic technical metadata, a bitstream also has a 'sequence ID' that uniquely identifies it within an item. This is used to produce a 'persistent' bitstream identifier for each bitstream. Additional structural metadata can be stored in serialized bitstreams, but DSpace does not currently understand this natively.</li>
</ul>
@@ -159,7 +212,7 @@ Each bitstream is associated with one <em>Bitstream Format</em>. Because preserv
<h3><a name="FunctionalOverview-EPerson"></a>E-Person</h3>
<p>DSpace hold the following information about each e-person:</p>
<p>DSpace holds the following information about each e-person:</p>
<ul>
<li>E-mail address</li>
@@ -168,7 +221,7 @@ Each bitstream is associated with one <em>Bitstream Format</em>. Because preserv
<li>A password (encrypted), if appropriate</li>
<li>A list of collections for which the e-person wishes to be notified of new items</li>
<li>Whether the e-person 'self-registered' with the system; that is, whether the system created the e-person record automatically as a result of the end-user independently registering with the system, as opposed to the e-person record being generated from the institution's personnel database, for example.</li>
<li>The network ID for the corresponding LDAP record</li>
<li>The network ID for the corresponding LDAP record, if LDAP authentication is used for this E-Person.</li>
</ul>
@@ -182,9 +235,9 @@ Each bitstream is associated with one <em>Bitstream Format</em>. Because preserv
<h2><a name="FunctionalOverview-Authentication"></a>Authentication</h2>
<h2><a name="FunctionalOverview-Authentication"></a>Authentication<a name="FunctionalOverview-Authentication"></a></h2>
<p><em>Authentication</em> is when an application session positively identifies itself as belonging to an E-Person and/or Group. In DSpace 1.4, it is implemented by a mechanism called <em>Stackable Authentication</em>: the DSpace configuration declares a "stack" of authentication methods. An application (like the Web UI) calls on the Authentication Manager, which tries each of these methods in turn to identify the E-Person to which the session belongs, as well as any extra Groups. The E-Person authentication methods are tried in turn until one succeeds. Every authenticator in the stack is given a chance to assign extra Groups. This mechanism offers the following advantages:</p>
<p><em>Authentication</em> is when an application session positively identifies itself as belonging to an E-Person and/or Group. In DSpace 1.4 and later, it is implemented by a mechanism called <em>Stackable Authentication</em>: the DSpace configuration declares a "stack" of authentication methods. An application (like the Web UI) calls on the Authentication Manager, which tries each of these methods in turn to identify the E-Person to which the session belongs, as well as any extra Groups. The E-Person authentication methods are tried in turn until one succeeds. Every authenticator in the stack is given a chance to assign extra Groups. This mechanism offers the following advantages:</p>
<ul>
<li>Separates authentication from the Web user interface so the same authentication methods are used for other applications such as non-interactive Web Services</li>
@@ -195,7 +248,7 @@ Each bitstream is associated with one <em>Bitstream Format</em>. Because preserv
<h2><a name="FunctionalOverview-Authorization"></a>Authorization</h2>
<p>DSpace's authorization system is based on associating actions with objects and the lists of EPeople who can perform them. The associations are called Resource Policies, and the lists of EPeople are called Groups. There are two special groups: 'Administrators', who can do anything in a site, and 'Anonymous', which is a list that contains all users. Assigning a policy for an action on an object to anonymous means giving everyone permission to do that action. (For example, most objects in DSpace sites have a policy of 'anonymous' READ.) Permissions must be explicit - lack of an explicit permission results in the default policy of 'deny'. Permissions also do not 'commute'; for example, if an e-person has READ permission on an item, they might not necessarily have READ permission on the bundles and bitstreams in that item. Currently Collections, Communities and Items are discoverable in the browse and search systems regardless of READ authorization.</p>
<p>DSpace's authorization system is based on associating actions with objects and the lists of EPeople who can perform them. The associations are called Resource Policies, and the lists of EPeople are called Groups. There are two built-in groups: 'Administrators', who can do anything in a site, and 'Anonymous', which is a list that contains all users. Assigning a policy for an action on an object to anonymous means giving everyone permission to do that action. (For example, most objects in DSpace sites have a policy of 'anonymous' READ.) Permissions must be explicit - lack of an explicit permission results in the default policy of 'deny'. Permissions also do not 'commute'; for example, if an e-person has READ permission on an item, they might not necessarily have READ permission on the bundles and bitstreams in that item. Currently Collections, Communities and Items are discoverable in the browse and search systems regardless of READ authorization.</p>
<p>The following actions are possible:</p>
@@ -305,7 +358,7 @@ Each bitstream is associated with one <em>Bitstream Format</em>. Because preserv
<p>In other words, the sequence is this: The collection receives a submission. If the collection has a group assigned for workflow step 1, that step is invoked, and the group is notified. Otherwise, workflow step 1 is skipped. Likewise, workflow steps 2 and 3 are performed if and only if the collection has a group assigned to those steps.</p>
<p>When a step is invoked, the task of performing that workflow step put in the 'task pool' of the associated group. One member of that group takes the task from the pool, and it is then removed from the task pool, to avoid the situation where several people in the group may be performing the same task without realizing it.</p>
<p>When a step is invoked, the submission is put into the 'task pool' of the step's associated group. One member of that group takes the task from the pool, and it is then removed from the task pool, to avoid the situation where several people in the group may be performing the same task without realizing it.</p>
<p>The member of the group who has taken the task from the pool may then perform one of three actions:</p>
<div class='table-wrap'>
@@ -344,7 +397,7 @@ Each bitstream is associated with one <em>Bitstream Format</em>. Because preserv
<h2><a name="FunctionalOverview-SupervisionandCollaboration"></a>Supervision and Collaboration</h2>
<p>In order to facilitate, as a primary objective, the opportunity for thesis authors to be supervised in the preparation of their e-thesis, a supervision order system exists to bind groups of other users (thesis supervisors) to an item in someone's pre-submission workspace. The bound group can have system policies associated with it that allow different levels of interaction with the student's item; a small set of default policy groups are provided:</p>
<p>In order to facilitate, as a primary objective, the opportunity for thesis authors to be supervised in the preparation of their e-theses, a supervision order system exists to bind groups of other users (thesis supervisors) to an item in someone's pre-submission workspace. The bound group can have system policies associated with it that allow different levels of interaction with the student's item; a small set of default policy groups are provided:</p>
<ul>
<li>Full editorial control</li>
@@ -359,9 +412,9 @@ Once the default set has been applied, a system administrator may modify them as
<h2><a name="FunctionalOverview-Handles"></a>Handles</h2>
<p>Researchers require a stable point of reference for their works. The simple evolution from sharing of citations to emailing of URLs broke when Web users learned that sites can disappear or be reconfigured without notice, and that their bookmark files containing critical links to research results couldn't be trusted long term. To help solve this problem, a core DSpace feature is the creation of persistent identifier for every item, collection and community stored in DSpace. To persist identifier, DSpace requires a storage&#45; and location&#45; independent mechanism for creating and maintaining identifiers. DSpace uses the <a href="http://www.handle.net/" title="CNRI Handle System">CNRI Handle System</a> for creating these identifiers. The rest of this section assumes a basic familiarity with the Handle system.</p>
<p>Researchers require a stable point of reference for their works. The simple evolution from sharing of citations to emailing of URLs broke when Web users learned that sites can disappear or be reconfigured without notice, and that their bookmark files containing critical links to research results couldn't be trusted in the long term. To help solve this problem, a core DSpace feature is the creation of a persistent identifier for every item, collection and community stored in DSpace. To persist identifiers, DSpace requires a storage&#45; and location&#45; independent mechanism for creating and maintaining identifiers. DSpace uses the <a href="http://www.handle.net/" title="CNRI Handle System">CNRI Handle System</a> for creating these identifiers. The rest of this section assumes a basic familiarity with the Handle system.</p>
<p>DSpace uses Handles primarily as a means of assigning globally unique identifiers to objects. Each site running DSpace needs to obtain a Handle 'prefix' from CNRI, so we know that if we create identifiers with that prefix, they won't clash with identifiers created elsewhere.</p>
<p>DSpace uses Handles primarily as a means of assigning globally unique identifiers to objects. Each site running DSpace needs to obtain a unique Handle 'prefix' from CNRI, so we know that if we create identifiers with that prefix, they won't clash with identifiers created elsewhere.</p>
<p>Presently, Handles are assigned to communities, collections, and items. Bundles and bitstreams are not assigned Handles, since over time, the way in which an item is encoded as bits may change, in order to allow access with future technologies and devices. Older versions may be moved to off-line storage as a new standard becomes de facto. Since it's usually the <em>item</em> that is being preserved, rather than the particular bit encoding, it only makes sense to persistently identify and allow access to the item, and allow users to access the appropriate bit encoding from there.</p>
@@ -371,8 +424,9 @@ Once the default set has been applied, a system administrator may modify them as
<p>Handles can be written in two forms:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">hdl:1721.123/4567
http:<span class="code-comment">//hdl.handle.net/1721.123/4567</span>
<pre class="code-java">
hdl:1721.123/4567
http:<span class="code-comment">//hdl.handle.net/1721.123/4567</span>
</pre>
</div></div>
<p>The above represent the same Handle. The first is possibly more convenient to use only as an identifier; however, by using the second form, any Web browser becomes capable of resolving Handles. An end-user need only access this form of the Handle as they would any other URL. It is possible to enable some browsers to resolve the first form of Handle as if they were standard URLs using <a href="http://www.handle.net/resolver/index.html" title="CNRI's Handle Resolver plug-in">CNRI's Handle Resolver plug-in</a>, but since the first form can always be simply derived from the second, DSpace displays Handles in the second form, so that it is more useful for end-users.</p>
@@ -390,7 +444,8 @@ http:<span class="code-comment">//hdl.handle.net/1721.123/4567</span>
<p>For example:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">https:<span class="code-comment">//dspace.myu.edu/bitstream/123.456/789/24/foo.html</span>
<pre class="code-java">
https:<span class="code-comment">//dspace.myu.edu/bitstream/123.456/789/24/foo.html</span>
</pre>
</div></div>
<p>The above refers to the bitstream with sequence ID 24 in the item with the Handle <em>hdl:123.456/789</em>. The <em>foo.html</em> is really just there as a hint to browsers: Although DSpace will provide the appropriate MIME type, some browsers only function correctly if the file has an expected extension.</p>
@@ -438,10 +493,10 @@ Dealing with these issues is the topic of much active research. Currently, DSpac
<li><em>image/foo.gif</em> is OK</li>
<li><em>../index.html</em> is only OK in a file that is at least a directory deep in the HTML document/site hierarchy</li>
<li><em>/stylesheet.css</em> is not OK (the link will break)</li>
<li>_<a href="http://somedomain.com/content.html_">http://somedomain.com/content.html&#95;</a> is not OK (the link will continue to link to the external site which may change or disappear)</li>
<li><em><a href="http://somedomain.com/content.html">http://somedomain.com/content.html</a></em> is not OK (the link will continue to link to the external site which may change or disappear)</li>
</ul>
</li>
<li>Any 'absolute links' (e.g. _<a href="http://somedomain.com/content.html_">http://somedomain.com/content.html&#95;</a>) are stored 'as is', and will continue to link to the external content (as opposed to relative links, which will link to the copy of the content stored in DSpace.) Thus, over time, the content refered to by the absolute link may change or disappear.</li>
<li>Any 'absolute links' (e.g. <em><a href="http://somedomain.com/content.html">http://somedomain.com/content.html</a></em>) are stored 'as is', and will continue to link to the external content (as opposed to relative links, which will link to the copy of the content stored in DSpace.) Thus, over time, the content refered to by the absolute link may change or disappear.</li>
</ul>
@@ -519,7 +574,7 @@ The results of statistical analysis can be presented on a by-month and an in-tot
<h2><a name="FunctionalOverview-Item%2CCollectionandCommunityUsageStatistics"></a>Item, Collection and Community Usage Statistics</h2>
<h3><a name="FunctionalOverview-Item%2CCollectionandCommunityUsageStatistics"></a>Item, Collection and Community Usage Statistics</h3>
<p>Usage statistics can be retrieved from individual item, collection and community pages. These Usage Statistics pages show:</p>
@@ -654,7 +709,7 @@ Authority control is different from the controlled vocabulary of keywords alread
<td height="12" background="https://wiki.duraspace.org/images/border/border_bottom.gif"><img src="images/border/spacer.gif" width="1" height="1" border="0"/></td>
</tr>
<tr>
<td align="center"><font color="grey">Document generated by Confluence on Nov 06, 2010 19:27</font></td>
<td align="center"><font color="grey">Document generated by Confluence on Dec 16, 2010 16:47</font></td>
</tr>
</table>
</body>