Looking forward, there have been glimpses of repository interfaces that might play a role for in-progress file deposit and management, where in-progress means as the work is written and created. Runner-up in the Developer Challenge at Open Repositories 2009 was a prototype called FedoraFS by Rebecca Koesar, who exposed Fedora as a desktop filestore using Fuse: “while only a command line prototype at this point the ease of overlaying a Graphical User Interface with file-folder icons is all but a done deal.”

At Open Repositories 2011 the same Developer Challenge was won by Repository as a Service (RaaS) based on the idea that with standard repository interfaces, to get data in and out the repository becomes a commodity that can be swapped. The entry demonstrated an Android mobile app that used SWORD to deposit photos into both DSpace and EPrints. A common interface was provided to access the items in the repository. Both EPrints and DSpace provided identical experiences because of the common interfaces.

Which brings us to SWORD (Simple Web service Offering Repository Deposit). The idea that repository deposit might be abstracted from repository software began in practice with SWORD in 2007. At the core of its proposition was, given the plethora of repositories and user interfaces, that users could choose a single interface for deposit in multiple repositories. It may thus be the single-most important development in repository user interfaces since the original repository softwares, but its impact is still more in principle than practice in terms of alternative interfaces that have attracted wide use. This may be due to a lack of interfaces, or lack of uptake, but it has not limited the number of potential use cases, as shown by Lewis, et al. (2012).

Or it could be due to limited functionality, which will be fixed by SWORD version 2, released in December 2011. We have written on this blog before about the key developments in SWORD v2, taking it from a ‘fire and forget’ deposit method that is limited in terms of what authors can do with their content after depositing in a repository, to a model where authors retain more control over their content and items can be created, updated, replaced, or deleted (CRUD) in the repository. SWORD v2 is the basis of DepositMO’s vision for in-progress deposit.

SWORD builds on AtomPub, the Atom Publishing Protocol. Many may be more familiar with Atom in the form of an RSS-like syndication protocol; AtomPub is the flip side, about pushing content into a dissemination resource rather than its receipt by readers (Snell 2006). SWORD 2.0 continues to build on AtomPub through the inclusion of the CRUD operations of AtomPub to enable the following kinds of interactions, described by the SWORD 2.0 Profile:

1. Clients may create resources by sending compound resources, such as archive files (tar, zip).
2. Workflows which may or may not include manual stages before deposited resources become available as web resources, are acknowledged and supported
3. Clients may update or delete the compound resources or associated metadata

In the progression to profile 2.0, SWORD becomes more explicitly a deposit lifecycle standard: “Most of the enhancements in SWORD 2.0 are around closing the deposit loop. This deposit process is only a portion of the full content lifecycle and does not attempt to provide support for collaborative or distributed authoring environments or policy management; it is focused entirely on the process of moving content from one location to another.”

During consultation over the new profile the adoption of more powerful publication protocols was advocated, but these have not so far been included, leaving the profile specification to note: “For standards to integrate detailed content management operations it is recommended to look at OASIS CMIS (Organization for the Advancement of Structured Information Standards – Content Management Interoperability Services), or the Google Documents (GData) List API.” It was this aim of bringing more powerful content management features to repositories that led to the DepositMO extensions using the platform and flexibility that SWORDv2 created with reference to these other publication protocols.

A similar publishing protocol connecting content-producing tools and repositories for learning resources and metadata is the Simple Publishing Interface (SPI), which also uses AtomPub. The main difference between SWORD and SPI, according to Ternier, et al. (2010), is in the submission of metadata. “In SWORD, metadata is available in a package and thus submitted to the repository as a part of the resource. In contrast, the SPI model makes a clear distinction between metadata and content at submission time. The rationale for this strict separation comes from the SPI application domain. Where SWORD is primarily concerned with depositing data, SPI is also intended for application scenarios where only metadata is considered.”

We have presented in this series of three posts a sweeping review of practical work on the usability of repository interfaces, most notably the deposit interface. Broadly these studies have found little wrong with current ‘fire and forget’ deposit interfaces while in some cases making adjustments for the structure and volume of metadata collected at deposit. Detailed and critical evidence on whether deposit interfaces make a substantive difference to levels of deposit, however, is hard to find. If we are to move towards more sophisticated Web 2.0-like interfaces for repositories, providing more interaction with authors using new protocols such as SWORD v2 to capture work at an earlier stage of creation, then users and usability will have to become much more central to repository testing.

