...

• frank asseg 
• Ed Fugikawa 
• Andrew Woods 
• Stefano Cossu
• Nikhil Trivedi
• Scott Prater 
• Osman Din 
• Eric James
• Greg Jansen
• Michael Durbin
• Michael Mike Daines
• Benjamin Ben Pennell
• Adam A. Soroka

Agenda

1. 4.0 Features: review of responses

   Feature	Votes (out of 7)
   Authorization	5
   Backup	4
   Batch Operations	1
   Clustering	5
   Content Modeling - Structural	5
   Managed External Datastreams	5
   Store/Deliver Large Files	6
   Search	7
   Transactions	3
   Triplestore	6
   Versioning	4
   Non-Functional: Easy Deployment	6
   Non-Functional: Performance - Single-node	4
   Non-Functional: Performance - Clustered	3

2. Resource locking model
3. Configuration and support of both protected and public endpoints (Greg Jansen)
4. Bring the meat ax down on our leakage of JCR abstractions through our API and RDF (Michael Durbin)
5. Fedora ontologies and concept mappings
6. other...?

...

Andrew and Greg: The sent out features e-mail did not get any negative responses. The feature list covers items that were agreed upon by stakeholders and developers.

...

The idea was to prioritize features that are most important to developers (representing institutions send out a broader message, saying that these are the features for 4.0 which drive the focus of development, in order to get sign off from stakeholders.

The page shows where the preferences lie (not to say that batch operations or transactions won't be worked on, just the priorities).

Greg: With respect to clustering, there are two distinct use cases: (1) performance; (2) redundancy. Wondering if we have emphasized that. There are some expectations in the community about redundancy.

Andrew: Yes, two distinct things. Wondering if we talked about, . . .perhaps only Ed APTrust has hinted at that at (some point). Do other folks think that's true?

Response: makes sense to talk about it

...

Esme: In our case (and as mentioned in e-mail), a lot of these features in are implemented in the front-end (via hydra). So, e.g., even if F4 beta has no auth, it'd still be an acceptable product.

Andrew: These discussions are taking place . . .exploring the idea that hydra Hydra starts to leverage F4.

Martin: Same applies to Islandora.

...

Esme or Scott: Auth could be externalized. VersioningFeatures such as versioning, search, content modeling are good.

Andrew: Let's keep continue the discussions around. After discussion with stakeholders, we have this list. 

Stefano: People might find that F4 is a compeltely completely different product from F3 in terms of features. Lack of features may put implementation burden if some features are absent (e.g. does auth have to be implemented in client?).

Andrew: agreedAgreed. bu But the first focus of 4.0 release beta is not upgrade from Fedora 3.. subsequent releases, 4.1, 4.2, will make it easier to upgrade.

...

Mike summarizes the problem. There's some locking which is not there and can be misleading if it's assumed to exist. We need to explore jcr JCR locking functiionalityfunctionality.

Adam: discusses 2 different proposals about how to handle these locks.

Mike: No personal preference, but need to do something that works

Adam: resources Resources that exist in repo, or in http api . . .

Andrew asks whether JCR spec talks about node being creating representing a lock.

...

Mike: If you delete the node, the lock disappears or not?. . .

Adam: not Not sure...

Mike: we We can figure out as we implement this

Andrew: any Any design ideas before you code that you can share would be good on irc IRC and pivotal ticket . . . 

3.  Configuration and support of both protected and public endpoints (Greg Jansen)

       Andrew summarizes Greg's point about two war files: (1) standard file with no auth enabled by default; (2) war file with a reporepository.json to point to auth classes and web.xml specifying protected resources.

...

       Andrew: Doing this in aplicationapplication, not in servlet container. Create a ticket to explore.

...

Andrew: There's some discussion out about exposing JCR functioality functionality such as providing JCR search capability. The general notion of abstracting away jcr is good. If For example, if we throw away ModeShape. . . 

...

Andrew: It's ongoing work that primarily Adam has been engaged. Lots of different aspects to it, and we won't go into them . There are a few different notions on the table floating around and often times intermingled. We have talked about trying to map fedora concepts to jcr JCR concepts and 

presumably in a higher in the chain, specifically ldpLDP. How doe we expose fedora concepts in ldp LDP and provide a mapping. Adam has been working on creating a model of these ontologies. The goal is to speak to the community clearly.

...

Adam: No, that was fantastic.

Addendum: The mapping from Fedora to LDP is available in OWL here: https://github.com/futures/ontology.

Andrew: Thanks . . . Reminder: last day of sprint . . . any objections if we do the sprint wrap up at 4 pm . est? See you then.

New Actions

•  Greg Jansen to create ticket for exploring "parameter-based" AuthZ
•  Michael Durbin to create ticket for cleaning JCR references out of F4 responses