Time/Place

This meeting is a hybrid teleconference and IRC chat. Anyone is welcome to join...here's the info:

Attendees

Agenda

  1. Release status: 3.8.0
  2. Java client API
  3. JCR/XML filesystem path
  4. Marking objects for deletion
  5. ...

Minutes

  • Fedora 3.8.0
    • Almost ready for Release Candidate
      • Waiting on PostGres driver issue posted on the list
    • Please participate in RC testing
  • Java client
    • Longshou working on resource implementation
      • Nearly done
    • Esme nearly done but may need more work next week
  • JCR/XML filesystem path
    • Asynchronously persisting human-readable repository objects in JCR/XML on the filesystem
    • Translating repo hierarchy into filesystem hierarchy
    • RDF relationships are not represented in this hierarchy
    • Do we need to encode the characters in the URL?
      • e.g. swap all : with \ (effectively creating a new directory)
      • What happens with things like PIDs?
  • Marking objects for deletion
    • Currently, deleting an object puts it into the trash and then ModeShape permanently removes it as part of a cleanup process
    • Maybe we should define a predicate for statuses in the repo
      • Delete, inactive, etc.
      • It will be up to the application layer to define how these statuses affect behaviour for users

8 Comments

  1. Stefano Cossu

    Sorry I didn't make it to the deletion discussion. We have been discussing about it internally. 

    From a Fedora REST API standpoint I would expect a DELETE command to hard-delete the record as it does now. A middle layer could implement a DELETE method that performs a soft-delete (i.e. mark record as deleted) instead.

    As for assigning a 'deleted' status, it would be useful to add a 'fcrepo:status' property to the fedora:resource CND. This can be either a numeric value that adheres to a global convention (e.g. we use 0 for disabled, 1 for active, 2 for hidden, -1 for deleted, -2 for invalid, etc.), or a URI reference to a node in the repo that represents a status with a label, a unique value, etc.

    Either way, XACML policies can be built to define who has access to invalid, disabled, deleted nodes etc. This solution is pretty flexible for us. 

    Thoughts?

    1. Andrew Woods

      Thanks for the input, Stefano Cossu.

      Your description is the approach we have landed on as well, with a slight clarification on the value of the fcrepo:status property. Those values will be URIs as opposed to literals. There will be a few Fedora-defined URIs for values such as "inactive", "deleted", etc which will be added to the Fedora ontology. You will, of course, be able to define your own URI values for the fcrepo:status property as well.

      1. Stefano Cossu

        Is there a ticket for this? 

        What are the foreseen core status types that will be implemented? A/D/I as in Fedora3?

        1. Andrew Woods

          Here is the placeholder ticket: https://www.pivotaltracker.com/story/show/54611050

          We have not yet defined the URIs or the internally recognized status types yet, however. Are these definitions something you are presently wanting/waiting-on?

          1. Stefano Cossu

            Thanks for the placeholder ticket, Andrew Woods. Do you want me to fill in the details from this conversation?

            It is not mission critical, but we are implementing our status types and I would like them to be an extension of the Fedora definitions. 

            1. Andrew Woods

              Stefano Cossu, It would be great if you populated this pivotal ticket. Thanks.

  2. Ralf Claussnitzer

    +1 the idea of a "deleted" state. This state can also appear on the OAI-PMH interface when OAI deletion strategy is set to "persistent". http://www.openarchives.org/OAI/openarchivesprotocol.html#DeletedRecords

    The F3 admin tool has a "purge" function for technically removing a record completely. I think its practical to make this distinction.

  3. Fulgencio Sanmartín

    +1 to the whole idea of fcrepo:status as described by Stefano - it was something existent in Fedora v3.x, see FOXML 1.1:

    http://fedora-commons.org/definitions/1/0/foxml1-1.xsd

    <xsd:simpleType name="stateType">
      <xsd:restriction base="xsd:string">
        <xsd:enumeration value="A"/>
        <xsd:enumeration value="D"/>
        <xsd:enumeration value="I"/>
      </xsd:restriction>
    </xsd:simpleType>

    We use the "I" (inactive) for the embargo, and it would be very useful to keep it, and would ease the migration 3>4.

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.