This concludes our three-part review of repository usability focussing on user deposit. The next post will start to report the results of user testing of the repository deposit tools developed in DepositMO.

If the deposit projects described in part 1 of this review were more concerned with metadata than the usability of repository interfaces, it may be because, unlike the Southampton projects that have close links with the development of EPrints, most of these projects do not have the keys to develop one of the main repository softwares. In response to its repository user survey, however, University of Rochester went further: it built its own repository software, known as ‘IR+’. This began with studies of faculty work practices and “resulted in modifications to the University of Rochester’s implementation of the DSpace code to better align the repository with the existing work practices of faculty.” (Foster and Gibbons 2005)

This included the introduction of Researcher and Researcher Tools pages. Further studies of work practices, of graduate students, followed at Rochester (Randall, et al. 2008). “The results of our work-practice study pointed to several enhancements, including personal showcase pages for faculty members and researchers, download statistics, and a checksum tool to support long-term preservation of files. We added these features to our IR and observed an increase in repository use as a result, but it was not a dramatic increase.” Note that the interest here was on authoring and information management practices used by the students: “Specifically, we wanted to build an authoring environment on our IR platform, while also integrating traditional and digital library functions and services. The end product is to be one interface for a wide range of research, writing, and archiving activities.”

The result, in 2010, was IR+, which “focuses on giving researchers an online ‘workspace’ within the repository where they can upload and preserve different versions of an article they are working on.” (Kolowich 2010)

An animated video on authoring support in IR+ shows that this private user workspace provides a file manager interface for sharing and collaboration, versioning and publication (Bell and Sarr 2010). In this respect IR+ can be compared with document services such as Google Docs and file management services such as Microsoft Sharepoint, rather than conventional repositories. DepositMO has worked on enabling deposit from similar applications – word processing and file management – but these applications are external to the repository.

There have been number of user studies of repositories focussed on the content submission process. A user evaluation of the DSpace multimedia repository B@bele (Caccialupi, et al. 2009) covered a variety of user issues including ‘Upload’, concluding: “The problem with submitting a new document depends on the layout of the upload page. Finding the upload link on that page is not simple since it is not visually recognizable as the link is inserted in the middle of the page. This task becomes especially difficult if other processes are not yet concluded and are therefore still active.” The method used here proceeded in a similar form to the DepositMO user tests.

Silva, et al. (2007, not OA) measured the ability of segregated groups of users to submit metadata to a repository, in this case the Brazilian Digital Library of Computing (BDBComp). Users had to access the repository, register, login, submit and check data. Results were claimed to show BDBComp to be an easy, comfortable, and useful self-archiving service, without indicating the motivations to use the system.

A model user study – simple, fast, focused – tested the submission process for a DSpace repository for electronic theses and dissertations (Boock 2005). The test included registration as well as deposit: “Usability testing proved we were on the right track and was well worth the two hours invested. Try it; it’s easy.”

While there are other usability studies of repositories and software, not all are from the author deposit viewpoint. McKay (2007) is concerned with repository users and usability, but not authors because they are “better studied than any other users of IRs.” Many such studies are to do with author motivations, or the lack of them, to use repositories (Mark and Shearer 2006, Davis and Connolly 2007) rather than with Web user interfaces.

Where usability studies get closer to repositories and software, they tend to be interested in functional issues, installation and configuration (Ottaviani 2006, Körber and Suleman 2008). Ottaviani considers deposit usability, but in practice proposes functional changes rather than a test report.

McKay and Burriss (2008) perform usability testing of VTLS Vital, one of the Fedora user interfaces, but in this case they test the information-seeking interfaces for end-users rather than deposit interfaces. Kim (J) (2005) compared the search user interfaces of DSpace and EPrints.

Kim (HH) and Kim (YH) (2008, not OA) provide suggestions that could be adapted to improve the usability of institutional repository systems, and to establish a usability evaluation framework. They seem principally interested in how to search for documents, improving visual appearance, clustering and display.

