Mark & Richard, A few clarifications that may help.
In DSpace 1.8.x, SWORD & AIP Backup/Restore use similar methods to process and ingest a METS/AIP package. SWORD (v1 & v2), by default, uses the org.dspace.content.packager.DSpaceMETSIngester class (though it can now be configured to use a different ingester via the 'mets-ingester.package-ingester' setting). AIP Backup & Restore uses the org.dspace.content.packager.DSpaceAIPIngester class. Although these are separate Ingester classes, both DSpaceMETSIngester & DSpaceAIPIngester extend the AbstractMETSIngester abstract class, which performs most of the actual METS/AIP ingestion processing. When the METS/AIP package refers to an Item, this AbstractMETSIngester class calls PackageUtils.finishCreateItem() to actually apply any workflows or install the item (using InstallItem as appropriate). https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/content/packager/PackageUtils.java#L504 So, in both cases, InstallItem should be used appropriately (at least in the latest 1.8.x codebase). That all being said, I have never tried to set an embargo via SWORD (and haven't had a chance to test this out). So, I cannot verify one way or another whether this actually works in 1.8.x. - Tim On 5/3/2012 3:13 PM, Mark Diggory wrote: > Certainly, > > I believe, in previous dialogs with Tim, he suggested it would as long > as the metadata fields mapped appropriately to the existing > configuration. The questions sounds like its important to determine if > AIP Restore, like SWORD is using InstallItem or not. > > Case 2 (fails) - SWORD goes straight in (no workflow) - this uses > some code in the METsPackager to create and install the item, not > InstallItem (I think, have to check the code), so it misses the > embargo checking. > > > I'd say that having SWORD "not" do this and use InstallItem more > appropriately would be an important consideration. Many other > considerations come into play when the standard mechanism for installing > items is circumvented. > > Mark > > On Thu, May 3, 2012 at 1:01 PM, Richard Rodgers <[email protected] > <mailto:[email protected]>> wrote: > > Hi Mark: > > We may, but we should first determine whether the METsPackager is > functioning correctly now. Tim D did the METSPackager work in > support of the AIP backup/restore, > and I'm pretty sure restoring embargo state was a use-case. As > least, it *should* be. > > Richard > > > On May 3, 2012, at 3:55 PM, Mark Diggory wrote: > >> I'm determining if we would want to add some of these details to >> our Advanced Embargo Support business/technical requirements for >> DSpace 3.0. >> >> https://wiki.duraspace.org/display/DSPACE/Advanced+Embargo+Support >> >> Best, >> Mark >> >> On Tue, Apr 3, 2012 at 2:52 PM, Richard Rodgers <[email protected] >> <mailto:[email protected]>> wrote: >> >> Ignasi: >> >> A little more detail on Tim's point: the code paths are a >> little different when submissions go through workflow: >> >> Case 1 (which works) - SWORD deposit goes into workflow. When >> it exits workflow, 'InstallItem.installItem()' gets called, >> which in turn calls EmbargoManager to set embargo if necessary. >> >> Case 2 (fails) - SWORD goes straight in (no workflow) - this >> uses some code in the METsPackager to create and install the >> item, not InstallItem (I think, have to check the code), so it >> misses the embargo checking. >> >> A lot of work has been done on packager code since 1.6, and >> I'm guessing it would work OK on later releases, at least 1.8 >> >> So it does appear that it's a 1.6 (packager) bug. Your options >> are to patch 1.6 (possible, but will take some analysis and >> testing), or live with putting SWORD deposits through workflow >> until you upgrade... >> >> Richard R. >> >> >> On Apr 3, 2012, at 5:01 PM, Tim Donohue wrote: >> >> > My apologies, Ignasi, >> > >> > It was pointed out to me that this *should* be possible, as >> per our >> > DSpace 1.8 Documentation: >> > >> > >> >> https://wiki.duraspace.org/display/DSDOC18/Embargo#Embargo-Termsassignment >> > >> > It explicitly states: >> > "The first step in placing an embargo on an item is to >> attach (assign) >> > 'terms' to it. If these terms are missing, no embargo will >> be imposed. >> > As we will see below, terms are carried in a configurable DSpace >> > metadata field, so assigning terms just means assigning a >> value to a >> > metadata field. This can be done in a web submission user >> interface >> > form, in a SWORD deposit package, a batch import, etc. - >> anywhere >> > metadata is passed to DSpace." >> > >> > My previous message was incorrect. I forgot that DSpace >> Embargo can be >> > set by merely passing in a DC metadata field. So, it >> *should* be >> > possible to set an embargo via the DSpace SWORD field >> (assuming you just >> > pass in the embargo terms as the configured metadata field). >> > >> > I now wonder if this is a bug in DSpace 1.6.x. I'm not sure >> if anyone >> > has tried this in more recent versions of DSpace? >> > >> > - Tim >> > >> > On 4/3/2012 3:10 PM, Tim Donohue wrote: >> >> Hi Ignasi, >> >> >> >> Unfortunately, I don't believe this is possible, as SWORD >> doesn't >> >> support the idea of an "item-level embargo". The Item >> Embargo feature >> >> you are talking about is specific to DSpace. >> >> >> >> The only way I can think of doing this is to submit the >> item via SWORD >> >> into a collection that has a workflow approval process >> setup (with the >> >> edit metadata step). Then you'd have to have someone >> manually go into >> >> the edit metadata step and manually add in the embargo. >> I've never tried >> >> this myself, but I think it may work. >> >> >> >> - Tim >> >> >> >> On 3/29/2012 4:03 PM, Ignasi Labastida i Juan wrote: >> >>> Hi, >> >>> >> >>> We are implementing the embargo feature in our institutional >> >>> repository. It seems to work fine. >> >>> We are also connecting our Research Information System >> with the IR >> >>> using the sword protocol. >> >>> Now we have found a problem when we send a document with >> embargo to a >> >>> collection without workflow. The item sent via sword goes >> to the >> >>> collection with all the metadata but without embargo. The >> embargo >> >>> terms and metadata arrive fine. >> >>> The same item is sent to a collection with workflow via >> sword, using >> >>> the same METS file, and once is accepted by the >> administrator the >> >>> embargo goes on. >> >>> >> >>> Any hint? >> >>> >> >>> Is it possible to send the embargoed item to a collection >> without >> >>> workflow? >> >>> We have DSpace 1.6.2 and Sword 1.3 >> >>> >> >>> Thanks >> >>> >> >>> Ignasi Labastida >> >>> Universitat de Barcelona >> >>> >> >>> >> >> ------------------------------------------------------------------------------ >> >>> >> >>> This SF email is sponsosred by: >> >>> Try Windows Azure free for 90 days Click Here >> >>> http://p.sf.net/sfu/sfd2d-msazure >> >>> _______________________________________________ >> >>> DSpace-tech mailing list >> >>> [email protected] >> <mailto:[email protected]> >> >>> https://lists.sourceforge.net/lists/listinfo/dspace-tech >> > >> > >> >> ------------------------------------------------------------------------------ >> > Better than sec? Nothing is better than sec when it comes to >> > monitoring Big Data applications. Try Boundary one-second >> > resolution app monitoring today. Free. >> > http://p.sf.net/sfu/Boundary-dev2dev >> > _______________________________________________ >> > DSpace-tech mailing list >> > [email protected] >> <mailto:[email protected]> >> > https://lists.sourceforge.net/lists/listinfo/dspace-tech >> >> >> >> ------------------------------------------------------------------------------ >> Better than sec? Nothing is better than sec when it comes to >> monitoring Big Data applications. Try Boundary one-second >> resolution app monitoring today. Free. >> http://p.sf.net/sfu/Boundary-dev2dev >> _______________________________________________ >> DSpace-tech mailing list >> [email protected] >> <mailto:[email protected]> >> https://lists.sourceforge.net/lists/listinfo/dspace-tech >> >> >> >> >> -- >> @mire Inc. >> *Mark Diggory *(Schedule a Meeting <https://tungle.me/markdiggory>) >> /2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010/ >> /Esperantolaan 4, Heverlee 3001, Belgium/ >> http://www.atmire.com <http://www.atmire.com/> >> >> > > > > > -- > @mire Inc. > *Mark Diggory *(Schedule a Meeting <https://tungle.me/markdiggory>) > /2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010/ > /Esperantolaan 4, Heverlee 3001, Belgium/ > http://www.atmire.com <http://www.atmire.com/> > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > > > _______________________________________________ > DSpace-tech mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/dspace-tech ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
