Page tree
Skip to end of metadata
Go to start of metadata

Time/Place

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

Attendees 

Agenda

  1. API Specification
    1. Ideally the first public draft would be published over the next couple weeks
    2. Moving towards a shared understanding: Purpose of the API specification 
      1. Some of the disagreements about the details of the spec arise from differing opinions on the purpose of the spec itself
      2. Notes on purpose of the spec
      3. Two different perspectives:
        1. Spec defines minimal but required set of capabilities that must be implemented in order to “do Fedora”
        2. There are a range of capabilities, and you may or may not do all of them
          1. If you do any of them, here is some guidance/expectations on the behaviour
      4. Josh: what is the scope of the spec?
        1. Is the spec mainly about aligning Fedora with LDP, or should it also include things (like fixity) that are historically associated with Fedora that do not fit into an HTTP interaction model?
    3. Does Persistence Fixity belong in the specification?

      1. Josh: It's an important function of this kind of system, and the expectations about how it might be done need to be clear

      2. Danny: some discussion of back-fillability of functions
      3. Aaron: application concerns are different for RW apps than for RO apps, too
      4. Andrew: consider the notion of substitutable backends- seems like spec should be clear enough that an app should be able to be agnostic to some extent; what capabilities should be guaranteed? what are implementation dependent? is a key distinction for the API definition effort. What can we do?
      5. Aaron: unsure how much we can do with regard to, for example, the flexibility in the LDP approach of constraints documents and statement rejection (again mattering to RW and not to RO apps)
      6. Andrew: To what degree is substitutability reasonable or sensible?
      7. Nick: If we're silent on SSR, cannot promise any functional substitutability (in managing apps)
      8. Danny: the spec is really leading me to use the simplest interaction models, which might good, but may also be too simple
      9. Josh: feels strongly that it should be a refinement of LDP
      10. Kevin: If the purpose is interoperability with an eye toward swapping out back-ends then we should tighten the spec
      11. Pain point: putting RDF (e.g. an ontology) into Fedora that does not conform to Fedora’s restrictions (e.g. single subject rule) so it must be uploaded as a binary file
      12. Is the SSR a technical limitation or an important part of what Fedora is?
        1. Andrew: it is a philosophical limitation - Fedora is a digital object repository so RDF describes objects in Fedora rather than random subjects in the world
    4. Outstanding issues

  2. Implications of blank node redesign:  FCREPO-2108 - Getting issue details... STATUS

    1. Warrants a 4.8.0 release?
    2. Instead of being created off to the side, these are now created as hash URIs
      1.  Jared: Will anyone notice this change?
      2. Andrew: existing resources will not change, but new blank nodes will be created as hash URIs
      3.  If administrators wanted to remediate this difference they would need to do this work (or a tool could be created)
    3. Nick: Do we need to release this along with a tool? What kind of release is it?
      1.  Andrew: It is not backwards-incompatible so it is a minor release
      2. Aaron B: Some clients may have written code that would make this backwards incompatible
      3.  Andrew: We could float this to the community to see if anyone is depending on the previous functionality
        1.  Basing this on mailing list feedback is not necessarily indicative of what people are doing
      4. Jared: Do we define breaking change based on the repository or potential workflows?
      5. We should produce a tool to remediate the different ways of handling blank nodes and put out a minor release:  FCREPO-2423 - Getting issue details... STATUS
  3. Suggestions from recent Fedora Leaders meetings
    1. Have an elected Fedora Committer join Fedora Leaders calls
    2. Have DuraSpace-hosted release testing infrastructure
    3. Interest in tighter alignment of effort and priorities between Islandora/Hydra/Fedora
  4. Announcement: Monday - 2017-04-17 - Import - Export Planning Meeting
  5. ...
  6. Status of "in-flight" tickets

      Click here to expand...

Ticket Summaries

  1. Please squash a bug!

     Click here to expand...

    Key Summary T Created Updated Due Assignee Reporter P Status Resolution
    Loading...
    Refresh

  2. Tickets resolved this week:

     Click here to expand...

    Key Summary T Created Updated Due Assignee Reporter P Status Resolution
    Loading...
    Refresh

  3. Tickets created this week:

     Click here to expand...

    Key Summary T Created Updated Due Assignee Reporter P Status Resolution
    Loading...
    Refresh

Minutes

  • No labels

1 Comment

  1. Just to clarify something re: whether skolemizing as hash is appropriate for a minor release.  Client code that has specific workflows around how Fedora skolemizes blank nodes could be affected.  The only example I can think of is resource cleanup, as  .well-known skolem nodes are not bound to the lifecycle of the resource that "created" them.

    So if you create a resource <http://localhost:8080/fcrepo/rest/foo> with a blank node, Fedora may skolemize that blank node to <http://localhost:8080/fcrepo/rest/.well-known/genid/13456>

    Upon deleting  <http://localhost:8080/fcrepo/rest/foo>, <http://localhost:8080/fcrepo/rest/.well-known/genid/13456> still exists.  

    It's possible that client code that compensates for this irregularity could exist.

    If this behaviour is a *bug*, and is something that could reasonably have been addressed by a point release, then releasing the hash skolemization fix in a point release is probably OK.