...

• 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

Agenda

1. Is there an appropriate Islandora/F4 joint sprint opportunity in the near future?

2. Unknown User (escowles@ucsd.edu): We have a ticket for the following version upgrade utility, but what is the plan for changing the core codebase to use the non-fedora-namespace properties?

   • Jira
     server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-1542

3. Aaron Birkland: What is the plan for getting the community involved with "API extension architecture"
4. Is anyone interested in moving this forward? 

   Jira
   server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-1590

   ...

5. Tickets resolved this week:
   
   

   Expand
   Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13111 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

6. Tickets created this week:

   Expand
   Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13029 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

7. ...

Minutes

...

1. fcr:metadata and NonRDFSource descriptions
2. API extension framework to provide a Fedora 4 equivalent to disseminators or other kinds of functionality, independent of the core Fedora 4 codebase
3. How do we align our REST API with standards, partitioning the API, adding test compatibility kits, etc.
4. Improving codebase by taking advantage of Java 8, reducing dependency sprawl, OSGI-ifying Fedora
   1. Some dependency conflicts with the Servlet API version that complicate supporting Karaf and Tomcat 7
   2. High-level benefits of OSGI are being able to add and remove modules at runtime, and not need the webapp-plus project to pre-compose different options

...

fcr:metadata and NonRdfSource descriptions

1. There are limitations to the NonRDFSource descriptions (fcr:metadata): can't use blank nodes or hash URIs, child nodes or child NonRDFSources
2. We can add some of that functionality to fcr:metadata, e.g. blank nodes and hash URI support – this seems uncontroversial and we can probably just file a ticket
3. The other use case is NonRDFSources that describe other NonRDFSources (e.g., FITS that describes a TIFF)
   1. This could be accomplished by creating child NonRDFSources, or making fcr:metadata a container, or allowing linking to a separate container
4. Option 2 is to make fcr:metadata a container, which would allow changes
5. General agreement that NonRDFSource descriptions should have a single subject and it should be the binary
   1. Some uneasiness about the subject, but having it be a single-subject description will make it easier to change if we look at how other LDP implementations handle this.
6. A different approach would be to allow creating different kinds of deletion policies:
   1. Delete the link
   2. Delete the linked resource
   3. Return an error
7. Supporting these different kinds of policies would be a Fedora-ism, but in support of LDP – maybe an extension.

8. Action: Esme will create two tickets:

   1. fcr:metadata should be a container
   2. fcr:metadata should have a single subject (the NonRDFSource URI) – this may exist

4.2.1 Release manager?

...