• Dial-in Number: (712) 775-7035
  • Participant Code: 479307#
  • International numbers: Conference Call Information
  • You may also call in using the VoIP dialer from a web browser, or Android/iOS apps
• 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

• Nick Ruest
• Jared Whiklo
• Daniel Davis
• Elliot Metsger
• Unknown User (acoburn)
• Ruth Duerr (at conference)
• Joshua Westgard (cannot attend due to conference travel)
• Bethany Seeger
• Katherine Lynch –> going to be late if able to attend – left my comments/suggested edits in the docs for review.
• Andrew Woods
• Stefano Cossu
• Diego Pino Navarro
• Hanh Vu

Agenda

1. Design docs - consensus that these are OK?  good to commit to GitHub?
   1. Follow up on #30 - Does API-X necessarily have to guarantee ontology resolution
   2. Follow up on #5 persisting data in repository.  Some open questions
      1. Can/should/must/ API-X be able to persist objects to the repository for its own purposes?
      2. Can/should/must API-X be configurable to specify a particular container (or containers) to inspect for API-X-related objects (service and extension definitions, ontologies, etc)
2. High level overview doc (#29)
3. Other updates
1. Unknown User (acoburn) and Bethany Seeger have started creating extension impls aligned with the current design draft
   1. These extension impls expose extension definition documents in OPTIONS body on service URI.  Should this be a pattern generally supported by API-X?  Required? 
2. Aaron Birkland has started implementing #10 and #12

Minutes

Discussion on finalizing design docs:

• Open questions:

• On GitHub issue #30 of whether API-X needs to guarantee the resolution of ontology:

• Consensus was not clear.

• Having a service solely responsibly for resolving ontologies or establishing API for ontologies resolution were suggested, but did not answer the core question of whether ontology resolution is a fundamental part of API-X architecture.    

• Compromising approach is to assert that this guarantee is not a fundamental part of API-X but we would provide an implementation to perform the resolution as a service that might persist the ontologies into the repository. This compromise was different than making ontology resolution a fundamental part of API-X

• From a practical standpoint, if API-X relies on ontologies to do reasoning, it will need to persist and make available ontologies in some manner.  It's just a question of whether it specifically persists them to the repository or not

• Conclusion:  API-X design shall include ontology resolution service.  At least one implementation of this service will persist ontologies to repo.

• On GitHub issue #5 on what degree can/should/must API-X be able to persist objects in the repository for its own use:

• The consensus was that API-X *CAN* persist objects for its own use.

• Specifying containers for API-X objects would allow API-X multi tenancy.

• We will postpone the movement of design doc into GitHub until all of the comments on them have been resolved, necessary diagrams are added and they have been appropriately wordsmithed.

• Ruth will be responsible to resolving comments on her overview doc.

• Aaron will be responsible for the rest of the design docs.

• Design docs should be cleaned up and finalized at 1 document/week, in the following suggested order:

  • Overview doc:  Jul 7 - 14

  • Extension definition & Binding: Jul 14-21

  • Service Discovery & Binding, Execution Jul 21-Aug 4

• Once all documents are cleaned up, they will be moved to GitHub signifying the end of active development on the document.  Maintenance through pull requests

Quick overview of Aaron Coburn’s and Bethany Seeger’s work  that are aligned with current API-X design:

• The work was not organized initially, but they were organized after the reading of API-X design docs. There were 4 categories of things: extensions, services, libraries, connectors.

• Services doesn’t know anything about Fedora resources, operates on inputstream or strings. Could operate outside of the context of Fedora

• Extensions make use of services and bind Fedora resources to services by exposing HTTP endpoint that will accept to path to Fedora resources.

• All of the extensions accept an option gives back RDF graph of what kind of objects the extensions can operate on

• Aaron B. is interested in the mechanism of binding to services this way. Elliot suggest some work to express Aaron C.’s and and Bethany Seeger’s work in the language of the design doc.

Next meeting July 21