Following up on this with a couple of points about RDF use in DSpace: Beyond the descriptive metadata that we usually think about (as replicated in the DWell browser) DSpace is already storing preservation data in RDF for the History (provenance) system. I've looked at that metadata with DWell and it lets me do things like plot DSpace events on a timeline view... very useful.
I also worked on a project last year to develop an RDF ontology for repository management policies, with the idea of having a distributed, federated policy management layer over DSpace and with 3rd party service providers (like persistent storage providers). Once again, viewing and editing that metadata was made easier by relying on RDF tools like Longwell. So RDF proved useful for these two cases because the metadata schemas were not standardized and needed to be flexible and extensible... very much like the situation we have with descriptive metadata. Only in situations where the metadata schemas are standard and static has it been better to go with a traditional database schema... otherwise you end up changing the schema (and the code) way to often. MacKenzie Richard Rodgers wrote: > On Thu, 2007-11-29 at 08:14 -0500, John S. Erickson wrote: > >> Richard Rodgers wrote: >> >>> (1) There is a lot of metadata in DSpace (and a lot more to come) that is >>> not related to user discovery (technical metadata, e.g) - this could live >>> in a triple store - but would not benefit from it. In fact, a lot or >>> record-based metadata is accessed much more efficiently in a RDBMS. >>> >> 1. From an architectural standpoint, doesn't a triple store (in theory) >> make it fundamentally easier to deal with a diversity of metadata types, >> *especially* technical metadata --- which can vary not only between >> formats but even between instances of a given format, depending upon the >> applications that have modified the bitstreams? >> > > Yes absolutely, but what I was trying to question was the 'grand > unification' assumption I think gets made implicitly or explicitly in > these discussions: i.e. that there has to be a single way DSpace > represents and manages all its metadata. Since RDF is so > general/powerful, it always looks like the prohibitive favorite if > framed in these terms. > > I picture a continuum - which ranges from completely 'dark' metadata > living only in an AIP in the asset store (recoverable, of course) to > highly visible discovery metadata - with copies in Lucene, a > triple-store, Google caches, etc. and cases in between involving > collection management. Where Longwell/RDF shines is the case where such > heterogeneous metadata needs to be combined for a particular discovery > purpose. > > Now as Christophe pointed out, the trick is to manage this spectrum > without excess system complexity, and too many moving parts. > -- MacKenzie Smith Associate Director for Technology MIT Libraries ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
