Contribute to the DSpace Development Fund
The newly established DSpace Development Fund supports the development of new features prioritized by DSpace Governance. For a list of planned features see the fund wiki page.
This is a page to discuss the strengths and weaknesses of DF as a mechanism for storing metadata in DSpace. It's originally structured as a SWOT analysis, but it might turn out not to be appropriate.
Strengths
Flexibility
DF is excellent for introducing new metadata schemas for existing resources. It would be possible to use DF to drive many aspects of the application, as well as using it for traditional metadata.
Weaknesses
Learning Curve
The learning curve for DF is infamously steep - potentially reducing our developer pool. A part of this comes from the requirement to use a new query language (probably DQL).
Opportunities
eification To Support Conflicting Metadata
eification could be used to allow the system to sensibly support conflicting metadata information about a resource. This could be used by humans (e.g. an administrator giving a resource a different classification to the one chosen by the author) or machines (e.g. a particular DSpace instance preferring to trust representation information from JHOVE over that from FED)
Convenient Integration With Cocoon
If cocoon is chosen to support the next gen web application DF would be pretty convenient. y being a little careful with our DF (as per http://www.xml.com/lpt/a/2002/10/30/rdf-friendly.html Making DF XML friendly) we could use XSLT (or XQuery, potentially) to generate presentation pages directly.
Threats
Volatility
The DF specs are fairly old, but have changed quite a bit between versions. Has the standard settled now? If not - we could end up with a considerable amount of effort to stay current. Will the use of 3rd party tools ameliorate this?
Unknown Scalability
I don't know how well DF tools scale, and I do know that DMS's scale well enough. If anyone has better information on this, clarification would be appreciated. JimDowning