Similarly, although Feng and Huang (2008, not OA) claim to have evaluated the usability of three discipline repositories – arXiv, PubMed Central and E-LIS – their framework, or criteria, for evaluation are really features and usage data taken from the repositories rather than direct involvement with users.

Also based on E-LIS, a subject-focussed digital repository, Tsakonas and Papatheodorou (2008) explored usefulness, usability and performance of an open access digital library based on a statistical analysis of a user questionnaire. Using a theoretical framework rather than observations of practical use, the work revealed that repositories would need to be more closely linked with users’ work tasks.

The next post will continue this review of studies of repository usability by looking at repository deposit processes and protocols that increase the utility of deposit, which we expect will receive greater attention and use going forward.

Digital repositories essentially provide a series of interfaces to get things done, such as deposit content in the repository, manage content (usually an administrator, but can involve others) and access content (users can browse or search, or machines can harvest content using OAI-PMH). It’s curious, then, that there have been few published studies of repository deposit or user testing of deposit interfaces.

Or you might wait for the results of user tests performed with these tools, but since we began this journey towards user testing we have taken such a diversion that you might wonder whether we will get there. We are still on course, so stick with us.

What follows is the @depositMO Twitter commentary on the videos at the time of release in October 2011. For shorter, edited versions of the first video presented below, scroll further down.

Dave Tarrant demos MS Kinect & SWORD v2 deposit

• Dave T has been accused of hand waving. As you will see from the video, it’s true
• To be clear, file manager drag-drop tool seen in the video is tech from DepositMO (Kinect hand waving tech courtesy someone else) #jiscdepo
• It is clearer that the Word deposit tool seen in 2nd half of the video is from DepositMO-so that’s both tools from the project #jiscdepo
• Good to see both DepositMO tools got a spontaneous round of applause during Dave’s show. So that’s a tick for flashiness #jiscdepo

Deposit with MS Word. For a heavily edited version of just the Word part of the demo, see this alt. video (4min11)

• From Word video: “Can hold process of ‘publishing’ (to repository) open. One of the key features of SWORDv2, build object before publish”
• From Word video: “DepositMO has been focussing on building communication between repository and user”
• From Word video: “Telling users where their content has gone so they can access it, add to it, edit it”
• From Word video: “Build this conversation between the Web and whatever system you are using to produce (content)”
• Why demo using Kinect? “Need to think carefully how we are going to get all these things in the repository-make it so intuitive, so easy”

Drag-drop Kinect deposit demo (Watch Folder). For a heavily edited version of just the drag-drop part of the demo, see this alt. video (2min40)

• From Drag-Drop video: “1st object going in EPrints, 2nd in DSpace, going into both. All underlying technology is SWORD v2″

Richard Jones on SWORD2

Since “all underlying technology” in DepMO is SWORDv2, here is Richard Jones on SWORD2 in another Repo Fringe video

• RJ on SWORDv2: “awesome community process”
• RJ on SWORDv2: “going to investigate data deposit aspects that SWORD might be able to support. We’ve also got money for client developments”

Where the SWORDv1 specification allowed resources to be Created in a repository, SWORDv2 has focussed on adding Retrieve, Update and Delete functions, thus providing full CRUD support. DepositMO focussed on use cases requiring extra functionality beyond basic CRUD but which could still use standard, already available specifications.

With DepositMO and SWORD v2 projects running in parallel this provided a set of clear requirements to enable complete interactive control of repository resources via a set of abstracted interfaces. By building upon existing, well developed and widely implemented standards (including HTTP and AtomPub), both projects utilise these standards to enhance digital repositories.

As both projects essentially outline the ideal RESTful implementation for discovery and control of resources in a digital repository, the specifications of the SWORDv2 and DepositMO projects have been integrated into the core of EPrints (v3.3). As a result, the RESTful interface to EPrints is as powerful and flexible as the built-in web interface, providing the following features:

1. All first-class objects can be managed via the REST interface. All EPrints, Documents, Files, Users and anything else identifiable by a URI can be created, updated and deleted via the REST interface.

