...

Attendees 

• Danny Bernstein
• Nancy Fallgren
• Doron Shalvi
• Jared Whiklo 
• Joshua Westgard 
• Bethany Seeger Ben Pennell
• Aaron BirklandDavid Wilcox
• Simeon Warner
• Peter Eichman
• Yinlin Chen
• Andrew Woods
• Michael Durbin

Agenda

1. Assign star master 

2. Ben Pennell is on the committee conveyor belt.

3. New Fedora Clustering configuration

4. Discussion of Nancy Fallgren's Write-up on perma links in IRs
5. Fedora Fedora representative at Data Help Desk at AGU Fall Meeting
6. Sprint follow-on tickets
   

   1. Memento work in-progress:

      1. Jira
         server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-2617

      2. Jira
         server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-2625

      3. Jira
         server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-2623

      4. Jira
         server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-2622

   2. Other work in-progress

      1. Jira
         server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-2632

      2. Jira
         server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-2585

7. 4.7.5 release
   1. Deprecations
   2. Non-API-Alignment fixes/improvements
   3. Future of fcrepo-audit? - 

      Jira
      server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-2648

   4. This month?
8. 5.0.0 release
   1. API Alignment
   2. Abandoning the single subject restriction: any feedback/illuminating discussion on the list?
   3. Pairtrees?
9. Tickets requiring attention

   1. Jira
      server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-2650

   2. Jira
      server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-2649

       - Peter Eichman is on it

   3. Jira
      server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-2544

       - waiting on feedback from Chris Colvard

   4. Jira
      server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-2486

       - ready to go? Danny Bernstein?

   5. Jira
      server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-2492

       - ready to go? Danny Bernstein?
10. ...

11. Tickets In-Review

    Expand
    Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=14307 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

    
    
    

12. New Fedora Clustering configuration 

13. 
    

Ticket Summaries

1. Please squash a bug!

   Expand
   Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13122 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

   
   

2. Tickets resolved this week:

   Expand
   Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13111 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

   
   

3. Tickets created this week:

   Expand
   Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13029 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

   
   

Minutes

• Discussion regarding new clustering configuration PR:  https://github.com/fcrepo4/fcrepo4/pull/1265

  • It would be interesting to understand the context for this PR

  • Is clustering being used with this new configuration?
• David Wilcox spoke about the AGU Fall meeting that will be in New Orleans in December. If you're interested in attending and representing fedora (essentially taking shifts at a table), contact David Wilcox
• Issues: 

  • Jira
    server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-2623

     - is ready to be merged. Andrew Woods will check in with Aaron Birkland before merging it, though it seems like it's ready to go. 
    • there needs to be some work done with converters to have the subject returned correctly for getting the timemap - so that the public facing side is `fcr:versions`, but the internal node name is `fedora:timemap`.  Sounds like `fedora:timemap` is being returned right now and shouldn't be.
    • a test case needs to be written to test the subject returned when doing a GET on a LDPCv.  

  • Jira
    server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-2622

     - duplicate of 2623?  Sounds like it. Jared Whiklo will update the ticket.

  • Jira
    server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-2585

    Danny Bernstein working on - sounds like it's almost ready to go. 
• The work on fcrepo versioning is going into a versioning branch right now. Once the basic versioning/memento functionality is there, it will be merged into master. 
• 4.7.5
  
  • Incremental Release - November / December time frame? 
  • fcrepo-audit - Question is should we continue to support this module or deprecate it? 
    • Seems like there is general agreement about deprecating it, however, maybe not quite yet until we have a durable solution to replace it with. 
    • Peter Eichman - talked about the issues they've been seeing. Having the audit messages added in the triple store (via fcrepo-camel-toolbox indexer) is useful and much easier to access audit info that way.
      
      • switched over to indexing triplestore camel route to track audit - will be using that in their production repo starting next week.  It is a separate dataset in fuseki. 
      • thinking about creating audit service that listens to JMS messages and writes to log file(s) - anyone else interested in that?
        • One could use the various mature filesystem tools available to manage logs this way (for rotating, viewing, graphing, etc.)
        • Their first thoughts on the first pass at this:  considering just dumping the JSON messages to disk. 
        • Might be able to look at fcrepo-camel-serialization tool for inspiration/code
    • There are currently two audit capabilities - fcrepo-audit & fcrepo-camel-toolbox triplestore indexing tool.  

Actions

•  Danny Bernstein will try to push forward on FCREPO-1262.
•  Doron Shalvi will write up a description of the Fedora URI concerns and post to the Fedora listserv to start discussion.

• Joshua Westgard volunteered to take minutes.

• The first item of discussion was Nancy Fallgren and Doron Shalvi's post on the Fedora community list regarding questions of Fedora's URI/URL usage.

• Doron Shalvi expressed at the outset his recommendation and wish that the conversation would continue at a time when Andrew Woods is available since he is likely to have valuable input on this question.
• Nancy Fallgren summarized the main points of concern:
  • URIs should be resolvable HTTP URIs.
  • Using URLs rather than URIs is not a best practice (i.e. making statements in RDF that blur the line between web resource and real-world object).
  • IDs for abstract concepts are being minted by various groups and we need to be able to use those in the RDF published through our Fedora instances.
  • Linked data is primarily for machines and not humans.
  • Currently NLM creates identifiers – referred to as permalinks – to represent these real-world objects, but it would be difficult if not impossible to use these directly in Fedora as it is currently defined.
• Joshua Westgard posited that the central barrier to the sort of use that NLM is describing might be the single subject restriction.
• Jared Whiklo suggested that one way to talk about real world objects in a Fedora ecosystem would be to use a triplestore alongside Fedora to store RDF about real world objects.
• Another option would be relaxing the single subject restriction.
• Aaron Birkland mentioned OAI-ORE's concept of a resource map as another helpful model to consider in this context.
  
  • This describes a method of keeping object and description separate and yet resolvable
  • Two methods are recommended for dealing with this problem: hash URIs and a the 303 response (see other)
  • Aaron Birkland also expressed support for removing the single subject restriction
• Danny Bernstein raised the further issue noted in the mailing list thread of the question of the appropriateness of RDF as a backend data storage format, and asked that this question be fleshed out.
• One issue with RDF is scalability (large datasets tend to balloon to millions and billions of triples rather quickly).
• Aaron Birkland suggested that the question may really be about whether the web-based architecture is appropriate.
• Doron Shalvi added two additional concerns:
  
  • restrictions on URI patterns creates a scalability problem for users with large collections of materials
  • there is a need to make assertions/statements about things external to the repository and single subject makes it necessary to then bury the LDP server under other layers of infrastructure, which in turn calls into question the benefit of using Fedora
• There seemed to be a consensus that the discussion was valuable and needs to continue, particularly as we move toward finalizing a version of the API specification.