Date: Thu, 28 Mar 2024 16:17:39 -0400 (EDT)
Message-ID: <1376345218.28850.1711657059052@lyrasis1-roc-mp1>
Subject: Exported From Confluence
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="----=_Part_28849_282396939.1711657059052"
------=_Part_28849_282396939.1711657059052
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Location: file:///C:/exported.html
DSpace Developers Virtual Summit (Feb 27 to Mar 2)
Why a=
"Virtual Summit"?
We've often heard feedback that DSpace Developers just don't get enough =
time to sit down (face-to-face or otherwise) to discuss larger topics or br=
ainstorm out future ideas for the DSpace platform. Our weekly DSpace Develo=
pers Meetings just don't allow for enough time to dig deeply into big topic=
s, and there is sometimes a limit to how much we can discuss via text chat =
(IRC). Often the only time we are able to discuss larger topics in detail a=
re at the Open Repositories (OR) conference.
The idea is that this "Virtual Summit" will be a form of DSpace "unconfe=
rence", bringing developers around the world together in a virtual fashion =
via either audio or video technology. Those in attendance will decide the t=
opics, but we have provided some suggested "hot topics" (which have come up=
frequently in the past) below.
All discussions will also be fed back to the general public. We'll take =
notes and send those notes back to everyone on dspace-devel listserv. This =
allows for non-attendees to also provide feedback throughout the Summit (an=
d afterwards).
If all goes well, we may hold these Virtual Summits a few times a year. =
We also could brainstorm whether it'd be possible to hold a "Virtual Hack-a=
-thon" to rapidly develop/prototype out ideas that were brainstormed during=
the Summit.
Who is invited?
- All Committers,
- Any other interested DSpace developers or technology-savvy individuals<=
/li>
At least initially, this summit is geared towards developers, as discussion will primarily revolve around the existing codebase &a=
mp; internal architecture. However, discussions from this summit will be fo=
rwarded out to the community for broader feedback at all levels (repository=
manager, user, developer, etc.).
If you don't fall into one of the above categories, you are still welcom=
e to attend. However, be warned that discussion will likely get very techni=
cal at times (which is why we recommend you be a developer or have a techno=
logy background).
Logistics
- When: Meetings will happen daily starting at 20:00UT=
C and last for 1-2 hours apiece. _We will attempt to keep discussions t=
o about 1 hour in length. But, if topics run over and people have time to c=
ontinue, we may extend beyond that.
- Where:
- Call in via Skype or Phone line - See #Connection Instructions below
- In addition, #duraspace IRC will be utilized as a discussion "backchan=
nel" =E2=80=93 to share links to current discussion topics/ideas, and poten=
tially even take notes.
- Attendance Limit: None.
- Daily Notes: Each day we will have a notetaker. Simila=
r to OR11, we may wish to take notes publicly via IRC or PiratePad. Mee=
ting notes will be sent to 'dspace-devel' listserv after each meeting, in o=
rder to allow for broader community feedback.
Connection In=
structions
You can call in via either Skype or via your Phone. This call will be au=
dio-only. We will also use the #duraspace IRC as a discussion "backchannel=
" (to share links, etc.)
Via Phone:
- Dial-in Number: (805) 399-1200=20
- Participant Code: 929807#
Via Skype:
- Search and Add Contact: "freeconferencecallhd.8053991200"=20
- Copy and paste freeconferencecallhd.8053991200 (the entire name) into y=
our contact search area
- add as a contact
- After freeconferencecallhd.8053991200 is listed in your contact list, s=
imply call that contact.
- Enter the participant code through the Skype keypad (not by just typing=
in the numbers on your keyboard): 929807# (you will prompted to add the # =
sign).=20
- Mac Users: The Skype Keypad can be found at the top of your call window=
(look for the little phone keypad icon).
- Windows Users: The Skype Keypad is unfortunately hidden under the
Call -> Show Dial Pad
menu
- Linux Users: The Skype Keypad can be found at the bottom of your call w=
indow (look for the little phone keypad icon).
More info on Skype connections also available at: http://www.freeconferencecallhd.com/skypeinstructions.html=
a>
Potential =
Discussion Topics
The following topics are just possible topics we may wish to discussion.=
Topics need not be limited by this listing, and others can feel free to ad=
d topics they feel may be important.
In no particular order:
- What may a "Common Business Logic API" look like? Can we build an API t=
hat makes it easier for new DSpace UIs to be built?
- Are there ways we could simplify DSpace ("Do one thing and do it well")=
? This could be at any level (Object Model, API, User Interface, etc.)
- How could we move towards "Metadata on All Objects" (i.e. Not just meta=
data for Items, but also for Bitstreams, Communities & Collections)?
- What other ways can we start to "Modernize" DSpace at all levels (Objec=
t Model, API, User Interface)?=20
- "App Store" or "Sharing Code": How do we work to better share custom co=
de like custom curation tasks, themes, etc. amongst those in our community?=
- "DSpace Virtual Hack-a-thon": Could there be a way to hold a virtual ha=
ckathon, as a way of rapidly prototyping/developing out ideas in the span o=
f a week or two?
- How to manage ongoing translations of DSpace? This has become harder &a=
mp; harder as we have increased the number of messages.xml files (Discovery=
, SWORD Client, etc).=20
- Should we rethink this direction or look towards Translation Management=
software, like Pootle (doesn't work for XML me=
ssages though) or similar.
- Authentication/Authorization review:=20
- More dynamic permission resolution.
- Centralize decision making for more consistent results across different=
interfaces.
Summit Meeting No=
tes
Day #1 Notes (Feb =
27)
Attendees: Kevin Van De Velde, Graham Triggs, Peter Dietz, Andrea Schwee=
r, Kim Shepherd, Hardy Pottinger, Mark Wood, Tim Donohue
Primary Discussion topics:
- Interaction/Code Share via GitHub.=20
- Can we come up with some best practices for forking GitHub, so that we =
can all start to share code more easily? I.e. allow institutions to pull in=
code from one another, etc.
- We may need to spend some time developing some GitHub best practices.=
li>
- We should also leverage Maven to obviously create separate GitHub proje=
cts for features that can just extend DSpace API, etc.
- Business Logic API discussion led into talking about REST API as a pote=
ntial area for this "common business logic"
- REST API - Who is using it? What should it do, and how should it intera=
ct with SWORD / Solr / etc.=20
- No one in attendance is using REST API in Production (though a few have=
used it for development)
- We should try and "show it off" more by writing some simple Javascript =
"embed" code to embed DSpace Content in a website. We can post that code up=
to http://demo.dspace.org and enable the REST API there. This could a=
lso allow for more testing.
- REST API should never create its own 'conventions' for=
common tasks. Rather it should use existing standards (e.g. SWORD for depo=
sit, etc)
- Question: Should REST API "wrap" things like SWORD & Solr (which ca=
n be accessed RESTFully themselves)? Could "RESTFul" DSpace just be a combi=
nation of SWORD + Solr + Admin REST API + other RESTFul interfaces?=20
- Several in disagreement here. Pros/Cons to various approaches
- Fedora actually has a separate REST API from Browse/Search. You Browse/=
Search via RSearch, and then lookup an item by ID via REST API. This approa=
ch allows you to simplify the REST API to very specific tasks, and use othe=
r existing services/interfaces where they are more 'standard' or widely acc=
epted.
- However, AuthZ may be simplified if you 'wrap' everything (even with a =
thin wrapper).
- Also if you 'wrap' the Search/Browse in REST API, then at a later time =
you could swap out Solr (or whatever) for something like Elastic Search, an=
d your clients would not need to change.
We took notes via IRC. So, the full notes are up in IRC chatroom: http://irclogs.duraspace.org/index.php?date=3D=
2012-02-27
Day #2 Notes (Feb =
28)
Attendees: Kevin Van De Velde, Mark Wood, Andrea Schweer, Richard Rodger=
s, Scott Phillips, Mark Diggory, Hardy Pottinger, Peter Dietz, Tim Donohue<=
/p>
Primary Discussion topics:
- Revisiting REST API Discussion=20
- Seems to be an assumption that we should only have one=
REST API
- No reason why we cannot have multiple APIs, or even different implement=
ations (and let the best one win out in the end)
- Revisiting whether one REST API should 'wrap' all calls (several questi=
on this). Tim noticed Twitter (and many other sites) have many many REST AP=
Is=20
- https://dev.twitter.com/docs - Twitter specifically has a ba=
sic REST API, Search API, Streaming API, etc. They even do OAuth / AuthZ vi=
a REST API.
- Comments from Bojan Suzic (via dspace-devel):=20
I think this is a good idea. In some cases Twitter has multiple APIs for=
the reason of different underlying architecture and techical implementatio=
ns. The other reason could be an iterative evolution of their services and =
infrastructure. In the case of DSpace - maybe this point could be considere=
d from the functional point of view. Generally, all the REST API versions w=
ould depend on the same DSpace-API, so the rationale for separation could b=
e based on some other asumption. For instance, user-centric (browse), admin=
-centric (update) or similar, and/or based on the development effort or res=
ources necessary to carry out the change. The example for the latter may be=
an outstanding decision about future development which may hold developmen=
t/release of the component or part which is already clear and non-disputabl=
e.
- Business Logic API=20
- Can we "mature" design/modeling of the Business Logic API by thinking o=
f it more as a REST API?
- What should make up a Business Logic API:
- Item Submission processes (special ingest workflow)
- Reviewer Workflow processes
- Creation processes for Collections / Communities (also includes initial=
izing roles, template items, etc. =E2=80=93 almost like a "workflow" proces=
s to create these objects)
- Creation processes for Groups / EPeople?
- Running Curation Tasks=20
- Richard Rodgers notes he's already building a demo REST API for Curatio=
n Framework using Jersey (http://jersey.java.net/). This will be post=
ed to GitHub in near future
- Smaller Activities: User feedback, Statistics, metadata registry, bitst=
ream format registry
- Authority Control? (managing internal or external controlled vocabulari=
es & taxonomies)
- Questions / Concerns on Business Logic API=20
- Need to avoid it being too "large" / all-encompassing.
- Where do we draw the line between underlying "DSpace Business Logic" an=
d UI? E.g. Is Search/Browse part of Business Logic API? Or is it a separate=
API?=20
- Mentioned that DSpace Discovery Module has been made more generic (no l=
onger Solr specific) =E2=80=93 may be the basis for a separate "Search API"=
?
- Can we simplify? Is the "Business Logic API" just the REST API (GET/POS=
T/PUT/DELETE objects)? Or is it still more than that?
- REST API usage of Sakai bus=20
- Are we satisfied with the Sakai-based REST implementation? Sounds like =
several have concerns about complexity & ongoing maintanence
- May need to work towards a new implementation =E2=80=93 based on Spring WebMVC or something else (Je=
rsey? Apache CXF?)
- Should be able to still reuse much of existing REST AP=
I work =E2=80=93 especially the modeling of DSpace Objects as Resources bou=
nd to URLs
- Mobile Device Support - DSpace is lagging behind. How do we plan to mov=
e in this direction?=20
- Several seem interested in this, but no one known to be working directl=
y on it.
- Two levels of mobile support: (1) Making current UIs more 'mobile frien=
dly' , (2) making DSpace more RESTful to support building native apps/clien=
ts=20
- Suggestion from Bojan Suzic (via dspace-devel):=20
One approach in this direction could be based on ClientUI idea (from GSo=
C 2011). Atomization and usage of lightweight components/architecture c=
ould lead to easier and less resource intensive development, maintenance an=
d customization of UI. Also usage of cross-platform tools such as jQueryMob=
ile, phoneGap or similar (+ REST API) could provide better coverage and req=
uire a less effort.
We took notes & shared additional links via IRC. http://irclogs.duraspace.org/index.php?date=3D2012-02-28
Day #3 Notes (Feb =
29)
Attendees: Mark Wood, Peter Dietz, Tim Donohue, Andrea Schweer, Graham T=
riggs, Hardy Pottinger, Richard Rodgers, Brad McLean, Robin Taylor, Mark Di=
ggory, Stuart Lewis
Primary Discussion topics:
- Questions around DSpace w/ Fedora Inside updates.=20
- Essentially DuraSpace still highly interested in this initiative. Howev=
er, no active development going on. There have been ongoing discussions/bra=
instorms.
- DuraCloud & ReplicationTaskSuite questions=20
- Talking through how Replication Suite works with DuraCloud --> DSpac=
e generates AIPs (in either METS or BagIt packages), those get replicated t=
o DuraCloud. In your DuraCloud acct you could choose which underlying stora=
ge providers (e.g. Amazon) to use. Can use one, or even replicate across mu=
ltiple providers (or move between providers at a later time).
- Main use case is backup & restore (and helping DSpace admins to aut=
omate it as much as we can)=20
- Currently an automated backup can happen via a ReplicateConsumer which =
can queue AIPs for upload whenever something changes in the system. Still a=
work in progress though. Working on stabilizing it.
- Brainstorming some future use cases =E2=80=93 one that came up is stori=
ng high-res archival quality images/videos in Cloud (DuraCloud), and using =
DSpace for access copy.=20
- Replication Task Suite can support this as it lets you decide which Ite=
m Bundles you want included in AIPs. So, you could only include the "high-r=
es" Bundle in AIPs, and exclude any Bundle which had access copies.
- Metadata For All Objects (briefly touched on)=20
- Is the "biggest bang for buck" just Bitstream metadata (esp. preservati=
on/technical metadata)?
- No, also need for enhanced Collection & Community metadata. Some us=
e cases include:=20
- Multi-lingual Communities & Collections
- Subject Headings on Communities and Collections (as a way to more easil=
y search them or organize them)
- Bitstream metadata also very important. Especially looking towards JHOVE or DROID. Essentially, storing preservat=
ion/technical metadata about files is important.
- Richard's Modernized DSpace work allows for Bitstre=
am metadata (at least skeleton code is there).
- Question: How should Bitstream metadata be exposed via Search/Browse?=
=20
- Likely Configurable? But configuration can be difficult, if Bitstream m=
etadata is very heterogenous (different schemas, etc.)
- Discovery / Solr=20
- Discovery is working towards making facets pluggable (develop new facet=
s), also working towards making indexing pluggable.=20
- The latter (pluggable indexing) may be useful in allowing for different=
types of objects/content to be indexed in different ways =
(This goes back to question about how to index/expose Bitstream metadata)=
li>
- Big Question: Should we think about making Discovery the only S=
earch/Browse option? It would allow us to potentially simplify ind=
exing issues as we get into Metadata on All Objects =E2=80=93 since we can =
work towards one solution (Discovery/Solr) rather than mul=
tiple at once.=20
- What would this mean? Essentially we'd replace the "/search/" directory=
(old Lucene Indexes) and the DB Browse tables with Solr. All searching/bro=
wsing would use Discovery, which currently only works with Solr (but should=
be pluggable to use other underlying technologies =E2=80=93 more below)
- Some Concerns / Questions posed:=20
- Does it need to be Solr? Can't we also achieve this abstraction using j=
ust Lucene (which now has browse-based libraries), or even a Solr alternati=
ve?
- Also concerns that Discovery in DSpace 1.7 was a bit buggy (possibly ev=
en a small "step back"). However, DSpace 1.8 looks to be better. Still, Dis=
covery may need more testing to ensure it's stable & ready.
- What about JSPUI? Discovery doesn't work yet on JSPUI. Two options: eit=
her port it to work with JSPUI (there was some interest in past), or else w=
e'd have to think about deprecating JSPUI altogether.
- Discovery in DSpace 1.8 offers more abstraction. It's now more "pluggab=
le" and you could hypothetically use something besides Solr. Though Discove=
ry obviously assumes that whatever it is using has similar features to Solr=
(faceting, etc)=20
- Also worth noting that Solr Statistics can be separated from Discovery.=
They can uses entirely separate Solr instances as needed (for better scala=
bility of each).
- Seems to be some interest in consolidating browse/search around Discove=
ry. But, also several outstanding concerns (see above) that need to be answ=
ered.
- One reason to like Discovery (from Stuart Lewis): http://blog.stuartlewis.com/20=
11/08/26/the-collection-is-dead-long-live-the-collection/
- @Mire has some extra documentation about DSpace 1.8 Discovery changes i=
t will be sharing. It's imperative that we work to ensure Discovery directi=
ons are brought towards central Committer control. That way we can get the =
proper 'buy-in' to make sure we can all support it, etc.
- SkylightUI - https://github.com/skylightui/skylight
- PHP-based UI for read-only searching/browsing DSpace (built out of Auck=
land). Uses DSpace's Solr indexes (built by Discovery)
- Queries Solr directly, rather than DSpace REST API, as Solr provides na=
tive replication support.
- Essentially just goes against Solr's own REST interfaces. Uses Solr as =
a "read" API.
We took notes & shared additional links via IRC. http://irclogs.duraspace.org/index.php?date=3D2012-02-29
Day #4 Notes (Mar 1=
)
Attendees: Kevin Van De Velde, Tim Donohue, Andrea Schweer, Mark Wood, G=
raham Triggs, Mark Diggory, Hardy Pottinger, Peter Dietz
Primary Discussion topics:
- Revisiting Discovery Discuss=
ion=20
- Kevin Van De Velde volunteers to prototype Discovery + Elastic Search (=
as alternative backend to Solr). Will start up a JIRA issue & code on G=
itHub=20
- Brief discussion on migration to GitHub=20
- Detailed Discussion on Maven Project Consolidation
- SWORD2 maven project uses a different format. Itdoesn't have sub-projec=
ts for '-api' and '-webapp'. Rather, uses the capabilities of Maven to buil=
d both JAR & WAR from a single Maven module:=20
- Mark Diggory proposes we use this as a "model" Maven Project.
- Question #1: Do we want to reorganize existing Maven projects (=
XMLUI, JSPUI, LNI, OAI, etc) to consolidate the "-api" and "-webapp" projec=
ts?
- Some general questions about how this would affect user customizations =
and/or "vendor drops".=20
- NOTE: Should not affect anyone using Overlays.
- We would need to make this change clear (Documentation).
- Also would need to ensure it doesn't affect our IDEs / Development envi=
ronments (we doubt it, but needs further investigation)
- In general, most seem in favor of idea & feel it could be a simplif=
ication of our codebase.
- Next Steps (for Question #1)=20
- This new Maven project organization structure should be documented! Lik=
ely under Documentation section on Advanced Customisation
- Try out this reorganization for one of the main modules (e.g. XMLUI) an=
d ensure IDEs are not affected
- Question #2: What about Maven projects like Discovery?=
http://scm.dspace.org/svn/repo/dsp=
ace/trunk/dspace-discovery/
- Technically the "-provider" part likely may belong alongside the 'dspac=
e-api' (in some way). In addition, the "-xmlui" parts likely should belong =
alongside the "dspace-xmlui".
- This question seems directly related to whether Discovery is the "defau=
lt" or the only option for Browse/Search.
- But, in some ways, it would also help to simplify the codebase =E2=80=
=93 less maven projects =3D less confusion. It also makes sense to consolid=
ate all things related to XMLUI under "dspace-xmlui".
- Wasn't a real conclusion on this question.
- Stepping Back: Larger reorganization questions posed=20
- Should Search/Browse even be part of 'dspace-api'? Technically they are=
more UI related?
- Should we be taking a step back and conceptually thinking about what ar=
e the "pieces" of DSpace? Some possible "pieces" include:=20
- Content Model piece
- Search/Browse mechanism
- Event Manager (to pass events between pieces)
- One or more UIs
- Where does the "Business Logic API" conceptually fit into these "pieces=
"? Can better defining these pieces help us to better draw the lines betwee=
n "Business Logic API", REST API , Content Model, UI?
- Some reflection back on the DSpa=
ce 2.0 thought exercises/prototype from 3 years ago.
- Should we think about having a similar conceptual thought exercise with=
the current Committers Team (and reflect back/pull from DSpace 2.0 where i=
t still makes sense)?=20
- Idea to try and start this thought exercise tomorrow, using an =
online whiteboard like Dabbleboard
- Feeback on Virtual Summit=20
- Tim would like feedback on how this Virtual Summit has gone.=20
- Has it been worthwhile to you?
- Should we do this again? (e.g. every 6 months? every year?)
- Is the timeframe about right? One week of meetings, with about 1-1.5 ho=
urs per day (most days we've ended at about 1 hr 15 mins)?
We took notes & shared additional links via IRC. http://irclogs.duraspace.org/index.php?date=3D2012-03-01 (Starts at [20:01])
Day #5 Notes (Mar 2=
)
Attendees: Kevin Van De Velde, Andrea Schweer, Tim Donohue, Peter Dietz,=
Mark Wood, Graham Triggs, Mark Diggory, Hardy Pottinger
Primary Discussion topics:
- Filling out / Approving the #Actionable Takeaways list below
- Helping new Developers / Users get started (brief discussion)=20
- Can we get some better documentation or user training in place for new =
users & new developers?=20
- Put some basic install instructions up on GitHub too (once we migrate =
=E2=80=93 which seems definite now)
- Advanced Embargo=
a> Feature=20
- 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 =E2=80=93 po=
ssible 3.0 feature.
- Higher Level Discussion of what encompasses "DSpace"=20
- This began on Dabbleboard whiteboa=
rd but ran into some technical issues (multiple editors at same time ca=
use it to get confused).
- General Goal: Simplify the 'dspace-api' module! As muc=
h as possible it really should just be the DSpace Data Model / Kernel. Ther=
e 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 task=
s 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 =E2=80=93 see below)
- Versioning Services (ala Dryad)
- Usage Event Services?
- Search / Browse API (already separate in Discovery)
- Dryad Project codebase=20
- Dryad has already built both versioning and id=
entifier services (e.g. DOI) into DSpace!
- Versioning=20
- Identifier Services:=20
- Several are highly interested in seeing these Dryad features make it in=
to DSpace 3.0!
- Feedback on Summit=20
- Positive overall. Many like the voice chat (easier to cover larger topi=
cs)
- A week is too long? 3-4 days is "sweet spot".
- Maybe we should start having occasional meetings via Skype? e.g. once p=
er month? or just "Special Topic Meetings"?
Actionable Takea=
ways
These are final takeaways from the discussion notes above. We've tried t=
o assign these to one or more people when we could, but some are just 'phil=
osophical' takeaways (in how we plan to move the platform forward). For mor=
e details on each takeaway, see the discussion notes above.
- REST API
- Look to replace Sakai bus implemenation with something else (Spring Web=
MVC?) =E2=80=93 Unassigned (though Mark Diggory & Bojan Suzic =
have been discussing)
- Install REST API on http://demo.dspace.org (allows for more testin=
g/visability, etc) =E2=80=93 Unassigned (Tim can take if no one el=
se has time)
- Create some "embed this" Javascript code that goes against REST API =E2=
=80=93 (Assigned: Peter Dietz with help from others)
- "RESTFul DSpace" philosophy:=20
- Individual REST APIs should stay simple & not attempt to replace/re=
write any existing standards (e.g. SWORD).
- We should encourage multiple RESTful interfaces (similar to Twitter). F=
or example, Search/Browse API may likely be separate from the basic REST AP=
I.
- 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/B=
rowse mechanism in future. (Tim & all)
- Maven P=
roject 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 ma=
jor IDEs
- Actually consolidate existing Maven subprojects (e.g. XMLUI and JSPUI s=
ubprojects) to use this new structure (Assigned: Mark Diggory with help fro=
m others)
- Mobile Device Support
- Look to better optimize our existing UIs for mobile devices (a vague ta=
sk) =E2=80=93 Unassigned
- Andrea Schweer knows of folks who are working on making Mirage Theme mo=
re Mobile friendly. Hopefully they can give that work back, if it can be ma=
de 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))
- 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, Communitie=
s & Collections.
- Modernized DSpace
- This is an important project which many seem to be watching closely. Im=
portant to keep it moving forward (All of us).
- "DSpace Kernel/API" philosophy:=20
- We should strive to simplify the Kernel. It has gotten bloated over tim=
e, and we should work to separate out individual "functions" into other API=
s. This will be an ongoing process, but it falls to all of us.
- Business Logic API
- Bring some of the related Dryad work out into more public areas (GitHub=
? Wiki?) =E2=80=93 Mark Diggory with Ryan Scherle
- Investigate whether WebMVC code could be the basis for some of the Busi=
ness 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. (Assige=
d to All in coming weeks)
- Pester MarkD & @mire (in a nice way) to help get this Dryad code do=
cumented 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 e=
ven provide some quick install hints (along with links to install docs, etc=
.)
- 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?=20
- Once a year? e.g. January/February
- Twice a year? e.g. January & May/June
- Three times a year? e.g. January, May & Sept
------=_Part_28849_282396939.1711657059052--