Dial In Details
Date: Friday September 25, 2pm EDT (-4 UTC)
- 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
Meeting Goals
Updates on new use cases and discussion
Close loop on the AIC Use Case: Content and Structural Validation
Define the information that we want to extract from each use case
Attendees
Agenda
Summary of activity
- New use case contributions
- Amherst use cases from Unknown User (acoburn)
- Transactional use case from Justin Coyne
- Refined validation use cases from Stefano Cossu
- New discussion on:
- New use case contributions
Next Steps
- Close the loop, or come full circle on the AIC Use Case: Content and Structural Validation use cases
- Do the new use cases adequately represent the comment thread? Anything else to do with these particular use cases at the moment?
- Updating Use Cases Summary - API Extension Architecture
- Too early? Wrong format?
- Review initial list of "what to distill from use cases".
- Continue review
- Close the loop, or come full circle on the AIC Use Case: Content and Structural Validation use cases
- Any Other Business
- Elliot away: 9/28 - 10/28
Related Resources
Design Page (with use cases outline)
Previous meeting agenda, including minutes
Minutes
- Unknown User (acoburn) discusses Amherst use cases
- Currently, they use Fedora 3. Are in the process of wrapping items they currently do, or have always wanted to do, as web services
- Have implemented roughly half of the use cases submitted on the use cases page
- ID Service was motivated by decoupling business IDs from repository IDs
- For Fedora 3, they currently have a tight coupling between Fedora PIDs and fronted IDs. This is brittle
- Fedora 4 doesn't have PIDs, but at times object URIs become long and unwieldy.
- Has been in touch with Unknown User (daniel-dgi), as this service could address similar needs in Islandora
- Architecturally, this is a registry and a resolver service
- Camel routes listen for events, scan for particular RDF predicate whose associated value is an ID.
- Mapping between Repository URI and ID are stored in RDBMS
- API-X may be useful in exposing the resolver service, i.e. expose friendly URIs based on IDs, redirect to Fedora resources
- Embargo handling attracted a few comments
- WebAC working group has mentioned using WebACs as a mechanism of enforcing embargo.
- API-X may not be the most appropriate mechanism to update WebACs according to embargo policy
- It's just as important to specify where API-X may not be appropriate in support of use cases
- Exposing details about the nature of the embargo may be a task for API-X
- JSON-LD use case was motivated by desire to use JSON-native infra such as riak or MongoDB
- Is this equivalent to template rendering?
- No, but Amherst's use cases for template rendering involve accessing JSON-LD representation from the JSON-LD service
- Discussion on composition or chaining of extensions
- Can API-X be seen as a pipeline of services on requests on Fedora?
- This was thought about and briefly mentioned in the original proposal (see: Composability of API Extensions)
- The need to compose, pipeline, or chain extensions seems implicit in the design
- Amherst use case implementations explicitly make use of one another
- This is one reason why Camel makes an attractive implementation
- Similar patterns used in Smithsonian infrastructure
- JAX-RS, Camel, and OSGi+Karaf play very nicely together
- The term "chaining" is limiting, think "composition"
- There should be an explicit use case related to composition
- Unknown User (acoburn) to take initial stab at this, based on Amherst's experience
- Can API-X be seen as a pipeline of services on requests on Fedora?
- Discussion of transactions, motivated by ORE aggregation locking submitted by Justin Coyne (not present)
- This use case seems to highlight problems with using many Fedora objects to represent ordering of resources via ore:proxies.
- Essentially, it creates a linked list with Fedora objects as nodes. Certain changes to this list may involve updates to several objects
- Transactions via REST can be problematic
- Probably best for extensions not to use API-X to expose additional transaction semantics
- An essential pattern that will be seen all the time is for API-X to expose atomic operations to outside world which, implemented underneath, may involve transactions between extension as repository
- Extension is an actor in transaction, not outside client
- This use case seems to highlight problems with using many Fedora objects to represent ordering of resources via ore:proxies.
- Action item: Everybody read and comment on Use Case Evaluation, we'll discuss at next meeting.