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
- Osman Din
- David Wilcox
- Unknown User (escowles@ucsd.edu)
- James R. Griffin III
- Nick Ruest
- Jared Whiklo
- Benjamin Armintor
- Harshakumar Ummerpillai
- Aaron Birkland
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 require a significant amount of community interest
At the earliest, this would likely be scheduled for some time during mid-August 2015
Possible areas of focus
- Web ACL
- migration-utils?
At this point, there is little certainty; the community itself shall likely drive the direction of the sprint
Versioning/Upgrade Utility
Unknown User (escowles@ucsd.edu) was not present for the call
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 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 is just about to take his paternity 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 is a 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.
fc-repo 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
