...
- Previously, cbeer had added this functionality, but it had been later removed
- Is data structured for this in modeshape to be reasonably performant?
- Mike: Was one of the agitators for this, opposed it being cut
- Some stuff is inferred, some not directly searchable
- What types of queries do we want to support?
- What exceptions are we willing to tolerate?
- Extension spec?
- Is it okay if it doesn't work consistently on server managed triples, like date fields?
- Just wants to be able to search dc:identifier. This would work, modeshape has an index that can be searched.
- Esme: Valkyie, making a list of queries that the repository needed.
- Needed queries
- all objects of given type
- Doing a search for dc:identifiers
- They will come up with a list of queries they need
- Needed queries
- Danny: Would it be helpful at this point to fill out the list
- Discuss some of the known limitations of modeshape's internal indices
- Mike: Last modified date is across two fields. Might need to normalize way stored in fedora. Need to work out if this is needed
- Esme: Types and containment triples are harder to make searchable
- Search for non-server managed triples that are directly assigned are easy.
- RDF type are not stored in the index modeshape maintains. That is inserted into responses.
- Use case: find all objects of a type in order to do bulk object on it
- Can't search on fcr namespace and ldp namespace. Might be okay to not support those, but it would be weird to have an LDP server that didn't support it
- Could add support for this in after if there is demand for it
- Discuss some of the known limitations of modeshape's internal indices
- Mike will start document to gather first pass at known limitations of implementation and requirements
5. Tickets requiring attention
- 2520
- Bethany would like more feedback on what expectations are for mimetype
- She will take another look at it to try to work through what the validation issue is
- 2650
- Bethany will take a look
- 2544
- there was a work around for that, using a different accept type. No one has strong feelings that it shouldn't be closed, so will make a note on ticket
- Josh - as a larger strategy, this is something we will need to address
- Paging mechanism is problematic in RDF rest api, but something we will need to deal with
- Work around okay for now, but many members issue needs to be addressed in future implementations
6. 5.0.0 release?
- Need to wrap up creation of mementos, one of the last main things to bring into alignment with spec
- Pairtrees - Do we want to remove them?
- Peter (?): In favor of removing them
- Significant bit of internal work to hide them at fedora level, while still might need them in jcr
- Danny: In doing away with pair trees, they would still be around internally
- Peter: Need them, otherwise performance tanks after about 1000 children
- Esme: Might want to look at Aaron Coburn's Appletree implementation. Takes checksum, makes path based on that. Includes hiding internal paths
- Esme: would involve renaming everything in your repository, so it would need to take place as part of a major version change
- Esme: Would either need migration tooling, or tooling for enabling/disabling the feature
- Danny: how hard would a migration tool be to created?
- Esme: Would be complex, but possible. If you have been using auto-generated UUIDS, could go through repo and remove pairtree.
- Danny: interesting proposal, do we need community feedback?
- Yes, more feedback would be good.
- Esme: to write up brief description of proposal for fedora-tech
- For discussion in new year
Action Items
Action: Check in with Andrew about completeness of the test suite
Action: Mike will put together a document with first pass at the feature set.
Action: Esme to write up brief description of proposal to remove pair trees for fedora tech