- Amol Khedkar
- Andrew Myers
- Randall Floyd
- Adam Ploshay
- Karen Cariani
- Michael Muraszko
- Nianli Ma
- Daniel Pierce
- Jon Dunn
- Check in RE where we stand with a minimum viable product
- Get community feedback on design and implementation of features, especially in regards to PREMIS
Andrew Woods : why not implementing community component in terms of the PREMIS events logging?
Drew M: Esme pointed out wouldn't need to do a data migration; what we want for this type of a plugin is trying out with ease - if someone has standing fedora, would have to provide a pre-packaged version. User that gets logged in audit log service is the fedora user, not tracking the actual logged-in user. We want our own workflow around what gets logged and when, would need filtering to get rid of all the noise of what events we want to track. PREMIS events needs are pretty basic, not a complex data model. If we did enable audit log service, integration points would be a lot lower level.
Andrew Woods: collectively this makes sense, small factors add up to this being a good decision
Drew: combining Sufia CC and plugin type model, the more that those plugin type things can live at the higher level, the more this makes sense for us
Drew: idea is that this will be an installable gem, but the process to make this a gem is more to do with Rails machinery and less with features
Decision in the September meeting: create a secondary Blacklight instance for tracking preservation events; preservation events don't fall into the category of a Work, more single log entry; lumping discovery into existing catalog controller stuff would have been problematic; development challenge was finding what CC offers to create this secondary search interface and getting rid of what's not needed
Looking at how to facet these things. Currently has date facet, type needs to be indexed differently, this is just an example
For storing users, can take the mailto uri and use this to compare to the users table in Hydra, if you're registered within HD2; you don't necessarily need to be authenticated user in hd2 to be logged as a premis agent
Jon: Search for objects based on preservation events as being problematic because we've separated these two in the search interface
Drew: ticket in to create more user stories for this sort of thing to define; As far as saving down preservation events to the fileset level, what would be needed is what level of detail would you need to save down to on the filset; one thing is to reach down to the filename, if we have a use case to specify that, you can search based on the filename
Jon: Important for manual auditing
Will: esp once we get to auto-fixity checking
How far up do we need to push this? Collection level? How high up do we need to be able to see events?
Andrew Myers: Any consideration for storing these events in a triple store? Parents and parents and parents would make sense for querying triplestore
Drew: any type of query logic is going to the solr level when we run an index; haven't considered triplestore
Andrew: possible benefits: various types of queries, can service those queries we've defined without having to do any advanced... Curious to what extent we're talking about PREMIS here? To what degree is the effort to conform to what PREMIS is saying; if serving the standard PREMIS ontology, opens the door for easier interoperability and discovery with others also using PREMIS ontology
Drew: dates - not as easy as adding a date in PREMIS; also have this whole class of affiliated dates, we're not using the complexity of PREMIS; we should consider that bc some of these events take sometime, so having a duration is not well represented currently
Andrew: to what extent are the plans to expose this data beyond the search interface?
Jon: what about other potential events outside of the system? Eg replicating to DPN - how do we capture that? Are there examples of other institutions that are using PREMIS to record replication in outside repos?
Andrew: DPN, APT institutions, but not as far along as HD2 in terms of preservation events
Jon: If there were standard tools for capturing that, we'd want to adhere, but it sounds like early days
Andrew: Understands argument for keeping things at the Hydra level, but there are functional reasons for keeping things at the Fedora level - created with internal and external events in mind
Looking at what we're showing, seems like it's the same info being captured, so it would be nice if ; same as like access controls, same information but not quite captured in the same way, makes sense to go for full alignment if there aren't any arguments really against this
Drew: If we were to embrace event logging in Fedora, the layers of the stack that would need to be created, kind of translate to all layers of the stack; seemed to make sense to start at the CC level; you do end up with a lot of duplicative data though.
Andrew: Curious, if there's any reason not to at the Hydra level, when you're persisting at the PREMIS event that you use the same details that are the wiki page above, would just depend on what property is named; even though you're completely managing in CC, what shows up in the works side is what you're tooling
Drew: Would be worth some reconciliation there to not deviate too much from what Fedora is giving you
If we deviate from what Fedora is doing, if using a system that uses Fedora's audit log, they would be different from what our audit log is capturing
General discussion needed for how we need to discover this PREMIS information, etc etc
Drew: If understanding work priorities in place; this is on Drew's local machine, need to get it into a state, what's our production instance
Mike: fine focusing on this currently, if we put it off now we won't pick it back up easily; would rather prioritize this work and have it more stable
Will: good thing to discuss tomorrow