You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 14 Current »

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. Fedora Community 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
  5. ...

Minutes

 

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.

POC 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.

Eggbert has use case for providing services (such as transformations) as objects in Fedora 4 to facilitate re-use (similar to disseminators).  Wants to push something like this on the Roadmap.  Andrew noted that fcr:transform is triggered on resource types, and could 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 scolemize 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.

  • No labels