Date: Thursday, May 26, 1pm EDT (-4 UTC)

Attendees

Agenda

  1. Progress updates
  2. Agree on License and CLA - OK to merge?
  3. Devise a plan to choose concrete extension(s) to develop, see github issue
  4. Prioritize and assign issues for next two weeks

Minutes

 

  1. Updates
    • Fixed Fedora memory leak #23
      • Re-ran latency tests with jvisualvm to confirm increasing heap.
      • Took a look at heap, found pattern that suggested it might be Jersey's fault
      • Latency, throughput of simple GET requests to small containers improved substantially
      • Nick Ruest setting up Test #3 from the Performance and Scalability Test Plans interest group
    • Updated acrepo-apix to Camel 2.17.1 (see pull request)
      • Had to change Fedora context paths in to make sure the apix-core router matches Fedora context path, to avoid need for re-writing
    • Aaron Birkland has been doing a bit of literature review re: SSWAP and semantic web services in general
      • Ruth Duerr: We should invest time in making an approach work with API-X
      • Architecture should allow alternative approaches
    • Joshua Westgard put a proposed reorganization on the Design - API Extension Architecture page.  Comments welcome
  2. License/CLA merge agreed
  3. Extension development
    • Stefano Cossu: Does anybody have concrete plans to develop extensions in the near future, particularly simple ones?
    • Stefano Cossu: It would be best not to divert resources away from core, so simple extensions that institutions are working on anyway is probably the way to go
      • These would likely live in other repos
      • Adopt these as archetypes for extensions
      • Incorporate into API-X demos
    • Still makes sense to 'like' existing use cases and  discuss at next meeting
  4. Issue assigning

 

  • No labels

8 Comments

  1. Stefano Cossu

    Aaron Birkland I have a concrete use case for complex ingest: sending a multi-part request with some files and metadata and having API-X create a PCDM structure that Sufia can index and display, optionally kicking off an asynchronous characterization process. Could that be a PoC that you can build your own specific use case upon? 

    1. Aaron Birkland

      Hi Stefano Cossu - I missed this comment.  Let's talk about this.  At JHU, we've developed a standalone "package ingest" service whereby one constructs (via a tool) a BagIt archive containing binary content and domain objects (rdf resources whose content may be from some arbitrary ontology or domain model) . The service ingests the individual resources in the archive as repository resources.  The big difference may be that our package ingest service does not create semantics for the items it is ingesting (i.e. it wouldn't create a PCDM structure where none is present in the packaged content)

      1. Stefano Cossu

        Then your use case is actually simpler than mine!

        Sorry I missed the June 9 meeting, but we will have time to discuss this further I am sure. 

        I think about API-X as an abstraction layer for a client that does not need to know about PCDM or any other internal RDF structure between resources, so defining a content model and its CRUD interaction modes will provide a way for a client to rely on a simplified metadata and content structure to perform these interactions. E.g. the client can say, "here are some files and some metadata, create or update a new set of resources based on model X". 

        For lack of a short-term alternative we want to do this by having Sufia, which has this abstraction layer, expose its ingest functionality as an API that accepts a similar input as the GUI. For non-Hydra shops, however, this could be fulfilled by API-X. 

        1. Aaron Birkland

          Hi Stefano,

          Yes, I'd like to understand more about your use case.  I think CLAW may have a microservice that creates PCDM objects via a simplified API (https://github.com/Islandora-CLAW/PDX). I'm not sure how this matches up to the use case, but maybe it's an avenue to explore?  Maybe Nick Ruest or Diego Pino Navarro would know more.

          In any case, it would be really neat if the end result of this were some API that consumes this content structure, and maybe an implementation based on sufia or PDX.  Where API-X comes into the mix is if you want to wire in a particular impl and expose this API as a service on certain containers in the repository (e.g. a repository container exposes a "simple PCDM ingest" endpoint on it that creates resources in a hierarchy below it), or if you want to just use LDP and (via filtering requests to repository resources through an extension) add PCDM properties as "server-managed triples", if that makes sense.

           

           

           

           

          1. Nick Ruest

            PDX is still a work in progress as we are building it out. You can check out open issues on it here.

            Diego Diego Pino Navarro (never sure which is the right account for Diego (smile)) Jared Whiklo and I can talk more about it if need be.

  2. Joshua Westgard

    Hi all – there is a meeting planned for today, correct?  I cannot find a wiki page for it. Or did we decide that folks would be too busy preparing to travel to Dublin?

    1. Aaron Birkland

      Sorry, I've been slow.  I just put it up a few minutes ago:

      2016-06-09 Fedora API Extensions Meeting

       

       

      1. Joshua Westgard

        No problem!  I will rearrange/cleanup the wiki page a bit before the meeting.

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.