Time/Place

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

Attendees 

Agenda

  1. Code4Lib report-out
    1. Portland Common Data Model
    2. Islandora/Fedora 4 proof of concept (Camel)
  2. Use case Transformation of (meta)data for certain types of resources
  3. F4 and blank nodes
  4. Back-porting bug policy, redux

Minutes

Topic not on agenda

Stefano:  Error on federation while ingesting large batches.  Still new and gathering information, will follow up with more.

Code 4 Lib Outcomes

Discussions of shared data model between Hydra and Islandora.  Document by Esme gives great guidance for structuring content in Fedora.  Been WIP since September in Hydra community.  Likely implemented concretely in Hydra installations around April and May.  A few edge cases still exist, but the foundation is solid and could be elevated.  There was discussion on predicates for differentiating between objects being members of other objects vs. objects being members of collections.

Proof of Concept for Islandora.  Pretty rough, but does the job.

Stefano has questions about the security framework for new data model.  Concerned about WebACL granularity.  Linking to multiple policies per resource would be beneficial.  That is, multiple policies applying to different properties on a single resource.  Also, questions on how policies would apply to transforms, and what the fallout of that would be if trying to use the transform without privileges.

Mike Durbin and Danny Lamb should talk about working together.  Dev time is at a premium, so perhaps between the two the ball could get rolling on a generic migration framework.

Egbert has use case for providing services (such as transformations) as objects in Fedora 4 to facilitate re-use (similar to diseminators).  Wants to push something like this on the Roadmap.  Andrew noted that fcr:transform is triggered on resource types, and could potentially be configured to use xslts in addition to ldpath.  Discussions turned to generic service framework.  Options are on the table, but a small, single, concrete use-case should be pursued so we can discover where the solution best lies (e.g. in Fedora, as a sequencer, outside in something such as Camel).  Image serving using IIIF has been identified, and Stefano can push that agenda.

F4 and Blank Nodes

Implementation of Blank Nodes seems inconsistent.  If you give fedora an rdf graph with blank nodes, it will take the blank nodes and skolemize them by giving them uris.  If you wish to retrieve the document, you will get it with the nodes referred to as ‘fedora:blankNode’.  By giving them uris, they’re not really blank nodes any more.  Question is do we continue doing this approach and perhaps take off the blank node type, or do we really make them anonymous resources within the context of the rdf and not make them dereferencable.  Complete removal of blank node support is not on the table. Skolemnization has to happen or they can’t be managed or persisted, but it’s a question of exposing them or not.  Blank nodes need to be cleaned up, and they will be if stored under the RDF that created them.  It’s been proposed to not use the well-known gen-id, and you can give the person the option to show or hide them by preprocessing them as you are inserting the document.  Aaron Coburn is willing to put a proposal together to move forward on this issue.

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