Versions Compared

Old Version 5

changes.mady.by.user Thomas Bernhart

Saved on

compared with

New Version 6

changes.mady.by.user Thomas Bernhart

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Added notes

...

  1. OAI-PMH design meeting
    Open question: start on base of an exisitng OAI-PMH implementation for Fedora 4, 5 or 6
    next step: start to create tickets to actually plan work
  2. Future of Technology Info Gathering Sessions
    Registration open: https://fedora.lyrasis.org/fedora-technology-needs-you/
    2 groups: new/future users, existing Fedora 6 implementers. Registration is necessary!
    Open for core administrators as well as people working with Fedora.
  3. RDF fixity
    Jira
    serverFedora JIRA
    serverId1fe6d535-c432-380f-b5c0-a7d3b2940ea4
    keyFCREPO-2253
    problem
    Problem: checksum depends on serialization format
    what What canonical representation to use to compute the checksum? Proposed by Quinn Hart: https://www.w3.org/community/reports/credentials/CG-FINAL-rdf-dataset-canonicalization-20221009/
    What should be included in the checksum? Proposal: ? Only user-added triples? Server-managed triples as well?
  4. Meaning of deletions (of a resource? of a tombstone? deletion of archive groups?) in Fedora 6
    Deleting a resource → data is only marked as deleted in OCFL
    Deleting the tombstone → the OCFL object is actually deleted (except if it's part of a archival group, then it would still be available in a older version of the archival group).
    Quinn proposes some changes to how deletion within archival groups works.
    Discussion: Recover a deleted object from a tombstone by adding a special header to a PUT request to tombstone?
    Next steps: Jared Whiklo  will create 3 tickets to track the discussion
    Would it be a breaking change to introduce this behaviour? Do we have to wait for Fedora 7?

Migration Updates: skipped

Updates on:

  1. Open Tickets (but assigned in some cases):
    Additional ticket:
    Jira
    serverFedora JIRA
    serverId1fe6d535-c432-380f-b5c0-a7d3b2940ea4
    keyFCREPO-3864
    seems like something that can be solved.
  2. In Progress and older but still relevant open tickets:
    Only some tickets were discussed briefly
  3. In Review:
    Jira
    serverFedora JIRA
    serverId1fe6d535-c432-380f-b5c0-a7d3b2940ea4
    keyFCREPO-3839
    waiting for feedback from government group