Skip to content

December 7, 2016

Jump to bottom Edit New page
kim pham edited this page Dec 7, 2016 · 10 revisions

Time/Place

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

Attendees

  • Nick Ruest
  • Jared Whiklo
  • Diego Pino
  • Melissa Anez
  • John Yobb
  • Kim Pham ⭐
  • Bryan Brown
  • Danny Lamb
  • Ed Fugikawa
  • Amanda Lehamn
  • Don Richards
  • Jon Green
  • Marcus Barnes
  • Natkeeran Ledchumykanthan
  • Aaron Coburn

Agenda

  1. Supported outputs from CLAW other than PHP code (Vagrant, Docker, Ansible, etc)
  2. Response to call for RDF UI Use Cases https://groups.google.com/forum/#!topic/islandora/x2UaNrCElzo
  3. Fedora API specification update
  4. Fedora Camp slides
  5. Drupal tests!
  6. Newbie tickets

Minutes

Supported outputs from CLAW other than PHP code (Vagrant, Docker, Ansible, etc)

Bryan:

  • In islandora 1.x there is a clear separation of what goes in islandora vs islandora labs and the vagrant machine is part of islandora labs.
  • There is Docker, Ansible work in CLAW and older Docker repos, so wondering what the future is for Docker container support and Ansible etc or if it's the onus for individual community members to maintain

Nick:

  • Docker and Ansible work came from islandora roadmap committee/board of directors. Funding was available to use at the time Jan/Feb 2016 to use on Dockerizing the current stack - the alpaca/salmon 7.x-2.x stack and original proof of concept. Have a Docker and Ansible playbook, taking bash scripts for vagrant and turning into an Ansible playbook. This was fairly supported for 3-4 months but as soon as pivot happened to drupal 8, major rearchitecture so it was no longer a priority
  • Available in claw github, stagnant insofar as it is not yet worth the time and effort. Will eventually go back and port all the stuff to the current stack but in the backburner. in terms of what is officially supported: based on time resources in community and who in the community can stand behind it. initial work with Docker, vagrant bash scripts for rapid dev/deployment, as we move to a more production/release schedule, will need to be cleaned up or pick one or two or go with some other option e.g. Packer

Danny:

  • It is long term a priority, not immediate. right now still wiring fedora 4 with drupal 8. eventually would like a container based approach to fedora, future of deployments and personally want to see it thrive/succeed
  • As soon as have an MVP, then it will be a priority

Diego:

  • Don't think we have enough people to maintain that right now or in the near future
  • Depends on how fedora 4 will evolve, once api specification is ready would then feel more comfortable to say do a deployment
  • Any decision for deployment and time for support would not be worthwhile at this point

Bryan:

  • Tasked with learning more about Docker at FSU and looking at the Dockerized claw components taking to look at with Dockerized files, this may be a place to invest some time in the future. would like to help with time permitting.
  • Possible approach: vagrant machine running Docker inside

Danny:

  • That approach works, api-x doing it now

Nick:

  • Caveat to talk about this as a community, perspective from end users to install, documentation team, devops groups for technical install instructions
  • Could do it or could reach out to other groups, another voice to see what the community wants in terms of install instructions and options for claw, not to be a wishlist but instead a "we want this and this is what resources we can provide to it" is helpful

Danny:

  • Can be quite disorienting at first, limited working with Docker vs linux vm knowing where logs are. Good for production environments...but Hydra is complex too

Nick:

  • Hybox has funding from amazon. You can apply to amazon aws, microsoft azure and get educational grants for resources. Hybox meant to be a cloud service, not deployed locally. It's a hosted service, but it's changing a lot still. It's not a vagrant image.

Response to call for RDF UI Use Cases https://groups.google.com/forum/#!topic/islandora/x2UaNrCElzo

Amanda:

  • Want to also bring up use cases with MIG, wait to finalize use cases from that group

Bryan:

  • Same, want to also bring up use cases with IRIG, wait to finalize use cases from that group

