Anyway, this looks really interesting. I’d say go for it with the prototype.

Pity about the Java though. What about Java/Python interfaces, Jython…? Can you maybe code in Python and link to existing Java?

A few random thoughts:

The task here gets much more ambitious as you move it in the direction of formal curation, publishing, persistent identifiers and so on. (See Neil’s comment.) The whole federation idea is really attractive but I’ve got the feeling that as items move from the individual’s desktop to public repositories and metadata gets disseminated to federated registries, there will need to be human curation activity along the way. I’m not sure if a fully automated system will be feasible… But I can certainly imagine something that assists the individual in publishing their stuff to shared spaces, by pre-filling most of the data in the ingest forms and flagging what’s missing. But even if that bit of it is some time in the future, the repository-on-the-desktop idea seems valuable to me anyway.

For making it useful and attractive to users, I’d say the first bit of networking would be to build in automated backup to a secure location. (Synchronisation?)

You didn’t mention email. I think it would be really cool to have all my email sucked up and indexed and sorted and tagged and stored and backed up seamlessly along with all my other stuff. (Rather than it being separate.)

It’d be good also to have a simple way to go from looking at something in the repository to opening it its owner application. You’d want to be able to see it through the repository, not just metadata but content (preferably HTML-converted), but also to click through to opening it for action. Of course this raises issues around version control, not just revisions of a document over time, but also the relationship between different formats: the Word document, the PDF, the blog post HTML. Unless people are using ICE for all their writing, they’re likely to have a whole mess of different versions of everything lying around. Can a desktop repository help sort out that mess?

Sorry, that was all a bit stream-of-consciousness, hope it makes sense…

A couple of observations if I may.

The ANDS general google group is not intended to be a discussion list rather it’s there for announcements.

More importantly your latest ideas certainly resonate with my thinking.
Your Picasa like approach could indeed work but I think it should have an important component added, namely the ability to create or infer collection level RIF-CS metadata based on files organised and stored in locations/folders by the user. Another important addition would be the addition of a persistent identifier minting service. Lastly, the ability to work across local, networked and remote data stores should also be considered.

I know you use these posts to harvest ideas and stir the pot, consider your aims partly accomplished.

Cheers
Neil

Here, have some mouth-foam on me.

1. What is the scope of content? The examples you mention are music, videos, ePrints, theses, which tend to have known metadata. How would you handle defining schemas and then entry of formal metadata for arbitrary research datasets? The suggestions I gave in the Twitter discussion were attempts at pointers to ontology creation and maintenance tools, also present in Fieldhelper as you mention (and maybe Mediaflux), in other words, ways to deal with the initial stage of Rowan’s problem.

2. “We’ll start with a local installation of The Fascinator – that puts Fedora 3 and Apache Solr on your desktop.” There’s a concern that this leaves the data on the C: drive for now, and delays bringing them into a well-backed-up environment — not necessarily a “repository”, but a robust data store (like Monash LaRDS, VeRSI’s federated data store, or the ARCS Data Fabric).

3. Your last diagram has a relation to a full “data lifecyle”: see Andrew Treloar’s diagram in my presentation at #DLCsyd09 http://tinyurl.com/betk3l . This sounds as if it’s on the right track! However, a lot of flexibility for different requirements in different cases is needed (access levels for different collaborator groups; version control; …). Can you allow for these needs and keep options open, so as to avoid the risk that by building a system rapidly prior to an overall data store and national data commons context, you are fixing too many choices prematurely?