...
The last is with the format policy registry. Lots of folks are interested in breaking it out of Archivematica, and amongst the people interested are Gisk JISC, in the UK. They are preparing to manage those servicesan Archivematica service. So, let them get done before discussing breaking it out. (Context: many people who are using Fedora like Archivematica's format registry but may or may not want Archivematica itself, including Islandora -- the community would have interest). Justin promised to be in touch and restart conversation when they are ready.
...
b. Update from import/export:
EsmeEsmé Cowles: We've made good progress on export, and got basic import utility merged in, and are working on round trip for phase one objectives, w/o doing anything with bags. We're working on sample data sets and driving initial docs, on how different this utility is from RDF serializer Camel project that was the starting place for project.
...
We're in a good place for future sprints to tackle bags and other features. We'll have an executable jar that addresses objectives and docs for how to use utility, enough so people will be able to at least give it a try and provide feedback that could get rolled in to later sprints.
c. Two Java devs, Bill Branan and Danny Bernstein, will have time to address Fedora performance issues around having many members. There's a Hydra change of direction (from members to collection) PR in, which is a mitigating change, but this will directly address this issue. (Status of the PR is the commits are not in but supporting commits are, Curation Concerns PRs are priority right now. There were some concerns, around whether solr indexing would change, but (AFAIK) concerns were addressed in it. PR should merged in next few weeks.
...
The issue is a request for changing the interaction contract on PUT requests with Fedora. What we're asking for is changing the model from how it relates to server managed triples. In the current approach, if you want to do a PUT, replacing all triples, you can make a PUT with a complete representation of the resource, with both user and server managed triples in it. If you don't have server managed triples you get a 409 in response. The change being requested is for clients to only include user managed triples and if they include the server managed ones they get the 409.
Adam A. Soroka: For context -- what Stefano Cossu's trying to do calls into question whether or not he should be using PUT at all, and he shouldn't be -- for these reasons. Here's his use case. Stefano doesn't care what the current state of resource is, he wants to add to it with no questions asked, mutate it (he may or may not want to remove properties) with no questions asked. He's only interested in the triples he actually wants to change. Here's why it matters: he's arriving with a request in hand, fully formed (adds or removals), -- and it's not a complete representation. It's a delta, or a future state of resource, however we want to describe it, and this is a direct conflict with what's a PUT. He's doing a PATCH. He's not doing it through a SPARQL update because it's unpleasant -- what he wants is a more convenient way to PATCH, like with RDF Patch or LDP Patch. Whether or not we act on this is up for discussion, but I feel we have to consider whether to do this with PUT.
Andrew Woods: We need to verify that's correct description of Stefano's use case. And we need to reaffirm we're doing what we need to with PUT.
Aaron Birkland -- The only time I've come across Stefano's use case is in integration tests, where I don't care what the state of resource is. And that's kind of minor, so I understand the appeal of PUT for this kind of situation. That said, I think Fedora's current behavior is correct. The LDP spec is explicit on what clients should do with triples they don't care about (PATCH them through), but I can see desire for shortcuts in certain situations.
...
Doing PUT w/o server managed triples, a user can do that with an additional header: Prefer: handling=lenient; received="minimal". Both cases are handled in PUTs. You can pass in headers to get what you want. So, we'd just be losing one scenario possibly.
...
Andrew: HTTP PUT should be idempotent and currently is not, because server managed properties change. (Later IRC discussion indicated that in fact current PUT behavior is at least arguably idempotent for a definition of that term derived by Jared Whiklo from the HTTP spec.)
Adam: How would we get around it? Stefano's request would.
...
Esme: I agree it's a blocker but we need someone with real production data to do it and find bugs.
AaronMichael Durbin: We won't find problems before, no one will do it. We'll have to ship and let people find problems and we'll fix them.
...
Andrew: Would it be useful to have a small utility for people to do migration?
Bethany Seeger: Not sure if a script would be useful, but maybe just flesh out the fcr:backup/restore page a bit more?
...
Bethany: Aaron Coburn and I've been talking about the possibility of gradle Gradle in some projects in fcrepo-exts, instead of Maven. It does same thing as Maven, pckgs things. We want to see what the community thinks about some projects in fcrepo-exts using gradle.
...
general: Gradle uses Groovy language, Jared notes that Aaron Coburn that Unknown User (acoburn) has seen that pax exam tests can be done but are more difficult.
...