wiki:ESciDoc200810

Version 3 (modified by hyman, 16 years ago) (diff)

--

Meeting between MPIWG group & eSciDoc team members, 16-17 October, Munich

MPIWG participants: R. Casties, M. Hyman, W. Schmidle, K. Thoden, J. Willenborg

eSciDoc architecture as of 2008-10-16

  • three layers
    • common functionality
      • generalized and unified data model for all content resources
      • content modeling of resources as a specialization instrument
      • versioning
      • PID
        • currently a political problem; to be implemented really for faces etc. by year-end
      • user management, authentication and authorization
    • intermediate services (added functionality)
      • duplicate detection
      • image handling
      • metadata handler
      • validation of data
      • retrieval/download statistics
      • workflow management
    • application services (can be integrated)
      • depositing
      • publishing
      • quality assurance
      • citation manager
      • export manager
      • SearchAndOutput?
      • controlled vocabularies
  • use of Fedora
    • Fedora has its own versioning model
    • versioning model is component-level
    • no version numbers (data-based versioning)
    • core services of eSciDoc implement versioning independently
    • an eSciDoc item may be more than one Fedora object
  • three stages
    • pending
    • submitted (some quality control)
    • released (a published, valid object)
      • after release an object cannot be deleted (to ensure persistence)
  • interfaces
    • SOAP and REST

Overall evaluation

  • core eSciDoc services
    • may be of some use, but developed functionality remains unclear
    • scheduled release date for 1.0 is Q1 2009
    • missing features
      • e.g. notification mechanism (for letting us know that a relevant document has been created or modified)
    • design features & flaws
  • solutions (links below may break at any time, since they are to demo resources)
  • comments
    • partner institutions for which a solution is being developed are "privileged"
    • no public or stable repository exists yet
    • future of project is unclear
    • need to reevaluate situation in Q1 2009