Skip to content
Jared Whiklo edited this page Mar 23, 2016 · 4 revisions

Time/Place

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

Attendees

  • Jared Whiklo
  • Melissa Anez ✨
  • Ed Fugikawa
  • Ben Rosner
  • Rosie LeFaive

Agenda

  1. Sprint updates

Minutes

Jared has added stuff to vagrant to make it spin up with services accessible on port 8282. PHP microservices generate PCDM objects. If folks want to try pulling down the new branch, go into install directory and do vagrant up. Fcrepo on 8080, along with Blazegraph and Drupal. Still a work in progress, but can be tested out now as a more 'sane' development environment. Ed will try it out today and other testers are requested to make sure this really works. Associated pull request

Ed asks: At this link, where you can copy the url, why does it say "your account islandora.git"?

Jared: It's a branch on his repo, so set him up as a remote or clone the repo.

Ed: If I git-clone, it brings down the wrong version.

Jared: try git checkout -b vagrant whikloj/sprint-002-thinCollection. Keep it separate from any 1.x Islandora. Priority for short term development is to get Drupal talking to microservices to make sure everything is working ok.

Ed: are we looking to create a container that is essentially a bin, and inside that bin is all the information about the object?

Jared: direct and indirect containers are part of the LDP spec. Not sure, when we're adding things, if we want to add them directly within the container as children, or put them anywhere in the repo and add a proxy objects that makes a link? The problem with F3 was that depending on how you repo is laid out, it can get slow when it's too "wide" or has too much on one level. F4 mitigates that. Is it better to let it put stuff where it thinks is best for balance and add these connections?

Ed: That answers the question. Keeping things from getting to heavy at one level. Worries bout losing those links, but not sure if that's a valid concern.

Jared: The link is an object itself. If you lose that link object, it's akin to losing any object. Its not a 'less important' resource. The lose would indicate a severe problem with Fedora or Modeshape. But we haven't decided yet on which approach to take. PCDM is still in its infancy and we are developing along with it. Hydra has already developed something and is changing to PCDM. Work is being done on consensus between the two communities. Stresses that we need ideas and opinions because this is all still being discussed.

Rosie: Going back to the higher concepts. Islandora is usually using for visual presentation. We have metadata and derivatives and present an OBJ as the 'thing" we are preserving. If we are splitting that up we could go the route of museums. For example, if you have a sculpture, it's unlikely to be described by a single digital object. This could make us more useable to the general GLAM community by not restricting us to the concept of objects that we had with 7.x-1.x.

Jared: Diego had some suggestions along this line, where we split things up into Drupal entities instead of nodes. Because Fedora is going to store each RDF and non-RDF object as different objects and every non-RDF has an RDF description, we'll have all this metadata about the different representations. We can have the sculpture and its metadata, and all the scans, and everything else relating to that item. Nothing is tied to the 'parent' object, but rather linked via relationships. We;re already doing it this way in the backend.

Rosie: I installed the CLAW/CLAW version, make a new collection, went to frcepo:REST and I don't see it. Am I not looking in the right place? It says 0 children.

Jared: Using Chrome? Shift+reload. It caches the page. If they don't show up, do you have the fcrepo path for that object?

Rosie: I threw a word in to see if I could force it to have a certain Fedora path

Jared: I don't know what effect that would have. That should probably be a label or uneditable field. That's probably where the problem comes from. You have to do a PUT in Fedora to define where it goes. What you did may have modified the outgoing RDF in a way it wasn't prepared for.

Rosie: Tries that. Still not getting written to Fedora. Just throwing in a title and nothing else.

Jared: Ok. Something has gone awry in the camel framework. Probably at the collection service, since it's not even getting to Fedora.

Rosie: When you're developing this stuff, where are you working with it?

Jared: The camel code is available externally. You can go in and make your changes and then recompile them in the VM and in karaf you restart the service. It's supposed to watch and update automatically, but karaf inside a VM seems to have some issues that don't show up outside a VM. Haven't heard of this in production. Depending on how interested you are, you can check out the logs in /opt/karaf/data/logs. There is much stuff in there. Other option is to destroy your vagrant install and try again. Maybe when it came up, something failed. You could also go into your karaf client and see if any of your bundles are not running- go to /opt/karaf/bin/client and use bundle:list | grep islandora (Diego adds from irc that tail -f /opt/karaf/data/logs/camel.log is also an option). If it's just an issue with how karaf started, you can just shut down and restart karaf in the VM. sudo service karaf-service restart

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

⚠️ ARCHIVED Islandora Tech Calls

⚠️ ARCHIVED Islandora User Calls

Clone this wiki locally