Date: Thursday, July 07, 1pm EDT (-4 UTC)
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
Next meeting July 21