{"id":179,"date":"2010-10-18T10:38:08","date_gmt":"2010-10-18T09:38:08","guid":{"rendered":"http:\/\/blog.soton.ac.uk\/depositmo\/?p=179"},"modified":"2012-01-24T17:40:34","modified_gmt":"2012-01-24T16:40:34","slug":"repository-deposit-turns-to-crud","status":"publish","type":"post","link":"https:\/\/blog.soton.ac.uk\/depositmo\/2010\/10\/18\/repository-deposit-turns-to-crud\/","title":{"rendered":"Repository deposit turns to CRUD"},"content":{"rendered":"

\"crud\"<\/a>There’s no more elegant way of putting it really. What’s at the heart of DepositMO? CRUD<\/p>\n

Create, Retrieve (or Read), Update and Delete<\/a> (CRUD), the four basic functions of\u00a0persistent storage. This is what differentiates the project from current capabilities for remote deposit of content to repository services. I’m using CRUD to write this blog post in WordPress. As I write I have two action buttons to the right of the content pane: Save Draft, and Publish. Both allow me to update the content to the storage server, the difference being whether the post is made public or not.<\/p>\n

So there is nothing new about CRUD, except that it is not yet directly applicable to many of today’s digital repositories, which tend to support single publishable item deposit with subsequent versioning should changes be needed or if updated versions are produced. In other words, there is no concept of a repository workspace – or a connected workspace – that allows the simple incremental updates widely supported by other computer authoring services and described by CRUD, or applications that go beyond this.<\/p>\n

“For authors it is often suggested that content might be deposited once by filling data in a Web form, but too much effort is involved for the process to be repeated for another repository. Better is multiple simultaneous deposit under the control of the author.”<\/strong><\/p><\/blockquote>\n

It became clear that we should do more to emphasise the role of CRUD in this project following a short, branched exchange on the American Scientist Open Access Forum mail list. A recurrent theme on the list had returned – the apparent tension between deposit in central, subject-based repository collections such as arXiv and distributed institutional repositories (IRs). The question is where to deposit; the aim to maximise the volume of open access content.<\/p>\n

Currently the answer probably depends on which subject area the research to be deposited covers, e.g. physical or biomedical sciences\u00a0will most likely deposit centrally, due to the strength of the repositories serving these areas. Other disciplines will deposit institutionally, but on a much lower scale. There is the crux of the open access problem.<\/p>\n

The answer proposed, notably by Stevan Harnad on the AmSci list, is for institutions to mandate deposit of published research papers in the local repository. That is, all papers, not just those not already deposited in a subject-based open access repository elsewhere.<\/p>\n

For authors it is often suggested that content might be deposited once by filling data in a Web form, but that too much effort is involved for the process to be repeated for another repository. One approach to reduce the perceived workload, given that all these repositories are open and allow open harvesting of data using OAI-PMH, is to deposit once and then harvest the content to other repositories as required.<\/p>\n

Another approach might be multiple simultaneous deposit. To save authors effort, data for deposit is entered into a form once, and then copied to the designated repository destinations. One tentative suggestion to emerge in the latest round of list discussion was that deposit to an IR be accompanied with login details<\/a> for a central subject repository for subsequent deposit. This is fraught with security problems, as we pointed out<\/a> to the list.<\/p>\n

\"SWORDEnter SWORD, for it was suggested that this be the mechanism for sharing deposit and logins in this case. It turns out that the organisation developing SWORD has a case study<\/a> that looks quite like that proposed.<\/p>\n

Separately, this is what arXiv says about using SWORD for deposit<\/a>:<\/p>\n

“This interface is primarily intended for use by conference organizers, proceedings and journal editors, etc. for programmatic bulk upload of pre-vetted material to arXiv for long term archival and dissemination. It is assumed that this is done with the (implied or explicit) approval of the authors of individual contributions or on their behalf.<\/p>\n

“Individual authors may prefer arXiv\u2019s interactive web upload for personal use, because it provides better feedback mechanisms, but in principle the deposit API can be used for one-at-a-time deposit to arXiv by individual authors, too. We envision integration of the deposit process into authoring tools for efficient upload from the desktop.”<\/p><\/blockquote>\n

So third-party deposit is just about acceptable, perhaps, without being wholly endorsed. The last sentence points indirectly towards the work of DepositMO, and Simeon Warner of arXiv was a co-author of the project’s short debut paper<\/a> at the Open Repositories 2010<\/em> international conference (OR10).<\/p>\n

As this paper shows, better than deposit-once and subsequent deposit elsewhere by another agent is multiple simultaneous deposit under the control of the author. It turns out that SWORD has this covered<\/a> as well.<\/p>\n

In fact, there are quite a few SWORD implementations<\/a> connecting different applications (sources) and repositories (destinations). If you look closely, one of those implementations listed is Microsoft\u00a0Article Authoring Add-in for Word 2007\/2010 \u2013 allows repository deposit direct from Word. Within DepositMO we have made some claims about enabling repository deposit from popular applications such as MS Office, and in the project\u00a0we shall be working with Microsoft to enhance this tool.<\/p>\n

Have we made the USP for DepositMO clear in the documentation to date? It’s not SWORD, or deposit or even multiple deposit, or deposit from specified applications. The answer begins with CRUD.<\/strong><\/p><\/blockquote>\n

Among this welter of deposit applications, you are probably asking what exactly will be DepositMO’s unique contributions? No. Well I was. At least, I was beginning to wonder if we had made our USP clear in the documentation to date. It’s not SWORD, or deposit or even multiple deposit, or deposit from specified applications. The answer, as we have already indicated, begins with CRUD.<\/p>\n

The project proposal<\/a> talked of ‘an\u00a0effective culture change mechanism’. That’s a wider issue for another time. On more technical issues the proposal describes the aim to ‘extend the capabilities of repositories to\u00a0exploit desktop and authoring environments’. More specifically it refers to components for the Microsoft Office authoring environments and enhanced SWORD interaction.<\/p>\n

No reference to CRUD-like features here. Nor in the OR10 paper – at least, not using these terms – but the direction is clearer. The paper starts by specifying the motivations for multiple deposit.<\/p>\n

Today the use case for repository deposit is write the content with a typical computer desktop application and save it somewhere, but not in the repository yet – the equivalent of the blog Save Draft button. When the work is complete it can be packaged and delivered to the repository using SWORD, the same as the Publish function in the blog. The OR10 paper puts it like this:<\/p>\n

“Currently SWORD is a one-way protocol, meaning that a repository can either accept a record, or reject it; there is no middle ground. Adding a lightweight mechanism to desktop applications to enable negotiation on what is sent in a SWORD package would go some way to bridging this gap.”<\/p><\/blockquote>\n

This facility should become available in SWORD v2.0, and developers from the project are contributing directly to this activity since there is a vested interest in the outcome.<\/p>\n

It would open new deposit possibilities. An admittedly complex and possibly unusual, but nevertheless feasible, case is suggested in the OR10 paper\u00a0where an author of a research paper pulls information from other linked sources, such as a contacts list and a citation manager:<\/p>\n

“At the point the document is submitted all this valuable information (such as author identities disabiguated by email address and structured citation listing) is lost.”<\/p><\/blockquote>\n

All this is more sophisticated than CRUD and points the way forward, but first implementing CRUD features using SWORD as a mediator between applications and multiple repositories would represent serious progress.<\/p>\n

What might follow from this is ‘culture change’ or, more immediately, dialogue between author and repository<\/a>. The OR10 paper puts it more prosaically:<\/p>\n

“Our proposal is to enable a simple yet powerful set of negotiations to occur between the desktop application and multiple repositories such that a single familiar submission workflow (in the style of the author\u2019s application) can be presented to the user.”<\/p><\/blockquote>\n

So as a starting point the aim in DepositMO is to activate the repository as a storage service for the iterative Save Draft action in an authoring application.<\/p>\n

In the next post we will consider the practical implications of this approach and look at an early sketch of a possible interface design.<\/p>\n

Just as long as we all understand and can share in what is new and where we are heading. Otherwise we may just find ourselves talking about a more familiar form of crud.<\/p>\n

\n

\"Crud.<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

There’s no more elegant way of putting it really. What’s at the heart of DepositMO? CRUD Create, Retrieve (or Read), Update and Delete (CRUD), the four basic functions of\u00a0persistent storage. This is what differentiates the project from current capabilities for remote deposit of content to repository services. I’m using CRUD to write this blog post […]<\/p>\n","protected":false},"author":25,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[417,332,334,143,418,4025],"class_list":["post-179","post","type-post","status-publish","format-standard","hentry","category-uncategorized","tag-crud","tag-depositmo","tag-inf11","tag-jisc","tag-sword","tag-swordv2"],"_links":{"self":[{"href":"https:\/\/blog.soton.ac.uk\/depositmo\/wp-json\/wp\/v2\/posts\/179","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.soton.ac.uk\/depositmo\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.soton.ac.uk\/depositmo\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.soton.ac.uk\/depositmo\/wp-json\/wp\/v2\/users\/25"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.soton.ac.uk\/depositmo\/wp-json\/wp\/v2\/comments?post=179"}],"version-history":[{"count":67,"href":"https:\/\/blog.soton.ac.uk\/depositmo\/wp-json\/wp\/v2\/posts\/179\/revisions"}],"predecessor-version":[{"id":247,"href":"https:\/\/blog.soton.ac.uk\/depositmo\/wp-json\/wp\/v2\/posts\/179\/revisions\/247"}],"wp:attachment":[{"href":"https:\/\/blog.soton.ac.uk\/depositmo\/wp-json\/wp\/v2\/media?parent=179"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.soton.ac.uk\/depositmo\/wp-json\/wp\/v2\/categories?post=179"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.soton.ac.uk\/depositmo\/wp-json\/wp\/v2\/tags?post=179"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}