Dear Marc,
I just had a meeting with my users (Belgium Poison Centre) and the
organisational model you propose (one version per contribution +
workflow for contribution control) seems to them more suitable to their
operations than the one they currently live with JspWiki (one version
per save).
I will explore the pointers you provide and see how it fits with my
"forked" DSpace.
From that, I will make you a collaboration proposal as a separate use
case and test situation.
By the way, the ASKOSI plugin for DSpace 1.7 / 1.8 is available.
For each metadata field for which it is desired, it allows to define one
or many SKOS vocabularies to control that metadata field.
ASKOSI is declared in dspace.cfg as an Authority Control plugin and it
retrieves the per field list of vocabularies to be used in the
Submission Input Form Definition.
A documentation effort is under way for ASKOSI but you can have a basis
here:
http://www.destin-informatique.com/ASKOSI/Wiki.jsp?page=ASKOSI%20jar
The vocabularies can come from many sources (SPARQL, RDF, XML,
databases, CSV files, Java Bundles) and displayed graphically in the
ASKOSI Web Application:
http://www.destin-informatique.com/scheme/concept.jsp?concept=c_4311&graf=en#Graf
and JITA, the vocabulary project I coordinate with E-LIS:
http://www.destin-informatique.com/scheme/view.jsp?scheme=jita
Wishing you a very nice day,
Christophe
Le 8/12/2011 18:38, Mark Diggory a écrit :
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]
<mailto:[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
<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
--
@mire Inc.
*Mark Diggory*
/2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010/
/Esperantolaan 4, Heverlee 3001, Belgium/
http://www.atmire.com <http://www.atmire.com/>
------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