2. All import plug-ins are now generic and can be utilised via the REST interface, doubling the number of supported package formats which can be deposited via SWORD. Additional plug-ins, which can be installed in a single click, are also available via the EPrints Bazaar app store.

3. The same permissions model is applied both via the SWORD/REST interface as via the normal EPrints interface. The permissions system provides a granular model via which users can be granted permissions based on item status, item type and even an individual item itself. Basically, if editing is possible via the web interface, then it is possible via SWORD.

4. The SWORDv2 specification supports the notion of “in-progress” items, so it has been possible to reduce the number of SWORD deposit endpoints in EPrints to ONE. This has many benefits:

• This endpoint represents a user’s deposits (or repository contents), closely aligning it with the Google Docs implementation and extensions of the AtomPub specification on which SWORDv2 is based.
• SWORD clients are easier to write.
• The user requires less context about which “collection” their content belongs to – it belongs to their collection.

In EPrints, the collection in which an item belongs is represented as a piece of metadata, a significant difference from DSpace. Rather than managing and connecting with several collections, a user can deposit and discover all of their resources via ONE URI, which is the same URI for every user (typically http://myrepo.org/contents). While the SWORDv2 specification outlines how this URI can be used for deposit, DepositMO mandates that a client should also be able to perform the inverse operation and request a complete list of deposit contents via this same URI, regardless of the status of the object.

4. A unique identifier (in the form of a URI) is assigned to every object (including EPrints, Documents, Files, Users etc…) as soon as it is created regardless of the stage in the workflow. This URI will NEVER be reused or overwritten, and can thus be used to reference an object throughout its entire lifecycle in the repository.

5. All URIs support all REST operations: PUT/POST, HEAD, GET and DELETE. The DepositMO profile of SWORDv2 adds the requirement that each URI must accept a HTTP HEAD request. Using this HEAD request, a client is able to request information about an object, such as last changed date, without needing to download the whole object to find this out. This enables each object to be synchronised with a local copy, allowing two-way update with clients that are keeping a local up-to-date copy, an important requirement in distributed systems.

6. All URIs can be content negotiated, meaning that you can get an RDF/XML, Atom, csv… serialisation of every object in the repository. These plug-ins are the inverse of the import plug-ins, so not only can you ingest items in any format, you can also export them in that same format. Again further plug-ins can be installed in one click from the EPrints Bazaar.

In summary, SWORDv2 and DepositMO on EPrints represents a major leap forward in repository flexibility. By utilising the built-in power of the EPrints identifiers, permissions model and Bazaar Store for plug-ins (all of which have been key parts of the EPrints 3.3 development), the HTTP CRUD interface supports SWORDv2 and DepositMO specifications as core functionality, replicating the functionality available via the web interface. This gives users the power to interact fully with their repository and content via an interface or client which suits their way of working, in their environment!

The current release of DSpace is version 1.8, and SWORDv2 is a part of that release. As such, the DepositMO extensions to DSpace have also been rolled into the release (with the exception of the packagers, discussed below). This is a significant development, as it means that new DSpace installations will be able to support the DepositMO extensions “out of the box”, which will be in-line with the EPrints support.

There are a number of notable features of the DSpace implementation which may differ from the EPrints experience:

1. DSpace has a full hierarchical collection structure (called Communities and Collections) which EPrints does not. As such, DSpace Service Documents at least list all of the DSpace Collections as deposit endpoints, but can further offer a full hierarchy of Service Documents containing nested endpoints some of which do not accept deposits but which have sub-collections which do. The consequence of this is that the desktop tools have to be configured with the deposit endpoint of the Collection to which the user will actually be depositing content. There is no option for the user to select an endpoint at deposit-time, and adding such an option would no doubt bring unacceptable complexity in the user experience. Instead the desktop tools must be pre-configured, making them as simple to use as the EPrints version, but at the cost of a less well categorised repository holding. This issue is well known in the DSpace community, and it is therefore not a significant problem.
2. DSpace’s permissions model is relatively complex and there are known issues with providing the end-user with the appropriate rights to modify their own content via remote APIs under various circumstances. For this reason, the prototyping done for DepositMO utilises relatively privileged users for the demonstration. A real production implementation would have a more carefully crafted user model in DSpace.
3. DSpace’s collections represent actual collections of content, while EPrints only has a single collection in SWORDv2 which represents the user’s Inbox. This means that all operations in EPrints work only on items which are in the user’s inbox. Since the connection between SWORD Collection and the user’s workspace in DSpace does not exist, the DepositMO extensions have been constructed to ensure that all the content being worked on remains in the user’s workspace to mimic the EPrints implementation. This is actually the ideal implementation, as significant complexity and the need for versioning multiply rapidly once users can modify content which has left the workspace and entered either the review workflow or the archive itself.
4. DSpace does not provide stable identifiers for objects until they have reached the “archive” itself: items in the workspace or workflow do not have public or even linkable URLs. Since DepositMO requires such URLs to direct users to their repository content, and that content is necessarily in the workspace (see point 3) this presents a problem. To circumvent this problem we have extended the SWORDv2 implementation in DSpace to provide URLs which do resolve to the item in the workspace for both of the application’s web interfaces (JSPUI and XMLUI). The user can therefore follow a link from their desktop to their working item (via a login screen). This feature only works for items in the workspace, as items in the workflow are not directly accessible to the submitting user. This means that the DepositMO desktop client cannot simply remember the identifier for the item on initial deposit, but must regularly check for updates, in case the identifier has changed.

In addition to these developments, the DSpace implementation of DepositMO also provides two Packagers. These are plugins to DSpace which implement SWORD’s ingestion interface and can be brought to bear on incoming content types. As part of the project basic XIF and DocX ingesters were written (utilising pre-existing code contributions by other DSpace developers), and made available open source. These packagers, due to their basic nature, have not been included in the DSpace 1.8 release, but are available separately here.

Overall, the implementation of the DepositMO extensions has been a very natural extension to the SWORDv2 implementation, and will no doubt be valuable to future users of the interface.

Content Management Systems (CMSs) should allow a number of basic functions to be carried out by a user, and digital repositories are no exception. Historically, such repositories have provided pretty web-based, human-focused interfaces through which users can manually perform the tasks of creating and publishing resources. With the development of SWORD, the creation and management of resources became something which, in part, could be carried out using an automated, machine-based client.

In SWORD version 1, this process was focused on making the operation of publishing a completed resource simpler. Further interaction (including retrieval of the same object) was not defined as a requirement. Thus this first specification, while useful, fell short of being a complete CMS system.

It was the intention of SWORDv2 and the DepositMO project to address these shortcomings. In addition, a DepositMO implementation of SWORDv2, the DepositMO profile, extends the functionality of SWORDv2 using a number of the as yet unused parts of the protocols SWORDv2 is based on – AtomPub and HTTP.

This post describes the features SWORDv2 provides to turn repositories into full CMSs, and details two extensions implemented in the DepositMO profile. While the DepositMO profile is a technical document, here we show how the extensions support two particular use cases, and how the DepositMO-developed deposit clients exploit SWORDv2 and the extensions.

Extending repositories as full content management systems

Figure 1 shows some of the basic operations that need to be supported by a digital repository-based CMS system.

Discover: The ability to provide simple description services which allow the client to choose the best method for deposit. Additionally, a client should be able to discover existing resources in the repository, thus skipping Create directly to Update.

Create: Provides a way for a client to create a resource  - a publication object – in the repository. It is this object that is then populated with relevant content.

Update: By making the repository a workspace, content should also be changeable.

Publish: Provide users with a way of describing an object as being suitable for publishing, making it public.

Retrieve: A critical aspect of any CMS system, a user must be able to retrieve their own content.

Delete: Similar to update, a user may be able to delete any resources they own. This is not always the case in digital repositories due to the ties of such systems with the classic publication model (a physical printed copy is hard to ‘delete’).

Use cases for DepositMO extensions to SWORDv2

As well as playing a key role in developing SWORDv2, the DepositMO specification details two key extensions to the SWORDv2 specification:

1. A user/client must be able to retrieve a list of their content regardless of the status of that content (edit, review, published, etc.).
2. A client must be able to obtain basic information about individual objects such that distributed copies can be kept synchronised and up to date.

To demonstrate the importance of these aspects consider the following two use cases:

• A user creates a formal paper which on completion is deposited and published in a repository for a conference. At the conference the author gives a presentation to accompany this submission. Logically this presentation should also accompany the publication already in the repository. Using the DepositMO discovery specification, the presentation software can list all the resources already in the repository and the user can “attach” the presentation as a complementary resource.
• A user is working on a publication for a conference, but wants to work both at home and at work without having to carry around a laptop or a USB memory stick, which will get lost just like half  a pair of socks. By using the repository as a workspace, two clients can maintain synchronisation of the same resource. To save download and comparing the document, which might be of substantial size, a DepositMO extension can be used to check the state of the object without having to download it.

As part of the DepositMO project two clients were produced – a Microsoft Word Add-in client, and a Watch Folder drag-and-drop deposit tool that works with file managers on standard PCs – to demonstrate the principles of these use cases. Although neither the most complete or prettiest clients, they do demonstrate the power of the two combined DepositMO extensions to the SWORDv2 specifications.

DropBox-style repository resource control – Watch Folder client

DropBox is easy. You drag stuff in, it is shared, simple. The barrier to entry for such services is low, meaning that people use them for convenience and uptake is high.

During the DepositMO project, questions were asked about how digital repositories, a trusted authority, could keep up with such technologies. This led to the development within DepositMO of a DropBox-style client for a digital repository.

Called “Watch Folder”, this client enables a user to create a folder, representing their resource, in a standard file manager on a personal computer, and then to add objects that are part of this resource to this folder.

As an example, the repository could contain a collection of images (the objects) relating to a single art exhibition (the resource, folder). As each object is copied into the folder it is simultaneously uploaded to the repository. View and edit links also appear as files on the desktop, connecting the user directly with the corresponding object in the digital repository.

As with DropBox, if an object is deleted or updated via either the repository or desktop interface then this change is instantly reflected in both locations. This functionality is not possible without the DepositMO extensions to the SWORDv2 specification.

The Watch Folder client demonstrates the ideal simplicity of a SWORDv2/DepositMO client to the user.

Windows application integration – Word add-in client

The second client produced as part of the DepositMO project integrates Microsoft Word with a digital repository. Although not a new concept – a similar client was produced by Microsoft to conform with the SWORDv1 specification – the DepositMO version integrates the complete CMS functionality as detailed by the SWORDv2 and DepositMO specifications.

From the start the Windows development separated the low-level driver from application integration. In this way the driver connects the application to the SWORDv2/DepositMO server via an easy-to-use API. This has the beneficial side-effect that the same driver can be used by many applications, saving substantial amounts of time when developing further clients.

The Microsoft Word add-in adds a new tab to the menu “ribbon” in Office 2010. Using this tab a user can set up their credentials with the repository, which can then be used to create and edit resources. Again, the user remains connected to their content whether on the local machine or in the repository.

Future of the DepositMO profile of SWORDv2

The DepositMO profile complements the SWORDv2 specification in order to provide more advanced functionality to deposit clients. For now the DepositMO specification remains an extension to SWORDv2, albeit one that is already integrated into the core of the latest EPrints and DSpace softwares, as will be revealed in the next two posts here. It would not be a huge leap to include the two simple DepositMO extensions in a future SWORDv2 specification, as without them many simple operations are just not possible.

Computer systems provide users with file manager tools, such as Windows Explorer or Mac Finder. This organises lists of files, and folders containing files, stored on the computer. Mostly these are fairly static services. Users can save files to designated directories and folders, and can move and copy files to different locations using short-cut keys of drag-and-drop.

We want to make use of this process of copy or drag-and-drop to initiate repository deposit. It works on the basis of a ‘watch folder’. Essentially this folder contains a script that monitors user actions in adding files or folders to the directory containing the watch folder. Figure 1 shows the active directory containing the watch folder, and also the script that runs when you click on the watch folder.

Fig.1 Active directory containing the Watch Folder script

When a new file is added to the directory containing the watch folder the script initiates a session with the selected repository and copies the file there as well. To complete this process the general script needs some information from the user, the same information used in the Word Add-in example:

• Direction, or url, for the repository
• User login for the repository

This information is provided via a simple text form that is launched by clicking on the CONFIG file in the same directory (see Figure 2). This information only needs to be provided once per user per session with the script running, not for each new file deposit.

Fig. 2 Opening the Watch Folder CONGIG file to specify repository direction and user’s repository login

The watch folder ‘watches’ for changes to all folders in the directory. When a user adds a new file to a ‘watched’ folder, either a new or existing folder in the active directory, within a few seconds the script automatically adds two new files (Figure 3): METADATA, and VIEW_ITEM.

Fig.3 Adding a new file to a ‘watched’ folder generates a METADATA file and a VIEW_ITEM link file

Clicking on METADATA shows an XML copy of the metadata record for the object (content of folder and files) stored in the repository. The user can edit and save the XML record to update the metadata in the repository.

Clicking on VIEW_ITEM will link the user to the real repository record in a Web browser.

In this scheme, a folder in the active directory containing the watch folder represents a record in the repository, and a file in that folder represents an object linked from that record. Thus, folders can be used to organise collections in the repository, for example, adding two images to a folder will link both images to the same repository record. Hence, creating a new folder will correspond to a new record in the repository; an existing folder to a current record.

You can download the Watch Folder script (folder sync client) from our collected project resources. Note, this is not a formally packaged application for easy installation, unless you are comfortable working with perl scripts. For the brave a short ‘getting started’ guide can be found close to the download link for the script.

In principle, this was designed to be a simple way to deposit any file in a repository using basic drag-and-drop and copy commands, and add/update metadata, on the user desktop. Would it prove to be as simple in practice?

The Watch Folder and Word-Add-in are the two user-facing tools developed in DepositMO, but to work effectively these tools need to communicate interactively with repository servers, or repository ‘endpoints’ as they are known in the SWORD community. It is SWORDv2 that enables this communication between endpoints and user applications. The next three posts will consider SWORDv2 and how DepositMO has shaped and extended this standard for different repository softwares, DSpace and EPrints.

The developer of the tool, Richard Boardman from the School of Engineering Sciences at the University of Southampton and a DepositMO project developer, has written a User Guide. This guide covers installation, use, and advanced features such as how to add and markup metadata using Word to ensure that metadata is recognised and reproduced in the repository deposit process.

In this case we are concerned with using the tool and submitting documents, that is, how it was used in the user tests, and so just that section is reproduced from the guide in this post. If you wish to find out more about installing the tool and other features, please see the full user guide. A link to download the tool will be provided at the end of this post.

Installation of this tool requires the use of Windows and the latest release of Microsoft Office/Word 2010. We chose to work with Word as it is a popular authoring tool, widely used among researchers and scientists to write research papers and create materials that are likely to be deposited in institutional repositories. In addition, Microsoft has been seeking to extend the use of Word for digital science by supporting plugins, applications that provide additional functionality required by science authors, such as science and maths markup, DTDs and deposit in arXiv. The deposit tool described here is another such plugin.

Although it is popular, adoption of the latest version of Word and Windows is not universal. So that we did not exclude possible test users, we set up and installed the tool so that the test was not dependent on the user’s equipment.

Since working with users we have been asked if the tool works with other applications in Office, such as Powerpoint. It does not. Emulation of the tool for Powerpoint is possible but not simple.

The following extracts are taken directly from the User Guide.

Using the add-in

Once the add-in has been installed, you should verify that it is available in your copy of Microsoft Word 2010. To do this, start up Microsoft Word 2010 and look for a new entry along the ribbon at the top of the screen.

Figure 1: DepositMO 2010 Word Add-in is visible at the end of the ribbon tabs

Clicking on the DepositMO tab will display the basic controls for the add-in. Show and Hide on the Repository control group will show and hide the main DepositMO control panel. These will by default appear at the right-hand side of the window.

Specifying an Endpoint in the Quick submission group, and clicking Submit will bring up a dialogue box prompting you for your username and password for that endpoint, and allow you to submit the current document to the repository.

Clicking About DepositMO 2010 in the About group will bring up basic information about the add-in.

Figure 2: DepositMO ribbon controls

Submitting a document

Let’s walk through the deposition process with a new document. Enter some text on to the empty Microsoft Word document.

Figure 3: Creating a basic document

Before you can deposit this to the repository, you must first save it on to your computer.

Figure 4: Saving the basic document

If you do not do this, then the add-in will prompt you to save it later before deposition can occur. Clicking Show in the Repository control group of the ribbon will bring up the main control panel for deposition.

Figure 5: Show the repository control panel

The main control panel can be seen now on the right of the window. This has a number of controls for accessing repositories.

Figure 6: The repository control panel in the Microsoft Word window

The top section of the panel allows you to enter details of the target repository: your repository’s location (sometimes referred to as an endpoint), your username at that repository, and the password associated with that username.

Figure 7: Repository endpoint and user details

After entering these details, you can then submit the document to the repository by clicking the Submit button underneath.

Figure 8: Submit and update buttons

The add-in will then send your document to the remote repository. The progress of the submission is then displayed in the Messages box at the bottom of the panel.

Figure 9: Add-in messages

If the submission was successful, then a message similar to the one above will be displayed. This indicates where a copy of our document resides (note that the original still exists where you saved it locally earlier). If it was not successful, then you should check the endpoint and your credentials (username and password), and additionally check the repository by visiting the area on that repository where you would usually manage your deposits.

Figure 10: Document location field

On a successful submission, the Document location field is automatically updated with the remote location of this document.

Figure 11: Panel appearance after a successful deposition

If you look at the panel now our deposition has successfully completed, you can see that the Repository location remains unchanged, as does the Username and Password, but the Document location is now different, as explained above. The Messages can be reviewed by scrolling up the little text area.

You can review your recent submission to the remote repository by visiting it with your web browser.

Note that as our example document contained no information about the title or authors of the document, there is correspondingly little detail on the server

Figure 12: Reviewing the submission in the remote repository

Download the Add-in

This ends our extracts in this post. If you wish to learn about updating a document submitted to repository and other ways to use to use this tool, continue reading the User Guide.

Now you know the basics of how to use the Word Add-in tool a you may want to download it to use with your copy of Word 2010. This download can be found among our collected project resources. The guide has instructions for installation.

The next post will introduce the second of the repository deposit tools developed by the DepositMO project and subjected to user testing, the Watch Folder tool.

Show MS Word Add-in for repository deposit

The target of current repository software is completed works.

The principal contribution of the DepositMO project is to provide new tools to support deposit of in-progress digital works. This is a significant change from current methods of repository deposit involving completed works.

To do this requires two new methods: deposit tools built into the authoring applications, and a means for these applications to communicate and interact with the repository software, providing the user with status and update responses. In essence this is like replacing your computer hard drive, instead saving the content destined for the repository directly in that repository and treating it as a network drive. Saving this content to a repository iteratively as it develops, as you do when saving on your local computer, requires the same functionality and assurance of correct execution, security and privacy. As we shall see, however, the expectation of description and metadata for a repository adds complexity compared with the simple method of save-to-hard-disc-and-add-filename.

Watch Folder, repository deposit via a standard file manager

We have blogged before about the principles, reasons and advantages of this new approach to repository deposit, but apart from some early demonstration videos we have not previously described or illustrated the actual deposit tools in any detail. Post-user testing of these tools we can now rectify this omission.

There are three new elements, including two deposit tools, and a means of enhancing and updating popular repository software such as EPrints and DSpace:

SWORDv2 supports Create, Retrieve, Update, Delete

1. A Microsoft Word Add-in deposit tool, to allow content in a document to be saved to, updated, or deleted from a repository during composition, without leaving the application.
2. A Watch Folder deposit tool, to enable content of any type and in any format to be uploaded to a repository simply by dragging in a file manager window.
3. Extensions to SWORDv2 for repository software

Of course, the second tool obviates the principle of bypassing the local hard drive, since the file manager is a record of what’s on the drive. But it means we can test deposit of a wider range of content before deposit tools are integrated with more authoring applications. Experience with building the Word deposit tool shows this is a major investment of time and expertise, as well as liaison with and support of the developer of the original application, in this case Microsoft – even when the application supports in-application plugins through APIs.

In the next three posts we will explore each of these new deposit tools in more detail, starting with the Word Add-in deposit tool.