Page History

...

The following topics were offered for further discussion: Metadata, Auth (both N and Z, presumably), XMLUI Repository, i18n, Configurable Submission. Taking the topics in order, the discussion around "metadata" (generally understood to mean the concept of "metadata for all objects") was lively, and seemed to hover closer to the need for a better definition of what "metadata for all" really means. Richard Rodgers discussed his MDS work, where it's clear that the existing metadata system can easily be extended to apply to all DSpace objects. Richard acknowledged that there's some question and need for further discussion whether this is "good enough" to serve the use cases envisioned for "metadata for all?" Some stumbling blocks for acceptance of this approach would be the current state of date handling in the code base, and the "simple" or "flat" metadata approach may not be as expressive as necessary. At least one committer declared there is value in simply extending the existing design to all objects, citing the usefulness of a consistent interface. Richard Rodgers then asked what the status of the DCAT recommendation for out of the box metadata schemas might be. Bram Luyten offered that DC was the clear winner, just from a skimming of the results. Amy Lana pointed out that DCAT is still evaluating the survey results. Mark Diggory urged caution before proceeding, since a recommendation from DCAT is still in the works. Richard Rodgers asked whether DCAT should also consider recommending a migration path from the existing model to their recommendation.

There was also a discussion of the need for better integration of controlled vocabularies and identifier systems, such as ORCID. There appeared to be consensus that integration with ORCID would be a clear win for the vast majority of DSpace repositories given that most are focused on people.

Configurable submission was the next topic tackled, Elin Stangeland is keenly interested, but says that things appear to be a bit messy: DCAT has a wiki page up for discussing/prioritizing, there was a Google Summer of Code project on the topic, Robin Taylor adapted some of the code from GSoC and put it into a patch, but only added the back-end code, not the interface work (nodding heads from many committers in the room), MIT is working on Context-guided ingest. Elin stated, and there seemed to be agreement, that what is needed is a developer to champion and make sense of the state of the work. Robin offered to take the topic up with the committers. Bram cautioned that "use cases are important for this feature," especially how one actually customizes the workflow (i.e. via a config file, or a web-based interface).

A number of "repostiory" ideas were discussed next, an XMLUI "theme garden" has long been on the wish list, and now add to that a curation task and SWORD package garden/repository. From the discussion, it seems like GitHub can handle the actual code storage handily, it's just an issue of discoverability. The wiki may work OK for this task. Richard asks "who takes the lead?" on implementing this idea? The consensus seemed to be that we should push the community to use the wiki at first and that as the number of shared themes, etc grows we should revisit a more formal strategy.

Wrapping up before lunch, a final question: "how do we deprecate code?" Do we need a formal process, with a comment period? It's a good question, but we're all hungry, something to think on in the weeks to come.

...