1 / 38

Service Providers: Future Perspectives

Service Providers: Future Perspectives. Michael L. Nelson Old Dominion University Norfolk Virginia, USA mln@cs.odu.edu http://www.cs.odu.edu/~mln/. 2003 PSP Annual Conference Washington DC February 5, 2003. Outline. The flavor of OAI-PMH talks

iliana
Download Presentation

Service Providers: Future Perspectives

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Service Providers: Future Perspectives Michael L. Nelson Old Dominion University Norfolk Virginia, USA mln@cs.odu.edu http://www.cs.odu.edu/~mln/ 2003 PSP Annual Conference Washington DC February 5, 2003

  2. Outline • The flavor of OAI-PMH talks • Some traditional public service providers • Why the OAI-PMH is not important • Defining the OAI-PMH data model • Abusing the OAI-PMH data model • Current and nearly-current interesting services

  3. OAI Open Day, Washington DC 1/2001 2nd OAI Workshop CERN 10/2002 4 5 0 1 11 4 6 1 Protocol definition, development tools DPs, retrofitting existing DLs SPs, new services Socio-Economic- Political Issues OAI-PMH Meeting History

  4. Shift of Topics • From the protocol itself, supporting & debugging tools and how to retrofit (existing) DLs… • …to building (new) services that use the OAI-PMH as a core technology and reporting on their impact to the institution/community

  5. NTRS • http://ntrs.nasa.gov/ • metadata harvesting replacement for http://techreports.larc.nasa.gov/cgi-bin/NTRS • previous NTRS was based on distributed searching • hierarchical harvesting • (nigh) publicly available

  6. Arc • http://arc.cs.odu.edu/ • harvests all known archives • first end-user service provider • source available through SourceForge • hierarchical harvesting

  7. NCSTRL • http://www.ncstrl.org/ • metadata harvesting replacement for Dienst-based NCSTRL • based on Arc • computer science metadata

  8. Archon • http://archon.cs.odu.edu/ • physics metadata • based on Arc • features: • citation indexing • equation-based searching

  9. Torii • http://torii.sissa.it/ • physics metadata • features • personalization • recommendations • WAP access

  10. iCite • http://icite.sissa.it/ • physics metadata • features • citation based access to arXiv metadata

  11. my.OAI • http://www.myoai.com/ • covers all registered metadata • features • result sets • personalization • many other advanced features

  12. Cyclades • http://www.ercim.org/cyclades • scientific metadata • features • personalization • recommendations • collaboration • status?

  13. citebase • http://citebase.eprints.org/ • arXiv metadata • citation based indexing, reporting

  14. OAIster • http://oaister.umdl.umich.edu/ • harvests all known archives

  15. Public Knowledge Project • http://www.pkp.ubc.ca/harvester/ • domain-specific filtering of harvested metadata (?)

  16. Perseus • http://www.perseus.tufts.edu/ • they claim to harvest all DPs, but only humanities related DPs appear in the pull down menu

  17. Others… • Commercial publishers • American Physical Society (APS) • Institute of Physics • Elsevier / Scirus (www.scirus.com) • Department of Energy • OSTI • LANL • Institutional servers • DSpace (MIT; www.dspace.org) • Eprints (www.eprints.org) • DARE (All Dutch universities)

  18. Service Providers • It is clear that SPs are proliferating, despite (because of?) the inherent bias toward DPs in the protocol • easy to be a DP -> many DPs -> SPs eventually emerge • hard to be a DP -> SPs starve • currently 5x DPs more than SPs • SPs are beginning to offer increasingly sophisticated services • competitive market originally envisioned for SPs is emerging

  19. OAI Inside Why The OAI-PMH is NOT Important • Users don’t care • OAI-PMH is middleware • if done right, the uninterested user should never have to know • Using OAI-PMH does not insure a good SP • OAI-PMH is (or is becoming) HTTP for DLs • few people get excited about http now • http & OAI-PMH are core technologies whose presence is now assumed

  20. Other Uses For the OAI-PMH • Assumptions: • Traditional DLs / SPs will continue on their present path of increasing sophistication • citation indexing, search results viz, personalization, recommendations, subject-based filtering, etc. • growth rates remain the same (5x DPs as SPs) • Premise: OAI-PMH is applicable to any scenario that needs to update / synchronize distributed state • Future opportunities are possible by creatively interpreting the OAI-PMH data model

  21. set-membership is item-level property resource all available metadata about David item Dublin Core metadata MARC metadata SPECTRUM metadata records OAI-PMH Data Model item = identifier record = identifier + metadata format + datestamp

  22. Typical Values • repository • collection of publications • resource • scholarly publication • item • all metadata (DC + MARC) • record • a single metadata format • datestamp • last update / addition of a record • metadata format • bibliographic metadata format • set • originating institution or subject categories

  23. Interesting Services • DP9 • gateway to expose repository contents in HTML suitable for web crawlers • Celestial • OAI “cache”, also 1.1 -> 2.0 converter • Static (mini-) repositories • XML files, based on OLAC work • OpenURL metadata format registries • record = metadata format

  24. DP9 Architecture see Liu et al., JCDL 2002; http://dlib.cs.odu.edu/dp9 Slide from Liu

  25. Celestial • Developed by Brody @ Southampton • http://celestial.eprints.org/ • designed to complement DP9 • see Liu, Brody, et al., D-Lib Magazine 8(11) • Where DP9 is a non-caching proxy, Celestial caches the metadata records • can off-load work from individual archives, higher availability • can harvest 1.1, 2.0; exports in 2.0

  26. “Static” Repositories • Premise: a repository does not wish to have an executing program on its site, so it has a “static” XML file with some of the OAI-PMH responses in place • accessed through a proxy • could be a low functionality node, or the XML file could be produced by a process and moved outside a firewall • http://lib-www.lanl.gov/~herbertv/papers/jcdl2003-submitted-draft.pdf • Based on OLAC work by Bird & Simons • http://www.language-archives.org/

  27. OpenURL Metadata Registry • Registry of metadata formats for OpenURL • http://www.sfxit.com/openurl/ • Van de Sompel & Bergmark, DCADL02, http://lib-www.lanl.gov/~herbertv/papers/icpp02-draft.pdf

  28. Conclusions • DPs continue to proliferate • and spawn SPs! • SPs are / are becoming a competitive market • e.g., at least 10 different interfaces to arXiv metadata • growing sophistication of services • differentiation of SPs will be on features that have little to nothing to do with OAI-PMH

  29. Conclusions • Protocol / transport gateways • Dienst <-> OAI • DOG, http://www.cs.odu.edu/~tharriso/DOG/ • Z39.50 • ZMARCO (UIUC) • SOAP • prototypes @ VT (Suleman) & ODU (Zubair) • WebDAV/DASL • resurrect DASL?

  30. OAI-PMH Will Have Arrived When: • general web robots issue OAI-PMH verbs • …DP9 will no longer be needed • requires shift in “control”: harvester or repository? • mod_oai is developed and is included in the default Apache configuration • OAI-PMH fades into the background • similar to TCP/IP, http, XML, etc.

  31. Backup Slides

  32. Repositories… • Stretching the idea of a repository a bit: • contextually sensitive repositories • “personalization for harvesters” • communication between strangers, or communication between friends? • OAI-PMH for individual complex objects? • OAI-PMH without MySQL?! • Fedora, Multi-valent documents, buckets • tar, jar, zip, etc. files

  33. Resource • What if resource were: • computer system status • uptime, who, w, df, ps, etc. • or generalized “system” status • e.g., sports league standings • people • personnel databases • authority files for authors

  34. Item • What if item were: • software • union of versions + formats • all forms of metadata • administrative + structural • citations, annotations, reviews, etc. • data • e.g., newsfeeds and other XML expressible content • metadataPrefixes or sets could be defined to be different versions

  35. Record • What if record were: • specific software instantiations / updates • access / retrieval logs for DLs (or computer systems) • push / pull model inversion • put a harvester on the client behind a firewall, the client contacts a DP and receives “instructions” on how to submit the desired document (e.g., send email to a specified address)

  36. Datestamp • semantics of datestamp are strongly influenced by the choice of resource / item / record / metadataPrefix, but it could be used to: • signify change of set membership (e.g., workflow: item moves from “submitted” to “approved”) • change datestamp to reflect access to the DP • e.g., in conjunction with metadataPrefixes of “accessed” or “mirrored”

  37. metadataPrefix • what if metadataPrefix were: • instructions for extracting / archiving / scraping the resource • verb=ListRecords&metadataPrefix=extract_TIFFs • code fragments to run locally • (harvested from a trusted source!) • XSLT for other metadataPrefixes • branding container is at the repository-level, this could be record- or item-level

  38. Set • sets are already used for tunneling OAI-PMH extensions (see Suleman & Fox, D-Lib 7(12)) • other uses: • in aggregators, automatically create 1 set per baseURL • have “hidden” sets (or metadataPrefix) that have administrative or community-specific values (or triggers) • set=accessed>1000&from=2001-01-01 • set=harvestMeWithTheseARGS&until=2002-05-05&metadataPrefix=oai_marc

More Related