Time/Place
This meeting is a hybrid teleconference and IRC chat. Anyone is welcome to join...here's the info:
- Time: 11:00am Eastern Daylight Time US (UTC-4)
- Dial-in Number: (712) 775-7035
- IRC:
Attendees
Agenda
- Motion for decision: Should the subject of triples in auto-created LDP-RS (/fcr:metadata) be the LDP-RS or the LDP-NR it describes (the binary)?
- See:
- Open fcrepo-specification issues
- How prescriptive do we want the spec to be?
- Deprecation of RBACL and XACML authorization modules?
- Storage patterns that facilitate repository migrations
- Rolling out Apple-Trees to the community
- Opportunities for contribution: low-hanging bugs to be fixed
- ...
Status of "in-flight" tickets
Ticket Summaries
Please squash a bug!
Tickets resolved this week:
Tickets created this week:
Minutes
irclog
- Motion for decision: Should the subject of triples in auto-created LDP-RS (/fcr:metadata) be the LDP-RS or the LDP-NR it describes (the binary)?
- Summary
- Now; RDF you get back from a description of a binary, the subject of the triple is the binary
- The ticket, changes the expectation of the diamond operator (<>)
- What is the expected behaviour?
- What is the expectation of the triples you get?
- Binary being the subject is the correct answer, and most straighforward
- Don't have to use OWL Reasoning
- "the subject of the triples is the binary, the description URL is different from the binary, the <> operator normally refers to the URL so the compromise is to have the <> operator refer to the binary URI, because that is the subject of the triples, even though <> typically refers to the URL being operated on" Esmé Cowles
- Solution:
- Moving towards a model of instead of the description being under fcr:metadata being under hash URI resource
- is this acceptable from a JAXRS perspective, and HTTP perspective?
- Fixing the behaviour now in a non-breaking way for 4.7.x, which may not be technically correct
- The <> working in a unique way on fcr:metadata is not acceptable, because a direction that is not completely solidified @abirkland
- Open fcrepo-specification issues
- Significant effort going towards refining the Fedora Specification, largely in GitHub issues
- Please read the specification, and issues; you're encourage to dig in, and raise your own issues
- Prescriptivnicifity
- Look at the issues with the perspective through the lens of prescriptiveness that you want
- Deprecation of RBACL and XACML authorization modules?
- For 5.0.0 release, these modules should be removed
- Andrew Woods will send a message out the community
- If the community is good with it, a point release will be made with a deprecation notice around these modules
- Storage patterns that facilitate repository migrations
- Lots of binaries make migrations hard; can we have established patterns for moving only metadata and leaving binaries in place?
- Would something go into the specification around this?
- fcrepo3 External datastreams vs Redirect datastreams discussion
- Rolling out Apple-Trees to the community
- Opportunities for contribution: low-hanging bugs to be fixed
- Excellent entry points for the codebase