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

• Aaron Birkland
• Unknown User (acoburn)
• Stefano Cossu
• Daniel Davis
• Ruth Duerr
• Rosie Le Faive
• Elliot Metsger
• Nick Ruest
• Bethany Seeger

Agenda

1. Summary of activity

   1. New use case contributions
      1.  Amherst use cases from Unknown User (acoburn)
         1. Amherst: template rendering service, 
         2. Amherst: binary derivative generation, 
         3. Amherst: ID service, 
         4. Amherst: embargo handling, 
         5. Amherst: JSON-LD compaction service, 
         6. Amherst: async digital preservation to external storage
         7. Amherst: Render fedora metadata resources as MODS/XML
      2. Transactional use case from Justin Coyne
         1. Use case: ore:aggregation locking
      3. Refined validation use cases from Stefano Cossu
         1. Enforce validation across repository
         2. Optional validation
         3. Validation only for selected resources
   2. New discussion on:
      1. Amherst: embargo handling
      2. Use case: ore:aggregation locking

2. Next Steps

   1. Close the loop, or come full circle on the AIC Use Case: Content and Structural Validation use cases
      1. Do the new use cases adequately represent the comment thread?  Anything else to do with these particular use cases at the moment?
   2. Updating Use Cases Summary - API Extension Architecture
      1. Too early? Wrong format?
   3. Review initial list  of "what to distill from use cases".
   4. Continue review
3. Any Other Business
   
   1. Elliot away: 9/28 - 10/28

Related Resources

Design Page (with use cases outline)

Use Cases Parent Page

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
• 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
• Action item: Everybody read and comment on Use Case Evaluation, we'll discuss at next meeting.