...

One of the major questions that Asger's presentation provoked was whether versioning was still important to do at the datastream level, or whether it can be done at the object level.  We had a follow-on discussion about this.  The idea presented was: What if Fedora no longer held information about old versions in the DigitalObject class and in the stored FOXML?  In other words, these would be designed to work only with the current version of the components of the object.  If a datastream changed, a new version of the entire object would be made (and object-level version number would be incremented), and older versions of the datastreams would be retained only if storage was configured to do so.  While discussing this, one concern we landed on was that there would no longer be a manifest pointing to all versions of everything stored within an object.  We cut this portion of the discussion short in the interest of time.  Action: Continue this discussion with others in the Fedora community (wiki page, mailing list, etc)

To drive the high level storage work forward, we identified:

...

Semantic Web and Linked Data

Steve presented his latest thoughts on improving SemWeb and Linked Data support in Fedora.

• Steve's presentation

We did not have much time to discuss with the group, but the following ideas seemed well recieved and worth persuing immediately:

• Deprecate "Lite" APIs
• HTTP URIs for RI queries: new parameter: scope = local|global, where local scope is vs. "info:" uris, and global scope is vs. "http:" uris (translated on the way in and out)

Steve also touched on the following ideas, which need some more experimentation/specification:

• Storing quads vs triples: Each object's triples are in a graph.  Performance? Compatibility w/multiple triplestores?
• Graph hierarchy: Does it make sense to have addressable graphs for each datastream as well?  Or just per-object.  Advantages/disadvantages.
• Declarative specification of which datastreams/triples to index.
  • Could be driven on a per-cmodel basis.
  • For base triples, system object methods might specify which triples to "generate".
• REST API for PUT/POST/DELETE of triples on a per-object basis.  Interestingly, this could allow for RDF management without the requirement that an index is present.  We discussed at which endpoint this logically fits: object/datastreams/datastream (straightforward to figure out where triples are stored), or object (can be figured out in some cases, but hard in other cases)

To drive this work forward, we identified:

• Lead: Steve
• Contrib: Asger, Ben
• Possible Contrib: Paul Gearon

WebDAV (or not..)

Kai led a discussion on having a WebDAV interface for Fedora.  One of the major motivating use cases was to have an easy way to ingest content into the repository.

We talked about the fact that WebDAV might not actually fit the bill here because OS-level clients (what most people would presumably be using for the "easy drag and drop case") are generally not that great.  OSX likes to do unnecessary locking for all writes.  Windows' client has been poorly supported for some time as well.

During the discussion, an alternative idea came up: If we want an easy drag-and-drop interface for the repository, how about ftp:?  OS clients' support for FTP is generally very good, and clients and servers already exist for FTP.  So the real problem for us is simplified to: How do you turn a directory full of files into Fedora objects?

This elicited a positive response from the group, especially for the simple "Drag and Drop" ingest scenario.

• Develop a "drop box" module for the Fedora server, which scans a directory periodically and when new items come in, wraps them and ingests them as Fedora objects.  This would be a prototype initially, and wouldn't have to be developed as part of the core.

Another idea that came up was that of a "live box", where content doesn't actually get moved out of the directory it's placed into, but is pointed to as a kind of "in-place" ingest.  We just scratched the surface of this latter idea.

To drive this work forward, we identified:

• Lead: Kai
• Contrib: Dan

Agenda

Tuesday

...