Diego:

  • Perhaps we need a better understanding waht it means to user RDF instead of xml
  • This includes How to make institutional modifications in terms of defining what needs to be preserve in metadata. Things like transfer formats, store data then transfer in future to format we need, and how to modify forms and keep them up to date
  • What RDF is it means to use in theory and practice side by side with drupal framework

Danny:

  • Without falling into similar circular patterns, we have something to work with from these three use cases, see common elements, hidden feature requests so try to isolate that and try to isolate those, focusing on the RDF UI mappings
  • Wrapped up with this conversation is coming back to form builder, which is different from what an RDF UI would do. This comes back to diff forms and permissions and that's just drupal defaults
  • We need to focus on what is the core of this issue - dealing with vocabularies, import them and put whatever type of predicate you want and attach to a field. Putting it all in one spot and configuration for each field and working your way through it
  • But also keep the other use cases somewhere, these additional feature requests are good to have, such as exporting DC xml etc.

Bryan:

  • Explaining RDF, it's a cognitive leap to force people to understand how to use the form, one or two people to administer the mappings but actual form shouldn't look like namespaces/predicates which will be a major part of getting some adoption and uptake

Danny:

  • It'll be name, description fields, all things like dc:title will be hidden from the user
  • Using json ld to export metadata from RDF but hiding the complexities

Aaron:

  • The closer you get to front end of app, with for instance javascript developers who maybe never heard of RDF they should not have to understand RDF in order to work with the code

Jared:

  • also understanding that they don't want to be remapping constantly. getting engaged ahead of time, spend their own time learning about it. if they do wnat to change it, one metadata person who does the mapping is fine. 90% of staff doesnt have to see it, so no tweaking every third minute. worry push to fedora
  • will be easy for end user, like forms in drupal diego/danny/nat put together to play with output through serializer jsonld don't know oyu're doig that when creating drupal entity.

Amanda

  • So RDF UI is mainly targeting metadata manager people. working forms for users making sure they get what they need, sys install that's it.

Danny

  • Exactly. Go through extract things relate to user interface, control metadat amapping fields in RDF rest take note of, enshrine in other user cases nuggest of shared requests

Diego

  • Curent interface work schema.org. Wonder how to take over that project drupal module. Those use cases will convert into code later.

Nick to put in agenda for next time discussion of implementation of use cases

Kim:

  • Volunteering to coordinate consolidation of use cases, working with Amanda Jennifer and Bryan after their interest group meetings

Nick:

  • Report back for January 11 2017 meeting

Fedora API specification update

https://github.com/fcrepo/fcrepo-specification http://fcrepo.github.io/fcrepo-specification/

Nick:

  • Spec efforts, coming up at CNI andrew and robin UVA will be there presenting on spec

Aaron:

  • Draft really moving forward, plenty of time for comments but getting to the point where we can actually start working through comments requires having a full draft in place. pretty close to being in place now minor things left. link in agenda. look at editor's draft

Nick:

  • Plese comment on specifications
  • Will be multiple implementations of fedora, this will be a reference implementation. we as a community think about what we put our weight behind or none at all, any that adheres to the fedora api spec

Fedora Camp slides

Nick:

Drupal tests!

  • Wired travis previously copy paste detection, no tests to point it at for drupal modules. piece of functionality that didn't feel was covered under standard drupal stuff. slight modifications to code generated from drupal console/configs
  • Wrote kernel test, wired up travis and works - will be using moving forward
  • PR with test and will actually create a base test to extend for islandora
  • Setup kernel tests difficult, so this an example to write your own https://github.com/Islandora-CLAW/islandora/pull/21

Newbie tickets

Nick:

Danny:

You may be looking for the islandora-community wiki · new to islandora? · community calendar · interest groups · roadmap

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

⚠️ ARCHIVED Islandora Tech Calls

⚠️ ARCHIVED Islandora User Calls

Clone this wiki locally