Skip to content
Nick Ruest edited this page Jun 8, 2016 · 7 revisions

Time/Place

This meeting is a hybrid teleconference and IRC chat. Anyone is welcome to join. Here is the info:

Attendees

  • Martin Dow
  • Jared Whiklo ⭐
  • Bryan Brown
  • Nick Ruest
  • Diego Pino
  • Melissa Anez

Agenda

  1. June sprint planning
  1. Code Coverage!!!
  1. ... (feel free to add agenda items)

Minutes

  1. & 2. Sprint will be July 20 - July 1

    Canada Day is July 1st, so any Canadians will be done a little early.

    Nick will not be around for the first week, so Jared has been roped into the duties.

    Related is Code Coverage, which is free compared to Coveralls. Chullo has coverage reports set-up.

    Nick is setting up PRs for PDX and Crayfish.

    Bryan: Is a coverage percentage of 100% possible?

    Nick: I've seen most be in the 80-90s% range. I'd be happy to get the badge green.

    Jared: Due to how early we are and how our development is going if we write tests as we add code, we should be able to be in the 90%.

    Sprint objectives

    • Writing more tests
    • PCDM Object Service - Bryan is working on it.
    • Data modelling
    • Drupal integration

    This Friday (June 10) Roadmap will vote on the Drupal 8 Prospectus, then we could switch gears to Drupal 8 and burn Drupal 7 to the ground.

    Nick created a bunch of newbie tickets and then a wonderful person (@sowla) from the Max Planck Institute in Munich came along and did some of them. https://github.com/Islandora-CLAW/CLAW/issues/263

  2. See above

  3. Other stuff

    Martin is interested in PCDM and Diego working on a rules engine and named graphs. Lots of questions raised at last weeks calls and is interested in our work. Like whether we want to write some of our data modeling constructs in the codebase like Hydra does it.

    Jared: That may have been my notes. The path of a Hydra route is not the way we want to go.

    Martin: Is the Hydra route a learning experience for how not to deal with PCDM?

    Diego: Yes, RDF is too complex to limit it to fixing it in the code. You need to give your users the tools to create RDF that fit their needs. Martin is looking at a interoperability exercise in the near-ish future.

    One of the things I would like to research is how restrictive is the base of a ORE aggregation.

    ORE creates a named graph, and get to a higher tree level it becomes restrictive and on the PCDM side we don't have the resource map to tell where one resource map ends and where the next begins.

    Martin: Is the proposal to use named graphs to do the digging down inside of ORE Resource Maps.

    Is there anything in the Hydra community that are not using Resource Map.

    Diego: The are defining the Resource Map as implicit on the object and this creates a problem when you want to lazy link one aggregation to another.

    There may have been a suggestion to use hashes to describe this, but has not be developed (that we know).

    It is on-going research and we will have to investigate. Especially before we get to higher level models.

    Martin is working with colleagues in Italy on OKKAM and he would like to integrate it to Islandora. Idea is you can use some machine learning to converge data points together. The ontology guides the machine learning process. This is dealing with the data, but doesn't provide much for the lifecycle management for the data. This is where he is hoping to bring Islandora into the mix.

    Diego: If you could open a ticket with your use case, so we don't lose this. Machine learning and business rules, what ever you are using and/or need.

    Martin: Is there a skeleton to base this off of?

    Diego has his notes for his OR talk. He will put it up somewhere.

    Martin: Is there another application of ORE in production in the wild?

    Diego: The Research Objects ontology is a very interesting one that is in wide use.

    The ontology is here: http://wf4ever.github.io/ro/ and they have an LDP mapping.

    There are ShEx which is a rule data modelling language. If you have a built graph and you want to reuse it to create more resource graphs. How do you store this? One way is in a repository but the other way is to have a meta-meta data model that verifies that it is a valid graph but not an instance and then allow you to use it.

    Martin: Will fleshing this out be part of the next sprint?

    Diego would like to spend some more time on this to create a microservice to do this storage.

    Martin: Would it be good to move towards Drupal 8 now?

    Nick: We are waiting for a response from the foundation's roadmap committee on the Drupal 8 prospectus. The benefit of the microservices is the ease of pivoting from Drupal 7 to 8.

This is an archive. For new Tech Call notes, click here

⚠️ ARCHIVED Islandora Tech Calls

⚠️ ARCHIVED Islandora User Calls

Clone this wiki locally