MikeSimpsonThoughtsDuringConference

From DSpace Wiki

ANDOM CHONOLOGICALLY-SOTED THOUGHTS OCCUING DUING THE 2004 USE CONFEENCE (as refactored at 20,000 feet, courtesy of Midwest Airlines) Metadata should probably have a separate authorization from the content. I.e. you should be able to set a switch that says, "Show the metadata for this object, but not the object itself." Another kind of record that should be attachable to a digital object should be a statistical ("usage") record -- this is different from regular metadata in the sense that it should be composed of counters that automatically update when triggered by API actions. So when the interface calls Item.display() (or whatever) the "display count" attribute gets autoincremented. These counters should be implemented at the lowest level possible (like the UNIX kernel counters for I/O, virtual memory, etc.) so that all sorts of statistical analysis can be built on top of them. Should the statistical functionality wind up as a separate module ("the Statistics API") or be part of the APIs of all modules (everything has a getCounters() call or something like that)? Actually, I think you could do all this with extensive logging plus a log analysis toolkit (i.e. Apache+Analog). It's where you want to put the overhead. Here's a concept and a vocabulary term hanging on it: "viewpoints", which are retrieval interfaces customized for specific data types (Text, Image, Audio, Video, Export). This is sort of Model-View-Controller, in that we split display from data. I suppose you should be able to request the Image viewpoint on a textual bitstream, but I'm not sure about what it should return. Should viewpoints attach only to certain levels in the object scheme, i.e. do communities need to have viewpoints? All objects are container objects. Even a "itstream" is really an abstraction of bytes plus extra information. All objects should be loosely-coupled to their containers -- maybe objects exist as non-hierarchical "pools" (bitstream pool, item pool, collection pool, community pool) and then we express hierarchy as arbitrary linkages defined between pools -- this is like a filesystem abstraction sitting on top of a physical storage device, where branches (directories) and leaves (files) are structure imposed on randomly-distributed disk sectors. etrieval interfaces should respond to (at least) two types of identifiers: something a bit more handle-ish (the "canon path") and something that reflects a (human-readable) pathway to the object through a specific hierarchy of communities/collections/etc. (the "label path"). There should be one unique "canon path" for each object, but many possible "label paths" (compare to symlinks in a filesystem). Any object should be able to be aliased into the next-higher-level set of containers: this action would create a new "label path" but not another "canon path". Maybe the original label path (the one created upon item submission?) should be privileged somehow -- the owner of that path can grant/create other paths, but no one else. Or, there's an owner of the "canon path", who can then grant/create one or more label paths with various authorization parameters upon request. I.e. an interface to send a request: "I see you are the owner of this item; I'd like to include it in my collection as well, and I'd like it to be publicly-accessible along the new label path." And then one for the reply: "The new label path has been created, and I've put this set of authorizations on it." Instead of "label paths", they could be called "alias paths". Any object should be able to have metadata records ("record objects?") attached, of various types (i.e. DC record, METS record, MAC record; but also "Collection" metadata, "Community" metadata, i.e. the information that is currently pulled off into the collection and community tables in PostgreSQL; this should be generalized and turned into a metadata record just like any other metadata). Note that being able to attach multiple records of the same schema type fixes the language issue (English DC, French DC, etc.). Metadata schemas themselves should be loadable/unloadable based on an XMLish definition file; actually any kind of registry-type information should exist in canon form in XML, which is then parsed by the loader process and turned into the appropriate internal commands (i.e. ANSI SQL) to create the necessary data structures in the metadata store. Authentication creates a session object with various "attributes" attached to it; attributes are the keys that provide authorization decisions during retrieval. Authorization should occur for retrieval of any object (communities down to bitstreams). An "authorization path" (what I called an "alias path", above) might define the sequence of authorizations that must be passed successfully to do retrieval. That does mean that different authorization paths could exist for a single object. Maybe the final arbiter is the canon path, i.e. authorization parameters set on the canon path are checked last, and override all other parameters set for the other authorization paths. I'm thinking that indexing/search functionality really has no business in DSpace, which is about archiving, browsing and retrieval. Index and search should really exist as a separate application that lives above the DSpace layer. The browse/retrieve API could of course extend useful functionality up to that service layer (i.e. OAI-PMH) but indexing and searching directly inside DSpace will always be a secondary function at best. An absolute baseline definition of "digital object": "a stream of bytes representing a discrete chunk of intellectual property." It would be nice if each defined MetadataSchema object could automagically imply an OAICAT crosswalk, if the appropriate XML mapping descriptor is available. Which is to say, there could be a "crosswalks" directory with XML files inside describing various mappings, and DSpace on startup would populate the OAI-PMH interface with the appropriate crosswalks based on the XML files that it found. etrieval limits should be able to be specified both in terms of number of records and/or size of delivered content (i.e. "give me ten records, or 100 Mb, whichever is less."). Persistent naming structures (handles, PULs, AKs) should be conceived as plugin views for the exposure and retrieval of repository content. DSpace should always maintain an internal canon identifier that can be algorithmically transformed into any of the other identifier types and exposed to harvesters et al. on demand. andom metaphor: DSpace is a hammer; we haven't even started building the cabinets yet. More vocabulary possibilities: the canon path could be called the "identification path", vs. the alias path(s) which are "authorizations path(s)" to the object in question. Another type of record that it should be possible to attach: a "licensing record". Our container objects (bitstreams up to communities, or maybe even Instances of DSpace) are starting to look like convenient abstractions composed of a persistent identifier that gives us a hook upon which to hang metadata. Which matches perfectly the DSpace fundamental questions: "Where is it?" and "What is it?" andom metaphor: individual users produce archipelagoes of knowledge. Interfaces extended to the service layer by various modules should probably express themselves (or be able to be expressed) as XML. The service layer could then search for appropriately named/identified XSLT transforms and use them for display. I.e. when you do a "retrieve" action on item "foo", using the authentication path of collection "bar" and community "bat", the service layer grabs the appropriate XML, and then applies transforms for "/bat/bar/foo", if available. Plugin modules (a la Apache) are just a fabulous design (obert Tansley's presentation). It would be EVEN ETTE if the modules were stackable, i.e. for authorization, several different modules may all be registered at startup as "interested parties" (providing the requisite API(s)). Then a call to Item.authorize() is really a set of calls falling through the stack of registered modules. Each module has a chance to either handle the call itself or decline the call, which then falls through to the next module in the stack. Apache does something almost exactly like this, I believe. Toolkits become services through the application of policies and procedures for use. Don't get confused and start burying policies and procedures inside your toolkit code. The question is never, "What can I do with Apache?" The answer is always, "Yes, I can use Apache to do that." DSpace should strive for something similar. It would be nice to consider writing "mod_dspace" for Apache, which would provide a nice interface layer down into the DSpace services. This ties Apache's down-growing roots into DSpace's up-welling springs, and lets us stick a pin in the content and answer all three questions: "Where is it? What is it? How do I get it?"