Time/Place

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

Attendees 

Agenda

  1. Close (or justify) old pull requests https://github.com/fcrepo4/fcrepo4/pulls, especially those older than ~6 months

  2. Hash resources: requirements, expectations, next steps
  3. Last-Modified date design
  4. Code4Lib Philly post-conference event?
  5. ...

Ticket Summaries

  1. Please squash a bug!

  2. Tickets resolved this week:

  3. Tickets created this week:

Minutes

1. Closing old PRs: Send email to the author or leave comments on the conflict pull requests, old branches too.

2. Hash fragments:

Create hash resources, give a name and a property, then it is auto created?
Need to know from user's perspective, what is the client expectation? Need to have common understanding before start implement it.
- How does the user create the hash fragment?
- User don't create the hash fragment and just use them?
- Does user delete hash fragment make sense? or just stop using them?
- Http doesn't provide a way to delete hash fragment
- If user doesn't create hash fragment, then it make perfect sense doesn't delete them neither.
- Question1: a dc:creator point to a hash uri and you delete all the properties of that uri, do you remove that triple.
- what if that triple is not in the repository?
- Chain deletion doesn't feel right.
- You have a resource, inside that resource, there is properties point to a hash uri. at the certain point, you remove all the properties from the hash uri, what happen to that triple?
- Treat hash uri as a identifier not actually associate a resource in the repository. (if it make sense)
- Current we don't have a good answer to the question 1. We can treat this as a identifer so no deletion action.
- As properties, hashURIs could contain the "/" character, as described by RFC 3986. But can't use as JCR node.
- Don't have a final conclusion in this meeting, a proposal is need, to discover what property model, linking or not linking, delete link, and etc.


3. Etags: Please look at that page and give comments. Need some agreements on that before start working on it.  

4. C4L: Have a meeting after the Code4Lib conference, what do you think?

other: https://jira.duraspace.org/browse/FCREPO-1443 need to be reviewed