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 #fcrepo chat room via Freenode Web IRC (enter a unique nick)
- Or point your IRC client to #fcrepo on irc.freenode.net
Attendees
- A. Soroka
- Unknown User (acoburn)
- Michael Durbin
- David Wilcox
- James R. Griffin III
- Aaron Birkland
- Stefano Cossu
- Unknown User (daniel-dgi)
Agenda
Is there an appropriate Islandora/F4 joint sprint opportunity in the near future?
- Unknown User (escowles@ucsd.edu): We have a ticket for the following version upgrade utility:
- However, the following two tickets are on hold until FCREPO-1542 is resolved. Do we need to continue to hold these two?
- Aaron Birkland: What is the plan for getting the community involved with "API extension architecture"
- Is anyone interested in moving this forward?
Tickets resolved this week:
Tickets created this week:
- Addressing by James R. Griffin III
- ...
Minutes
Islandora and Fedora 4 Sprint
Managed by Unknown User (daniel-dgi) and Nick Ruest (returning following the Islandora Conference)
Scheduling
Such a sprint would likely be scheduled for mid-August 2015
The community itself will drive the direction of the sprint. Possible areas of focus include:
- Web ACL
- migration-utils
Versioning/Upgrade Utility
Unknown User (escowles@ucsd.edu) was not present for the call, and no other parties present appeared to be in the position to discuss this topic
Prioritized for later calls in which either Esme or Andrew Woods is present
API Extension Architecture
Aaron Birkland is aiming to next put out a call for interest from the community (in order to define the scope of the related tasks)
A. Birkland will soon go on leave; hence, this is to be delayed until his return during either early August or September
Use Cases
Stefano Cossu of the Art Institute of Chicago has drafted use cases within the Confluence Page for this undertaking
JHU has also specified the initial use cases
It is likely that this call for interest shall also involve the capturing of additional use cases
Structuring fcr:metadata resources as an LDP Container
Currently, non-RDF resources have the descriptive metadata structured using fcr:metadata
fcr:metadata itself is a pseudo-container (in that, one cannot use to perform the operations which one can perform using a true LDP container)
Restructuring this fcr:metadata as a proper container is the request
It should be noted that no individuals volunteered for addressing this issue
There appears to be a lack of documentation regarding the outcome of past discussions involving this issue
No specifications or discussions relating to the scoping of FCR metadata appear to have been drafted or have taken place
It was proposed that this topic be discussed upon the return of A. Woods
Regarding the precise definition of fcr:metadata (rather than the construct of the container)...
A clarification was made in which it was confirmed that a discussion of the FCR metadata (proper) never indeed took place; This was simply understood as an LDP construct
Perhaps this conversation is necessary...several parties seemed to support this
The context in which this is undertaken is typically one in which repository architects or administrators seek to store metadata structured in the XML without transforming it into the RDF
The suspicion was such that individuals are far more interested in simply adding this content as another bitstream
Without a clear sense for a time frame, this shall need to be discussed during the next call.
fcrepo-client and Issues Related to the Linking of fcr:metadata
James R. Griffin III seemed to be interested in undertaking this from the standpoint of becoming familiar with the code base
A. Coburn clarified that this issue seemed to solely afflict the fcrepo-client
Michael Durbin felt that this client was out of parity with the Fedora Commons code base (as well as untested)
A. Coburn confirmed that this was the case (and specified that they did not leverage this from with Apache Camel integration)
M. Durbin also advised that, if any such client is to be supported by other components of Fedora Commons 4.x, it would be best to have it covered within integration testing suites
LDPath Templating for HTML Views
HTML Views for Fedora Commons are currently implemented using Velocity
RDF tuples are transformed into objects; These objects, in turn, are rendered using the templates
The commonly-used LDPath language contains a templating extension; it would be ideal replace Velocity using this extension
James R. Griffin III showed some interest, but delayed commitment to the issue
Linking within the Splash Page
The insertion of a link encouraging end-users of Fedora Commons to register with the organization is desired
This would serve as a means by which to increase the degree of communication with the user base
Modeshape Integration and OSGi Compliance
Currently, A. Coburn is working to clean up the Modeshape package integration with fcrepo-kernel-impl (specifically, the parts of the fcrepo code that break into modeshape's internal classes)
By using the publicly-exposed Modeshape API, the best practices in compliance with complying with OSGi guidelines can be undertaken
This is being blocked when attempting to inspect binary content (within the context of performing fixity checks)
A. Soroka confirmed that this was indeed the case, but that Chris Beer and Benjamin Armintor should be contacted regarding the preferred resolution
Further, it appears to be the case that this was undertaken to access Infinispan cache stores more directly (and simply, as a consequence, broke through the Modeshape layer)
OSGi Cleaning
A. Birkland enquired as to whether or not A. Coburn still felt confident that complete OSGi support was possible for fcrepo-kernel
While this would be ideal, A. Coburn was uncertain about the degree to which the kernel can be completely modularized, but so far he is optimistic.
Issues in relation to the resolution of conflicts between Java servlet API's are far more trivial
This is necessary in order to deploy Fedora Commons using Karaf
Where A. Coburn's certainty wavered related to the exposing of other modules using RESTful endpoints
It was suggested that the services be registered and that a whiteboard pattern be implemented
Apache Felix was specified as a publishing framework in which this approach was commonly undertaken
A. Birkland confirmed that they retain their degree of interest in this undertaking
The increasing diversity offered in deployment strategies and increased modularity offered many benefits to the community
