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)
- U.S.A/Canada toll free: 866-740-1260, participant code: 2257295
- International toll free: http://www.readytalk.com/intl
- Use the above link and input 2257295 and the country you are calling from to get your country's toll-free dial-in number
- Once on the call, enter participant code 2257295
- IRC:
- Join the #duraspace-ff chat room via Freenode Web IRC (enter a unique nick)
- Or point your IRC client to #duraspace-ff on irc.freenode.net
Attendees
- David Wilcox
- Longshou Situ
- Unknown User (escowles@ucsd.edu)
- Eric James
- Kevin S. Clarke
- Unknown User (acoburn)
- Andrew Woods
- Ed Fugikawa
- Yinlin Chen
Agenda
- Release status: 3.8.0
- Java client API
- JCR/XML filesystem path
- Marking objects for deletion
- ...
Minutes
- Fedora 3.8.0
- Almost ready for Release Candidate
- Waiting on PostGres driver issue posted on the list
- Please participate in RC testing
- Almost ready for Release Candidate
- Java client
- Longshou working on resource implementation
- Nearly done
- Esme nearly done but may need more work next week
- Longshou working on resource implementation
- JCR/XML filesystem path
- Asynchronously persisting human-readable repository objects in JCR/XML on the filesystem
- Translating repo hierarchy into filesystem hierarchy
- RDF relationships are not represented in this hierarchy
- Do we need to encode the characters in the URL?
- e.g. swap all : with \ (effectively creating a new directory)
- What happens with things like PIDs?
- Marking objects for deletion
- Currently, deleting an object puts it into the trash and then ModeShape permanently removes it as part of a cleanup process
- Maybe we should define a predicate for statuses in the repo
- Delete, inactive, etc.
- It will be up to the application layer to define how these statuses affect behaviour for users
8 Comments
Stefano Cossu
Sorry I didn't make it to the deletion discussion. We have been discussing about it internally.
From a Fedora REST API standpoint I would expect a DELETE command to hard-delete the record as it does now. A middle layer could implement a DELETE method that performs a soft-delete (i.e. mark record as deleted) instead.
As for assigning a 'deleted' status, it would be useful to add a 'fcrepo:status' property to the fedora:resource CND. This can be either a numeric value that adheres to a global convention (e.g. we use 0 for disabled, 1 for active, 2 for hidden, -1 for deleted, -2 for invalid, etc.), or a URI reference to a node in the repo that represents a status with a label, a unique value, etc.
Either way, XACML policies can be built to define who has access to invalid, disabled, deleted nodes etc. This solution is pretty flexible for us.
Thoughts?
Andrew Woods
Thanks for the input, Stefano Cossu.
Your description is the approach we have landed on as well, with a slight clarification on the value of the fcrepo:status property. Those values will be URIs as opposed to literals. There will be a few Fedora-defined URIs for values such as "inactive", "deleted", etc which will be added to the Fedora ontology. You will, of course, be able to define your own URI values for the fcrepo:status property as well.
Stefano Cossu
Is there a ticket for this?
What are the foreseen core status types that will be implemented? A/D/I as in Fedora3?
Andrew Woods
Here is the placeholder ticket: https://www.pivotaltracker.com/story/show/54611050
We have not yet defined the URIs or the internally recognized status types yet, however. Are these definitions something you are presently wanting/waiting-on?
Stefano Cossu
Thanks for the placeholder ticket, Andrew Woods. Do you want me to fill in the details from this conversation?
It is not mission critical, but we are implementing our status types and I would like them to be an extension of the Fedora definitions.
Andrew Woods
Stefano Cossu, It would be great if you populated this pivotal ticket. Thanks.
Ralf Claussnitzer
+1 the idea of a "deleted" state. This state can also appear on the OAI-PMH interface when OAI deletion strategy is set to "persistent". http://www.openarchives.org/OAI/openarchivesprotocol.html#DeletedRecords
The F3 admin tool has a "purge" function for technically removing a record completely. I think its practical to make this distinction.
Fulgencio Sanmartín
+1 to the whole idea of fcrepo:status as described by Stefano - it was something existent in Fedora v3.x, see FOXML 1.1:
http://fedora-commons.org/definitions/1/0/foxml1-1.xsd
We use the "I" (inactive) for the embargo, and it would be very useful to keep it, and would ease the migration 3>4.