Hi Kathi, Thank you for the response. This is currently similar to our approach:
1.) A user can create a new version from the original, it is placed into the requesting users Submission Workspace. The original is "locked" from further editing. 2.) The Submitter may alter the new Item in their workspace to achieve the changes they want. 3.) They then submit the new version to the Reviewer Workflow, where it can be evaluated by reviewers. 4.) On Acceptance, it is placed into the archive. 5.) Repo Maintainers can choose if they want to have previous versions still be searchable/viewable in the repository configuration. I can see that we could align steps 1-3 with your protocol allowing SWORD users to participate in versioning in the same manner. Questions: Can you the use different IRI to reference each of the versions of the resource? Is it possible to "revert" or "rollback" a working revision when its created at step (2) Is it possible to create a new version off of any previous revision of the resource in the version history (i.e. after 3 has completed). === The NESCents Dryad repo utilizes a Versioning prototype @MIRE has developed that clones DSpace Items and utilizes a "Version History Service" to track/manage the relationships between different versions of DSpace Items. This allows the user/curator to: 1.) Spawn new Versions of Items, retaining the previous state for posterity. 2.) Revert Current Latest Version of an Item to a previous version. 3.) Refer to different Versions of the Item by Identifier. Each Item has a canonical handle that referes to the most current Item, this handle is moved to the new version when it is archived into the repository. Thus the current Item has two handles, while each previous version can be refered to by its individual handle. In Dryad, DOI's are used instead of handles, and the DOI contain syntactical detail about the Item and Version being refered to doi:[prefix]/dryad.[itemid].[version] doi:10.5061/dryad.62s7r0p5 doi:10.5061/dryad.62s7r0p5.1 doi:10.5061/dryad.62s7r0p5.2 doi:10.5061/dryad.62s7r0p5.3 If handles / local IRI are used to refer to the Item, they are are opaque and do not have syntactical detail about the Item/Version. We started out considering the use of metadata fields in DSpace to track versioning. Identifying VersionHistories via dc:isVersionOf/replaces/isReplacedBy metadata and quickly determined that it was necessary to provide a more explicit data model for versioning items in DSpace as metadata is brittle and can always be broken by a user who is unaware of what they are doing. We know this approach both differs from the approach Fedora and the DSpace SWORDv2 implementation would take for Versioning of Datastreams/Bitstreams within an Item. But that is quite intentional, we are working to achieve logical versioning of the entire Item/Object rather than just storing previous versions of the stored Bitstream/Datastream Content. We feel this allows the physical Items/Objects to continue to be managed and persist unchanged for historical/tracking purposes while allowing submitters/maintainers a business process to support the publication/release of new versions. The approach taken is analogous to the experience when working in a WIKI, previous versions (wiki text + attachments) of the page are presented in context of the current page, and may be viewed, restored or deleted. It sounds like it would be good to have someplace where different approaches to versioning could be compared so that some best practices or commonalities might be identified across repositories that will support versioning. Best Regards, Mark On Fri, Sep 16, 2011 at 11:21 AM, Kathi Fletcher <kathi.fletc...@gmail.com> wrote: > Hi Mark, > SWORD leaves versioning possible, but not specifically defined, as I > understand it. > Connexions is a versioning repository and we are implementing a SWORD V2 > service. We are using a POST to the Col-IRI with dcterms:isVersionOf set to > a repository item that you want to create a new version of. > "To create a new version of published content, the client issues a POST to a > Col-IRI with an Atom Entry that contains “isVersionOf" with the URL of > published content that this should be a new version of. The OERPub (SWORD > v2) service SHOULD populate the new version with the contents of the parent > version." > We are electing to do things in a couple of steps: > > Create a new version from the old version (POST to Col-IRI) -- and it ends > up in an editing environment. > Retrieve the contents (GET to EM-IRI) and edit them. > PUT the new version. > > Kathi > On Fri, Sep 16, 2011 at 11:37 AM, Mark Diggory <mdigg...@atmire.com> wrote: >> >> Hi Stuart, >> >> Great work! I'm coming in pretty late in the game, but want to review >> swordv2 for our own uses as early as possible. >> >> I'd like to understand better the versioning functionality. I'm >> looking at the work done on the swordv2 DSpace implementation and >> trying to determine how compatible it will be with DSpace Item >> Versioning prototypes we have going with NESCent. >> >> Can anyone point me at a specification for versioning in v2? >> >> Mark >> >> On Fri, Sep 16, 2011 at 12:46 AM, Stuart Lewis <stu...@stuartlewis.com> >> wrote: >> > Hi all, >> > >> > It has been a little while since we've had any activity on this list - >> > so I thought I'd send a quick update. The implementations (DSpace / >> > EPrints >> > / Fedora / Ruby / PHP / Java / Python) have all progressed well. One of >> > the >> > things Richard hopes to do in the next week or so is to help us decide if >> > the SWORD v2 specification as it stands is now ready to be 'released' or >> > not. >> > >> > We knew this decision would require some implementations in order to >> > test some of the decisions that this group had made. Kathi Fletcher, a >> > Shuttleworth Fellow >> > (http://www.shuttleworthfoundation.org/fellows/kathi-fletcher/) has been >> > working with the Connexions OER repository (cnx.org) to look at using SWORD >> > v2 as a the basis or an OER deposit interface. She has therefore been >> > working deeply with the specification for the past couple of months, >> > meaning >> > she has a lot of useful experience in working with it. We have therefore >> > added her into this group so that we can learn from her experiences. >> > >> > Thanks, >> > >> > >> > Stuart >> > >> > ------------------------------------------------------------------------------ >> > BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA >> > http://p.sf.net/sfu/rim-devcon-copy2 >> > _______________________________________________ >> > Sword-app-techadvisorypanel mailing list >> > Sword-app-techadvisorypanel@lists.sourceforge.net >> > https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel >> > >> >> >> >> -- >> Mark R. Diggory >> @mire - www.atmire.com >> 2888 Loker Avenue East - Suite 305 - Carlsbad - CA - 92010 >> Esperantolaan 4 - Heverlee 3001 - Belgium >> >> >> ------------------------------------------------------------------------------ >> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA >> http://p.sf.net/sfu/rim-devcon-copy2 >> _______________________________________________ >> Sword-app-techadvisorypanel mailing list >> Sword-app-techadvisorypanel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel > > > > -- > Katherine Fletcher, kathi.fletc...@gmail.com > Twitter: kefletcher Blog: kefletcher.blogspot.com > > > -- Mark R. Diggory @mire - www.atmire.com 2888 Loker Avenue East - Suite 305 - Carlsbad - CA - 92010 Esperantolaan 4 - Heverlee 3001 - Belgium ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 _______________________________________________ Sword-app-techadvisorypanel mailing list Sword-app-techadvisorypanel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
