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
- Andrew Woods
- David Wilcox
- Michael Durbin
- Unknown User (escowles@ucsd.edu)
- Mohamed Mohideen Abdul Rasheed
- Eric James
- Peter Murray
- Osman Din
- Kevin S. Clarke
- Yinlin Chen
- Ed Fugikawa
Agenda
- Java Client Library updates
- Review and distribute tickets
- F3 -> F4 upgrade elements
- Next hackfest??
- Duplicate triples
Minutes
Java client library updates
- Tickets in pivotal tracker as epic
- Send a reminder to the mailing list asking for help
- Maybe we need to do this in a sprint context
- First task is large/nebulous
- Evaluating LDP clients is an undefined amount of work. Doing this might help kick start the effort
- Might make sense to do this in a sprint
- If one of the existing LDP clients won’t work, it probably isn’t worth writing our own
F3 to F4 Upgrade
- What will content look like in F4?
- Comparing/contrasting F3 and F4
- Things to keep in mind when upgrading
- Objects
- Metadata mapping (XML to RDF)
- Disseminators
- Authorization/authentication
- No API-A/API-M distinction
- Search
- GSearch no longer used
- Would be good to support lossless information transfer from F3 to F4
- i.e. F3 data that is no longer needed in F4 should still be preserved
- Content Modelling
- Hierarchy vs. flat file system
- Objects
Next hackfest
- Should align with Fedora 4.0 release
- West coast USA?
- Around DLF
Duplicate triples introduced
- client API ideas – see Strawperson API Design.
Minutes
Java Client
- Kernel API classes are a pretty good model, except for JCR and other internal classes in params and return types that need to be cut:
- JCR Session
- Identifier Translator
- The services seem a little cumbersome as a client, so perhaps a more focused grouping (as in the Strawman)
- Some work needs to be done to abstract/simplify certain calls
- Unknown User (escowles@ucsd.edu) wants to start working on the basic calls soon to complete local work
- will set up a few base API classes and as interest builds we can more formalize process
- Eric James suggested a separation (like API-A and API-M) for the client
- Michael Durbin added that a read-only mode or client would be good.
- Many (if not all) F4 responses include duplicate triples
- This is likely not a problem, although it would be nicer to not have the duplicates
- The ideal approach would be to eliminate the inclusion of the triples at the outset versus de-duping after the fact