Sword Bl 0903[1]

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

0 comments

Post a comment

    Post a comment
    Embed Video
    Edit your comment Cancel

    Favorites, Groups & Events

    Sword Bl 0903[1] - Presentation Transcript

    1. SWORD Simple Web-service Offering Repository Deposit Julie Allinson 25th March 2009, British Library
    2. SWORD Quick Introduction
      • Vision: “lowering barriers to deposit”
      • Simple Web service Offering Repository Deposit
      • Aims to provide a standard mechanism for ‘doing deposit’ into repositories
      • JISC funded project started 2007, continuation funding for SWORD 2 from June 2008
    3. What is it?
      • A lightweight protocol for deposit
      • A profile of the Atom Publishing Protocol
      • Implementations of SWORD in IntraLibrary, Fedora, DSpace and Eprints repositories
      • SWORD clients – web-based, desktop, MS Office plugin, Facebook, widgets
    4. Motivations – why?
      • no standard interface for tagging, packaging or authoring tools to upload objects into a repository
      • no standard interface for transferring digital objects between repositories
      • no way to deposit into more than one repository with one ‘click’
      • no way of initiating a deposit workflow from outside a repository system
    5. The Project Partners
      • SWORD partners:
        • UKOLN, University of Bath and University of York (Project Management) – Adrian Stevenson & Julie Allinson
        • University of Aberystwyth (DSpace, Fedora, & clients) – Stuart Lewis, Neil Taylor, Glen Robson, Richard Jones
        • University of Southampton (EPrints) – Les Carr, Seb Francois
        • Intrallect (IntraLibrary) – Sarah Currier, Andrew Robson, Martin Morrey
        • Jim Downing – standards development
    6. Use Cases
      • Deposit from a Desktop/Online tool
      • Multiple deposit - e.g. deposit to institutional and (mandated) funders’ repository with one action
      • Machine deposit - e.g. automated deposit from a laboratory machine
      • Migration/transfer - e.g. to a preservation service
      • Mediated deposit - e.g. deposit by a nominated representative, to additional repositories
    7. Scenario 1
      • A lightweight deposit web service can facilitate this transfer of object(s)
      • Librarian L completes the deposit through the repository interface
      • id
      • Librarian L invokes deposit of a surrogate into arxiv.org
      • Deposit
      • id
      • Author A deposits via an easy-deposit desktop application into the institutional repository's mediated deposit queue
    8. Scenario 2
      • A lightweight deposit web service can facilitate this transfer of object(s)
      • Deposit
      • The depositor can choose one or more repositories to deposit into
      • A depositor is required to submit to a Research Council repository, but they also wish to deposit into their institutional repository and a relevant subject repository
    9. SWORD AtomPub Profile
    10. Standards
      • WebDAV (http://www.webdav.org/)
      • JSR 170 (http://www.jcp.org/en/jsr/detail?id=170)
      • JSR 283 (http://www.jcp.org/en/jsr/detail?id=283)
      • SRW Update (http://www.loc.gov/standards/sru/)
      • Flickr Deposit API (http://www.flickr.com/services/api/)
      • Fedora Deposit API (http://www.fedora.info/definitions/1/0/api/)
      • OKI OSID (http://www.okiproject.org/)
      • ECL (http://ecl.iat.sfu.ca/)
      • ATOM Publishing Protocol (http://www.ietf.org/htmlcharters/atompub-charter.html)
    11. AtomPub
      • “ the Atom Publishing Protocol is an application-level protocol for publishing and editing Web resources”
      • benefits
        • supports many of our parameters and requirements, in particular file deposit
        • it already exists and has growing support
        • it is well-used in popular applications
        • it has an extension mechanism
        • good fit with the Web architecture
      • drawbacks / risks
        • too much of a retrofit?
        • it is designed for a single package/file OR an atom document – this means that we need to package up metadata and files
    12. SWORD AtomPub Profile
      • SWORD profile builds on AtomPub
      • Provides extensions, constraint relaxations and enforcements when:
        • Clients post compound resources (zip,tar)
        • Mediated deposit required
        • Workflows involved
      • SWORD compliance does not preclude AtomPub compliance
    13. SWORD APP Package Support
      • AtomPub uses MIME to describe resources
        • SWORD supports accepting MIME types, but
      • Inadequate for compound types e.g.
        • Zip, tar
        • METS, SCORM, MPEG21, DIDL packages
      • SWORD extends AtomPub:
        • sword:acceptPackaging element
        • Value taken from SWORD package types
        • Developing area
    14. SWORD APP Mediated Deposit
      • SWORD deposit client user may not be owner of resource
      • SWORD allows clients to set a HTTP header:
        • X-On-Behalf-Of
      • Assumes trust between owner and mediating user
      • Future development could explore OAuth for creating trust relationships
    15. More Features
      • No-Op (Dry Run)
      • Verbose Output
      • Client and Server Identity
      • Auto-Discovery
      • Error Documents
      • Nested Service Description
    16. SWORD APP Error Documents
      • SWORD adds new class of document to AtomPub to allow better error description
        • ErrorContent
        • ErrorChecksumMismatch
        • ErrorBadRequest
        • TargetOwnerUnknown
        • MediationNotAllowed
    17. SWORD Profile of AtomPub
        • Protocol Operations
          • Retrieving Service Document
          • Listing Collections
          • Creating a Resource
          • Editing/Deleting resource – not part of SWORD, optional
        • Service Documents
          • new elements: version, verbose, noOp, maxUploadSize, collectionPolicy, mediation, treatment, acceptPackaging, service
        • increasing requirement for persistent Atom Entry Documents
    18. How it Works
      • Issue HTTP requests (GET, POST) from client to SWORD interface
        • GET Service Document (explain/discover)
        • POST ATOM document or file/package to collection URI
      • HTTP response and ATOM document is returned
      • HTTP basic authentication should be supported
    19. SWORD In Use
    20. Implementations
      • Repository implementations
        • DSpace
        • EPrints
        • IntraLibrary
        • Fedora
      • Client implementations
        • command-line, desktop and web clients
        • Facebook Client
        • Deposit from within MS Word & Powerpoint
        • Feedforward / FOREsite and others
        • Java, PHP and .NET libraries
    21. Web Interface
    22. Fedora deposit
    23. Fedora Deposit response
    24. Validation
    25. SWORD in use
      • In addition to the case study implementations:
        • Feedforward has already implemented
        • ICE project is looking at SWORD
        • DSpace and EPrints installations already exist
        • Microsoft eChemistry work
        • OAI-ORE - FOREsite work
        • more are planned
      • NISO activity around deposit
      • Collaberation with Nature Publishing Group possible
      • York – funded project around SWORD
    26. More Info and Contact
      • SWORD Website:
      • http://www.swordapp.org
      • General queries:
        • Adrian Stevenson [email_address]
      • Technical queries:
        • sword sourceforge list [email_address]
    27. OAI-ORE Object Re-use and Exchange Julie Allinson 25th March 2009, British Library
    28. ORE background
      • commenced October 2006
      • stands for ‘Object Reuse and Exchange’
      • falls in the remit of the Open Archives Initiative (creators of OAI-PMH)
      • funded by the Mellon Foundation, with support from the National Science Foundation in the U.S.
      • international focus and lots of interest
      • a 2 year project, not the answer to all our problems
      • ended September 2008
    29. ORE Results
      • Primer – in heavy use for the presentation!
      • User Guides
        • Resource Map implementation in ATOM, RDF/XML, RDFa, HTTP
        • Resource Map Discovery
      • Specifications – Abstract Model and Vocabulary
      • Tools and additional resources
    30. Key terminology for ORE
      • Aggregations
      • Web architecture – resource, URI, representation, link
      • Resource Maps
      • Linked Data / Semantic Web
      • RDF
      • ATOM
      • Serialization
    31. ORE in one sentence
      • “ ORE is a serialization format for describing aggregations of Web resources”
      • (according to me)
    32. Relationship to OAI-PMH
      • OAI-ORE is NOT a replacement for OAI-PMH
      • OAI-PMH will continue to exist as one approach to interoperability
        • OAI-PMH metadata-centric
      • OAI-ORE will complement with richer functionality, when this is desirable
        • OAI-ORE is resource centric
    33. An example
      • The ForeSite toolkit
        • “ Libraries for constructing, parsing, manipulating and serializing OAI-ORE Resource Maps”
        • Demonstrator created Resource Maps of journals in JSTOR, delivered as ATOM documents via SWORD DSpace interface
    34.  
    35.  
    36. That’s it.

    + j.allinsonj.allinson, 7 months ago

    custom

    384 views, 0 favs, 0 embeds more stats

    SWORD presentation give at the British Library.

    More info about this document

    © All Rights Reserved

    Go to text version

    • Total Views 384
      • 384 on SlideShare
      • 0 from embeds
    • Comments 0
    • Favorites 0
    • Downloads 2
    Most viewed embeds

    more

    All embeds

    less

    Flagged as inappropriate Flag as inappropriate
    Flag as inappropriate

    Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

    Cancel
    File a copyright complaint
    Having problems? Go to our helpdesk?

    Categories