Time/Place

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

Attendees 

Agenda

  1. 4.5.1 RC-3 testing status

  2. Strange behavior of Binaries and NonRdfSourceDescriptions (see gist and comment below)
  3. Schedule special-topic meeting on Versioning Spec (pre-requisite reading: Memento spec)
  4. F4 plans for moving to Modeshape5 
  5. Release candidate policy
  6. Can we cut a release for fcrepo-build-tools
  7. Upcoming release for fcrepo-camel
  8. Thoughts on multi-tenancy
  9. ...

  10. Status of "in-flight" tickets

    key summary type created updated due assignee reporter priority status resolution

    Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Ticket Summaries

  1. Please squash a bug!

    key summary type created updated due assignee reporter priority status resolution

    Unable to locate Jira server for this macro. It may be due to Application Link configuration.

  2. Tickets resolved this week:

    key summary type created updated due assignee reporter priority status resolution

    Unable to locate Jira server for this macro. It may be due to Application Link configuration.

  3. Tickets created this week:

    key summary type created updated due assignee reporter priority status resolution

    Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Minutes

4.5.1 RC-3 testing status

  • Includes all known issues
  • No outstanding tickets for RC4
  • Sign-off from Hydra and Islandora on sanity tests
  • Still need to run through tests based on exercises we do in workshops
  • Plan to release 1 week from tomorrow
  • This release was thoroughly tested

Strange behavior of Binaries and NonRdfSourceDescriptions

  • Looks like we have agreement on expected behaviour
  • Last modified date on binary source descriptions is problematic
  • What should the behaviour be?
  • Option 1: Collapse last modified info from binary and binary description into a single value
    • Seems like a bad choice but fixes broken behaviour
  • Option 2: Keep these values separate but distinguish between HTTP representation and resource representation
  • Data from the headers is HTTP-specific: it concerns representations. Data from the body (RDF) is repository-specific: it concerns resources.
  • Note: In the event that the binary itself is changed (e.g. via a PUT operation), it is expected that all last-modified dates would change: the fedora:lastModified date in the RDF would change, since the binary was modified, as would the HTTP headers corresponding to the binary. Since the RDF in the description would change (in addition to fedora:lastModified, the premis:hasMessageDigest would also change) the HTTP last-modified header corresponding to the RDF description would also need to change (since its representation changed).
  • Should we distinguish between a change to the binary and a change to the description in the messaging framework?
    • This will require further discussion. A binary and its description are 2 different HTTP resources but different aspects of the same Fedora repository resource
    • Action: Continue this discussion at the committers meeting at OR2016

Schedule special-topic meeting on Versioning Spec

  • We will move forward with spec docs one at a time
  • Versioning appears to be ready to move forward
    • Move into Git repo and use Respec tool 
  • There are 2 options for how versions are created
    • Need agreement on this before we move forwrard
    • Option 1: Indicate that a resource should be versioned. Any updates create a new version
    • Option 2: A parallel resource is a versioning target. POSTing to that resource creates a snapshot on demand
  • Action: Andrew will send out a Doodle poll to schedule the meeting

F4 plans for moving to Modeshape5

  • Modeshape 5 has been released
  • No longer uses Infinispan
  • There is a ticket for moving to Modeshape 5
  • A migration will be required
    • A backup/restore operation is recommended
    • Fedora exposes this capability already
    • This capability will be deprecated in the future but for now it is useful
  • We will need to update configurations/dependencies and do a lot of testing
  • At what point will we support more than one release?
    • One that supports Mode4 and one that supports Mode5
    • Will we have parallel releases?
    • If the migration is smooth, we should encourage everyone to upgrade
    • If not, parallel releases may make more sense
  • Should we use Mode5 to launch Fedora 5?
  • Should we have separate releases for the implementations and the APIs?
    • Need to get all the JCR stuff out of the API
    • We would have 2 implementations at first: Mode4 and Mode5
    • What would their version numbers be?
    • Mode4 could be 4.x and Mode5 could be 1.x
      • fedora-4.6.0-mode5-1.0.0
  • This is an opportunity to separate the API from the implementation and encourage alternate implementations
  • Need a new branch for Mode5

