Alexey, I really want to get back to you on this thread. There are a few things I've been working on around ORE that may be of benefit to you... I'll keep it brief because I can extrapolate on many of the below topics but do not have time right now....
On Dec 9, 2008, at 2:09 PM, Alexey Maslov wrote: > The Texas Digital Library has been investigating using ORE and OAI- > PMH in conjunction with handling ETDs from various schools across > Texas in a federated collection. I would like to briefly cover the > background and design that we are looking at to see if anyone has > any feedback or comments on this project. Our primary use case is: > we have several IRs across the state that have ETD collections for > their respective institutions and we would like to create a single > federated collection that aggregates those ETDs and keeps itself > automatically updated. > > Over the last several months TAMU Libraries have been following the > development of the OAI Object Reuse and Exchange (ORE) > specification. Its primary feature is the ORE Model, an abstract > data model for expressing relationships between web resources. The > term they use for such a relationship is “Aggregation” and the web > resources they describe are called “Aggregated Resources”. A > concrete representation of an Aggregation in some readable format is > called a “Resource Map”. > > Given potential of this new format for repository interoperability > and the wide adoption of DSpace in the Texas Digital Library, we are > currently looking at adding OAI-ORE support to DSpace. This would > include the capability to both disseminate and harvest ORE objects. > Our approach is as follows. > > First we need a way to disseminate ORE resource maps from a DSpace > repository. This is a two-stage problem. Step one is creating a > mapping between the DSpace architecture and the ORE data model. In > other words, generating ORE Resource maps from DSpace objects. Also > necessary was a specific serialization format to express the > abstract resource map as a concrete and usable representation. For > this we chose Atom XML. Following the documentation and examples > from the ORE specifications, specifically “Resource Map > Implementation in Atom”, the mapping was fairly straightforward to > create. I've attached an example copy of such a mapping. This is something I've been working to complete... Basically we have an addon that generates ORE RDF called dspace-rdf in t he dspace- sandbox and a few changes in the XMLUI to expose it as /metadata/ handle/xxxx/rdf.xml http://dspace-sandbox.googlecode.com/svn/modules/dspace-rdf/trunk/ and some config in the XMLUI sitemap > <!-- Theme pipeline --> > <map:match pattern="DRI/**"> > <map:mount check-reload="no" > src="aspects/aspects.xmap" uri- > prefix="DRI/"/> > </map:match> > > > <map:match pattern="metadata/**"> > > <!-- Semantic Web RDF Generation for a specific community/ > collection/item --> > <map:match pattern="metadata/handle/*/*/rdf.xml"> > <map:generate type="DSpaceObjectRDFGenerator"> > <map:parameter name="handle" value="{1}/{2}" /> > </map:generate> > <map:serialize type="rdf" /> > </map:match> And exposure of that via html link in the head of all XHTML pages: http://libstaff.mit.edu/svn/repos/distributions/dspace.mit.edu/trunk/dspace/modules/xmlui/src/main/webapp/themes/dri2xhtml/structural.xsl > > > The second part is actually disseminating the results; that is > providing the resource maps with a URI from which they can be > consistently accessed. Following the guidelines set forth in > “Resource Map Discovery” guide, we chose to simply disseminate the > ORE resource maps through existing OAI-PMH means. This entailed the > creation of an ORE/Atom dissemination crosswalk in DSpace that > served out ORE as one of the available metadata formats. In addition > to OAI-PMH, the ORE resource maps is also provided by other services > using the same crosswalk, for example Manakin XMLUI. OAI-PMH should be easy to pipe, I had started experimenting with it. But havn't added the capability yet to the dspace-rdf project. > > > Done in this fashion the dissemination aspect of ORE support does > not require any core changes to DSpace itself. The changes are > limited to a new dissemination crosswalk as well as whatever changes > Manakin and the OAI webapp needed to serve the resource maps > directly through a URI in addition to an OAI-PMH request. +1 and your welcome to join in and use any of my previous work as a starting point. > > > The harvesting aspect is more complex and requires a greater degree > of changes to core DSpace. First and foremost, DSpace needed the > ability to contact remote OAI-PMH providers and harvest data from > them. This would make a DSpace repository not just a data provider, > but potentially also a service provider under the OAI-PMH > architecture. Creation of such a harvester, and imparting it with > the ability for automatic iterative updates, entailed the addition > of a new table to the DSpace database to relate collections with > their harvesting information. > > Once a basic OAI-PMH harvester was complete, it was extended to also > function as an ORE harvester by the addition of the appropriate > ingestion crosswalk. The OREIngestionCrosswalk can parse an ORE > document, build a basic DSpace item and then fill in its metadata > and bitstreams by following the URI references in the Resource Map > and generating a secondary OAI-PMH request for descriptive metadata. > Once all these pieces were completed, their capabilities needed to > be made useable through DSpace’s interfaces, such as the command- > line interface, the Manakin UI, JSPUI and so forth. Th biggest point of irritation for myself is that the DSpace default metadata for DC has so many significant problems with it that I am forced to map the field by hand to attain some form of real and validatable DC/DCTERMS on any Item in DSpace. I've been able to setup a set of default mappings that will produce valid DC/DCTERMS, anything that falls out of this area (custom fields in the DC namespace I've set about forcing into a custom "dspace" namespace. > > > Furthermore, since we added capabilities to make the harvests > automatic and recurring, this could allow us to keep a harvested > DSpace collection “in sync” with an external DSpace collection it is > being harvested from. This is the primary use case that motivated > TDL to look into using ORE for interoperability between the many IRs > under its umbrella. The potential, however, is even greater. Because > ORE resource maps simply describe aggregations of web-accessible > resources without regard to how that access is made possible, this > could in theory allow for seamless interoperability between a DSpace > IR and any other ORE-compliant service. Yes this is a continued area of interest for me. This initial work was completed this year and I'd like to continue to extend upon it when time is available. I would highly recommend building on the work I've completed thus far I think you would be welcome to join the dspace- sandbox as a committer and take over any portion of the codebase you require. I would be highly interested is setting up a phone conference with you to chat about our common interest please feel free to contact me outside of the list to discuss this. Sincerely, Mark ~~~~~~~~~~~~~ Mark R. Diggory http://purl.org/net/mdiggory/homepage ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
