Page History
...
Wiki Markup |
---|
We took notes & shared additional links via IRC. http://irclogs.duraspace.org/index.php?date=2012-03-01 (Starts at \[20:01\]) |
Actionable Takeaways
Day #5 Notes (Mar 2)
Attendees: Kevin Van De Velde, Tim Donohue, Andrea Schweer, Mark Wood, Graham Triggs, Mark Diggory, Hardy Pottinger, Peter Dietz
Primary Discussion topics:
- Filling out / Approving the #Actionable Takeaways list below
- Helping new Developers / Users get started (brief discussion)
- Can we get some better documentation or user training in place for new users & new developers?
- Put some basic install instructions up on GitHub too (once we migrate – which seems definite now)
- Advanced Embargo Feature
- Being talking about at the next DCAT meeting to make sure it meets community requirements
- Committers should discuss in more detail in future as well – possible 3.0 feature.
- Higher Level Discussion of what encompasses "DSpace"
- This began on Dabbleboard whiteboard but ran into some technical issues (multiple editors at same time cause it to get confused).
- General Goal: Simplify the 'dspace-api' module! As much as possible it really should just be the DSpace Data Model / Kernel. There are many "pieces" that should be refactored out of 'dspace-api' in future (hopefully as part of Modernized DSpace work)
- Things that could/should be refactored out of 'dspace-api':
- Content Manipulation (Curation Tasks) -> includes both curation tasks themselves and MediaFilters (which likely should be rewritten as Curation tasks anyways)
- Ingesters/Disseminators -> includes both packagers and crosswalks
- Usage Statistics (it's already separate in Solr Stats)
- External Identifier Services (ala Dryad – see below)
- Versioning Services (ala Dryad)
- Usage Event Services?
- Search / Browse API (already separate in Discovery)
- Dryad Project codebase
- Dryad has already built both versioning and identifier services (e.g. DOI) into DSpace!
- Versioning
- Example: Version 1, Version 2 of same document (see versions listed at bottom of page)
- Codebase: https://dryad.googlecode.com/svn/trunk/dryad/dspace/modules/versioning/
- Identifier Services:
- Example: The same document can be accessed via different identifiers: DOI link (http://dev.datadryad.org/resource/doi:10.5061/dryad.1385.2
), Handle link (http://dev.datadryad.org/resource/info:hdl/10255/dryad.36265
), default DSpace Link (http://dev.datadryad.org/resource/10255/dryad.36265
)
- Codebase: http://code.google.com/p/dryad/source/browse/trunk#trunk%2Fdryad%2Fdspace%2Fmodules%2Fidentifier-services
- Example: The same document can be accessed via different identifiers: DOI link (http://dev.datadryad.org/resource/doi:10.5061/dryad.1385.2
- Several are highly interested in seeing these Dryad features make it into DSpace 3.0!
- Feedback on Summit
- Positive overall. Many like the voice chat (easier to cover larger topics)
- A week is too long? 3-4 days is "sweet spot".
- Maybe we should start having occasional meetings via Skype? e.g. once per month? or just "Special Topic Meetings"?
Actionable Takeaways
- REST API
- Look to replace Sakai bus implemenation with something else (Spring WebMVC?) – Unassigned (though Mark Diggory & Bojan Suzic have been discussing)
- Install REST API on http://demo
- Look to replace Sakai bus implemenation with something else (Spring WebMVC?) – Unassigned (though Mark Diggory & Bojan Suzic have been discussing)
- Install REST API on http://demo.dspace.org
(allows for more testing/visability, etc) – Unassigned (Tim can take if no one else has time)
- Create some "embed this" Javascript code that goes against REST API – (Assigned: Peter Dietz with help from others)
- "RESTFul DSpace" philosophy:
- Individual REST APIs should stay simple & not attempt to replace/rewrite any existing standards (e.g. SWORD).
- We should encourage multiple RESTful interfaces (similar to Twitter). For example, Search/Browse API may likely be separate from the basic REST API.
- We should also encourage multiple implementations (as necessary), with an eye towards choosing a "best in class".
- Discovery
- Prototype whether Elastic Search can be used as an alternative to Solr. (Assigned: Kevin Van De Velde)
- Vote on whether Discovery should become default or even "only" Search/Browse mechanism in future. (Tim & all)
- Maven Project Consolidation
- Document our new standard Maven Project structure (SWORD2 is the model). Eventually this should go under: Advanced Customisation
- Test to ensure this new consolidated structure still works well with major IDEs
- Actually consolidate existing Maven subprojects (e.g. XMLUI and JSPUI subprojects) to use this new structure (Assigned: Mark Diggory with help from others)
- Mobile Device Support
- Look to better optimize our existing UIs for mobile devices (a vague task) – Unassigned
- Andrea Schweer knows of folks who are working on making Mirage Theme more Mobile friendly. Hopefully they can give that work back, if it can be made generally useful.
- Hope that a stable set of REST APIs can let others build native client apps or mobile-tailored UIs (e.g. ClientUI project (from GSoC 2011))project (from GSoC 2011))
- Look to better optimize our existing UIs for mobile devices (a vague task) – Unassigned
- Metadata for all Objects
- Takeaways were not very specific. Just that this is important, and that there are use cases for having metadata on Bitstreams, Communities & Collections.
- Any specific takeaways?
- Business Logic API
- Bring some of the related Dryad work out into more public areas (GitHub? Wiki?) – Mark Diggory with Ryan Scherle
- Investigate whether WebMVC code could be the basis for some of the Business Logic API (Mark Diggory and many others))
- Dryad Codebase -> Possible 3.0 Features
- Dryad has several major features (Versioning & External Identifiers) that would be very flashy for 3.0. We need to start looking more closely at this work, and get a team of us working on bringing it into 3.0. (Assiged to All in coming weeks)
- Pester MarkD & @mire (in a nice way) to help get this Dryad code documented so that the Committers can begin helping to make it generalizable.
- GitHub Migration
- We will turn off the "issue tracker" as we don't want to confuse folks. We want all issues logged in JIRA.
- We likely may want to enhance the README to be more helpful / perhaps even provide some quick install hints (along with links to install docs, etc.
- Dryad has several major features (Versioning & External Identifiers) that would be very flashy for 3.0. We need to start looking more closely at this work, and get a team of us working on bringing it into 3.0. (Assiged to All in coming weeks)
- Virtual Summit itself
- Mostly positive feedback so far (Send your feedback to Tim!)
- In future, may want to hold Summit from Mon-Thurs (4 days) or Mon-Weds. The Friday meeting is harder as it ends up being Friday evening in Europe/UK & Saturday morning in NZ.
- Regularly Scheduled Summit?
- Once a year? e.g. January/February
- Twice a year? e.g. January & May/June
- Three times a year? e.g. January, May & Sept
Overview
Content Tools