Release candidate policy

  • Please review

Can we cut a release for fcrepo-build-tools

  • Fewer lines of code in test suites
  • Can we cut a new release?
  • Need to update modules that use build tools directly
  • Action: Aaron will create a ticket and cut a 4.4.1 release

Upcoming release for fcrepo-camel

  • Done

5 Comments

  1. Unknown User (acoburn)

    Fedora Binaries and last modified date

    For every ldp:NonRDFSource (LDP-NR) object added to a Fedora repository, there is an associated ldp:RDFSource (LDP-RS) description created to describe that binary. Together, they form a datastream resource in the Fedora object model. When the binary object is removed, so too is the related description. Furthermore, HTTP request to either will include a link header that points to the other.

    HTTP requests to the LDP-NR will return a standard set of header fields, including an ETag and a Last-Modified header. Requests to the LDP-RS describing the binary will also contain an ETag and a Last-Modified header. Furthermore, the body of that LDP-RS will contain a triple such as the following:

    <http://localhost:8080/fedora/info/binary> fedora:lastModified "2016-04-16T21:26:59.9Z"^^xsd:dateTime

    That triple refers to the last modified date of the Binary.

    At present, there is a bug with how last-modified dates are handled, such that ETags do not behave properly. (ETags, as they are currently implemented, are based on last-modified dates). It would be useful to clarify what the expected behavior for this should be, and once clarified, it should inform the CRUD portion of the Fedora specification.

    Design questions

    There are, therefore, two last-modified dates: one for the LDP resource and one for the HTTP resource. One option would be to collapse the different last modified values into a single value. Another option would be to use separate last-modified values for the LDP resource and the HTTP resource.

    To illustrate this, suppose a property is changed (e.g. ebucore:width) on the description but the binary does not change. As a consequence, which last-modified date(s) should change?

    Option 1: All dates change. This includes the fedora:lastModified triple in the description and the Last-Modified headers for both the description and the binary.

    Option 2: Only the Last-Modified HTTP header for the description changes. All other last-modified dates refer to the binary itself, and since the binary didn't change, the corresponding last-modified value does not change.

     

    Note: In the event that the binary itself is changed (e.g. via a PUT operation), it is expected that all last-modified dates would change: the fedora:lastModified date in the RDF would change, since the binary was modified, as would the HTTP headers corresponding to the binary. Since the RDF in the description would change (in addition to fedora:lastModified, the premis:hasMessageDigest would also change) the HTTP last-modified header corresponding to the RDF description would also need to change (since its representation changed).


    There are open pull requests that implement both of these options:

    Option 1: https://github.com/fcrepo4/fcrepo4/pull/1022
    Option 2: https://github.com/fcrepo4/fcrepo4/pull/1024

     

    Feedback on the intended behavior would be appreciated.

    1. Jared Whiklo

      I think option #2 makes the most sense.

      No need to change the Etag for the bitstream if it didn't actually change. Which (I think) is how option #1 works.

      1. Andrew Woods

        Agreed, Jared Whiklo, +1 for Option 2. My expectation would be:

        • If the Description changes, only the ETag and Last-mod of the Description would change, 
        • If the Binary changes, the ETag and Last-mod of both the Binary and Description would change

        Regarding the triple found in the Description of the form:

        <http://localhost:8080/fedora/info/binary> fedora:lastModified "2016-04-16T21:26:59.9Z"^^xsd:dateTime

        ...I would expect the value/object of this triple to be the Last-Mod of the Binary.

         

        1. Unknown User (acoburn)

          I updated the text above to be more clear that the triple contained in the Description refers to the last modified date of the Binary.

          But yes, your expectation is consistent with my expectation of this.

  2. A. Soroka

    Data from the headers is HTTP-specific: it concerns representations. Data from the body (RDF) is repository-specific: it concerns resources.

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