Christophe,
Sorry, this has been sitting in my drafts for a month now and I notice it
now that TIm replied. There are initiatives on Item Versioning and
operational production code to support this feature in Dryad.
We've done Item Level Versioning support for Dryad that is based on
previous architectural review group recommendations. This includes support
for Item Metadata level versioning. Our intent is to place this into the
DSpace modules and provide it for support, but that contribution work needs
to happen in the community because there are many Dryad centric assumptions
made in the current approach.
To clarify what this supports:
1.) New Versions of Items may be spawned from existing items.
2.) Existing Items are "Lucked" and new version cannot be created until the
new version in the submitters workflow passes through the review process.
3.) All metadata and bundles are versioned in the Item
4.) Bitstreams are conserved across the items.
5.) A version History is visible to users, versions may still be
deleted/edited by repository admins.
We've decided that it is very bad practice to use Item metadata as a
catchall for versioning state / relationships, we store these relationships
explicitly in the database as a new table to assure version integrity can
be maintained when edits/delete occur. The metadata details relating
to versioning are exposed via a separate administrative metadata section of
the METS document and rendered as new sections under the ItemView in the
UI. Because new versions are new Items, we are able to just reuse the
existing OAI-PMH support / etc. But we need to look further in enhancing
these to support exposing the versioning information and look into how
SWORD v2 will manage Item Versioning more effectively.
Likewise, this leverages a new IdentifierService we created, this
IdentifierService allows for customization of the Persistent Identifiers
used in DSpace, the default are handles, but we've implemented DOI support.
The reason for these new Services is that for Dryad, identifiers are
versioned such that the version id is encoded in the DOI (as well as the
parent/child relationship between Dryad Data Package and Data File Item
hierarchies).
Per SWORD v2 Versioning, the analog we are seeing now with DSpace is
similar tot he debate in the Fedora community concerning Atomic vs Complex
Fedora Objects. This point being, should we be establishing a best practice
for when new bundles are defined and bitstreams move to them, the current
approaches we have taken for Dryad Versioning and SWORD v2 Versioning are
somewhat orthogonal/contradictory. And this needs to be worked out in the
next versions of these features, SWORD v2 versioning crams the previous
versions bitstreams into new bundles with versioning details encoded in
them. Whereas, Dryad Versioning supports versioning the entire Item
"Metadata/Identifiers/Bundles/Bitstreams". The Dryad Approach is modelled
off of the style of versioning you see in existing WIKI platforms like
Mediawiki, XWiki and Confluence, where the analog is that WIki content =
DSpace metadata and Wiki attachements = DSpace Bitstreams.
Dryad Versioning is based on the previous GSoC Versioning project
https://wiki.duraspace.org/display/GSOC/Google+Summer+of+Code+2007+Versioning
The source for Dryad Versioning is maintained int he Dryad SVN repository
at GoogleCode.
http://code.google.com/p/dryad/source/browse/trunk#trunk%2Fdryad%2Fdspace%2Fmodules
This is a planned contribution to DSpace and we would welcome community
participation on assisting in vetting it outside of Dryad.
A few more notes below...
On Wed, Nov 30, 2011 at 6:29 AM, Christophe Dupriez <[email protected]>wrote:
> Hi!
>
> I am planning to develop Item Metadata Versioning for DSpace.
>
> The objective is to give repository managers the possibility:
> 1) to track of who modified what and when (productivity, responsibility)
> 2) to undo any unwanted changes (and redo when needed!)
>
> Some preliminary specs:
>
> http://www.destin-informatique.com/ASKOSI/Wiki.jsp?page=Metadata%20Versioning
>
> As I use DSpace as a "general purpose repository" and especially as a
> SKOS Concepts Repository, the ability to control the content is very
> important.
>
> Example of this:
> http://www.windmusic.org/dspace/subject-search
> which comes from:
> http://www.windmusic.org/askosi/
> graphically presented as:
>
> http://www.windmusic.org/askosi/concept.jsp?concept=sujet_22227&graf=en#Graf
> SKOS data coming from the DSpace Collection:
> http://www.windmusic.org/dspace/handle/68502/27
> Concept data coming from:
> http://www.windmusic.org/dspace/handle/68502/22227
>
> I would be very grateful, if similar initiatives are in the pipeline, to
> pointed to the URL of existing documentation about them.
> I am also very open to collaborate to existing efforts if desired.
>
I think the idea of using Items for Authority Control concepts
is intriguing. We are currently looking to create a separate
"Authority/Concept" Object to preserve concept details and hierarchy such
that we can maintain it separate from the content Items themselves. But I
suspect they will look very much like your Concept Items in the long run.
This would be a great area to see collaboration emerge to asure one
instance
Cheers,
Mark
--
[image: @mire Inc.]
*Mark Diggory*
*2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010*
*Esperantolaan 4, Heverlee 3001, Belgium*
http://www.atmire.com
------------------------------------------------------------------------------
Cloud Services Checklist: Pricing and Packaging Optimization
This white paper is intended to serve as a reference, checklist and point of
discussion for anyone considering optimizing the pricing and packaging model
of a cloud services business. Read Now!
http://www.accelacomm.com/jaw/sfnl/114/51491232/
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
