Skip to content
Natkeeran edited this page Apr 11, 2018 · 15 revisions

Time/Place

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

Attendees

  • Danny Lamb
  • Yamil Suarez
  • Natkeeran
  • Marcus Barneshttps://github.com/Islandora-CLAW/CLAW/wiki/April-11,-2018
  • Jared Whiklo
  • Rosie LeFaive
  • Seth Shaw
  • Jonathan Green
  • Mark Jordan (regrets)

Agenda

  1. https://github.com/Islandora-Devops/ansible-role-crayfish/issues/2

  2. Content Modeling Rodeo

    1. Taxonomies for Content Model and "Media Model" (e.g. DSIDs)
      1. Taxonomy terms can have fields, so an 'external uri' field is super easy to implement.
      2. Use a single bundle as metadata profile, tag with content model to drive behaviour
        1. Field Group module can get us pretty close to something that looks like a form builder form.
      3. If you need a different metadata profile, make another bundle! Nothing bundle specific at this point, it's all about tagging with taxonomies
      4. Use Permissions By Term module to associate roles with tags.
      5. Already have PR in to swap view and form modes using Context (which can easily be controlled via tags)
      6. Needs Structure Sync to guarantee consistency when installing / pushing to prod.
    2. Using core media module gives us audio and video entities with basic displays in addition to images and generic files.
    3. Reverse media relationships
      1. "Media Of" field analagous to "Member Of" (could even the same field, really)

      2. Use views to generate a "manage" page for media screenshot from 2018-04-11 13-20-12

      3. Action link to add media to node (use Prepopulate module to pre-fill form) screenshot from 2018-04-11 13-20-45

      4. Use EVA module to still display media through object display modes screenshot from 2018-04-11 14-37-38 screenshot from 2018-04-11 13-26-47

  3. Open questions left

    1. Ordering of child nodes / hierarchies (e.g. books and newspapers)
      1. Core book module - works, gives breadcrumbs and prev/next navigation with a hierarchy, but totally brutal UX
      2. Just use taxonomies? tempting, but feels wrong
      3. Entity Reference Hierarchy module - Basically adds a weight in addition to a parent reference. You get breadcrumbs for free, but admin page for children only works on immediate children (so hierarchy manipulation is a bit disconnected).
      4. Entity Queue - Creates orderings as config entities. Great views integration (you can use a queue as a sort in a view), used a lot, but still a bit clunky.
      5. Draggable Views - I see what it's trying to do, but it's buggy as all get out
      6. Weight - hijacks sticky field to use as a weight... pretty hacky
    2. Translating terms to RDF. What's better, a "hasContentModel" predicate with taxonomy terms, or using the taxonomy to enhance rdf:type?
    3. What to call entities for people/organizations? (I've been improperly using 'authorities').
  4. Priorities for release

    1. Content modeling
    2. Flysystem to avoid duplicating huge files and give better control over where files go
    3. Example migration (need not be from 7.x, but that'd be nice)
  5. ... (feel free to add agenda items)

Minutes

  1. https://github.com/Islandora-Devops/ansible-role-crayfish/issues/2 - Database column type issue
  • Seth - Default version of the MariaDB that CentOS supports does not support varchar(2048) UNIQUE, which is needed for large file paths. We have two options: get another version of MariaDB or use hashes for path to avoid this problem.
  • Seth - People have noted that they do not want introduce many repos.
  • Jared - Another option is to use postgresql.
  • Danny - I am fine computing the hash or getting MariaDB from another repo or using postgresql.
  • Seth - epel repository can be used. But, somebody did not want to use epel.
  • Danny - Yes, Adam did not want to use epel. Lets get input from Adam before proceeding.
  1. Content Modeling Rodeo
  • Danny - I've explored solutions so that we can avoid having to maintain many islandora content type modules and avoid repetitive administrative tasks. We had discussed using taxonomies of content types and media types (DSID) to drive the form and display of drupal content. By taking advantage of various drupal modules, we can get majority of the features we are looking for. This means we will be adding several more drupal modules as dependencies, which will be more like a Drupal distribution or profile. There are many advantages and some drawbacks to this architecture.

  • Danny - By using Permissions By Term, one can associate permissions/roles with a taxonomy term. This is fully integrated with Drupal subsystems. This provides a very fine level of access control.

  • Danny - We make use of views and EVA to manipulate the rendering of forms and display. We don't need to specify various form modes, except for additional customization is needed.

  • Danny - Taking Mark Jordan's concerns into consideration, I've also reversed the way a content type and media bundles are related. Media bundles will be aware of the content type they are part of, rather than content type consisting of media bundles. We loose some ability to apply restrictions on media bundles based on content type.

  • Jared - We can add these restrictions using alter and context.

  • Danny - When using Taxonomy, there is an additional challenge. Taxonomy is a content entity. Thus, they are not easy to export, except via the migrate module, similar to other content. In addition, we need to guarantee taxonomy ids. Because, views make use of taxonomy node ids. These ids are minted internally. Thus, when islandora gets installed, these ids need to be created. This poses an issue of installing islandora on existing Drupal instance where those taxonomy ids already exist. We can use Structure Sync to guarantee that Islandora specified ids are created.

  • Rosie - Is it possible to use other fields or properties instead of ids. Can we make use of the relationship module?

  • Danny - Maybe. From what I understand relationship module makes use of ids under the hood.

  • Rosie - Relying on taxonomy id is a concern.

  • Danny - We can consider using path auto + tokens. Views may have issues with them. This needs to be reviewed further.

  • Seth - This architecture seems to simply the rdf mapping.

  • Danny - We can use any content type as the metadata profile.

  • Rosie - If we want to switch the metadata profile from say MODS to DC, we can do that.

  • Danny - Yes.

  1. Open questions left
  • Danny - Manual ordering of book pages, newspaper etc remains another area of challenge. The default Drupal book modules does not provide a good user experience. Some of the modules I've tested such as Draggable Views are not mature. Further work is needed in this area.
  • Further discussion is deferred for next meeting.
  1. Priorities for release
  • Deferred for next meeting.
  1. Other - EDM - Support for Object/Thing vs Digital Representation or Work vs Instance
  • Rosie - I was reviewing the EDM? metadata standards, and they distinguish between the actual object and the digital representation. Similar to work vs instance in BIBFRAME. Does CLAW support this?

  • Danny - We have not addressed this issue yet. It will require work, specially with respect to solr and jsonld representation to support this.

  1. Other - Technical Metadata
  • Rosie - Where does technical metadata go?

  • Danny - Currently, technical metadata will go into the media bundle/resource.

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

⚠️ ARCHIVED Islandora Tech Calls

⚠️ ARCHIVED Islandora User Calls

Clone this wiki locally