Page tree
Skip to end of metadata
Go to start of metadata


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



  1. OAI Provider Predicates Prototype
  2. Database connector (see discussion here)
  3. F4 -> F4 Federation (see discussion here)
  4. Packer/Docker/Puppet for Graphite server?


OAI Provider Predicates Prototype

  • frank asseg was not on the call to discuss. 
  • Will move the discussion to next week.

Database connector

  • Proposed by Stefano Cossu and Nikhil Trivedi
  • Need to make a database available to view as nodes in Fedora
  • Similar to ModeShape metadata connector
  • Need to whitelist tables to make available
  • Map fields to node properties
  • Make data available
  • Need to create Fedora-specific nodes similar to file system federation
  • Seems like it would be generally useful to the community

F4 -> F4 Federation

  • Proposed by Stefano Cossu
  • Mirror particular content from one Fedora node to another
  • Use case: public Fedora mirror that only contains publicly available nodes (indicated with mixin)
  • ModeShape or JCR connector?
    • JCR-level might be more efficient
  • Greg Jansen: Maybe filter via access controls rather than federation?
  • Stefano Cossu: Need 2 Fedoras for load balancing and a public mirror outside the DMZ for security reasons
  • Michael Durbin: Federation layer is somewhat dumb. Difficult to emulate all repository functions between source and target
  • Greg Jansen: Probably easier to express security in a declarative way in one repository through XACML or something similar rather than running 2 nodes and trying to manage security via Federation
  • Stefano Cossu will work on this and report back

Packer/Docker/Puppet for Graphite server?

  • Packer script to generate a VM image?
  • Docker, Puppet, etc.?
  • Greg Jansen: Using Packer to make dev VMs on local machines

Handling Blank Nodes

  • Raised by Stefano Cossu
  • Blank nodes seem to be  somewhat supported in the latest build
  • Not sure if this comes from Fedora development or ModeShape?
  • No one on the call is familiar

Defining Order of Nodes in a Hierarchy

  • JCR has convention, ModeShape has an API, Fedora does not

  • Any thoughts on this?

  • Michael Durbin: Would like this a lot. Incompatible with RDF?

  • Stefano Cossu: Define with LDP properties?

  • Greg Jansen will add more detailed notes


  1. Regarding BNodes: I tested inserting the following RDF in a node (e.g.  http://localhost:8180/fcrepo/rest/z)

    DELETE { }
    INSERT {<> aic:customRel [
    aic:name "Custom BNode property" ;
    aic:author "scossu"
    WHERE { }


    And I find this new property in the node: 

    <> "7cef4351:148d19aeb67:-7ffe"^^<>


    As well as this new node on http://localhost:8180/fcrepo/rest/.well-known/genid/29dc3540-bce5-4324-bff8-74e230ab6937:

    <http://localhost:8180/fcrepo/rest/.well-known/genid/29dc3540-bce5-4324-bff8-74e230ab6937> <> <http://localhost:8180/fcrepo/rest/.well-known/genid/29dc3540-bce5-4324-bff8-74e230ab6937/fcr:export?format=jcr/xml> .

    <http://localhost:8180/fcrepo/rest/.well-known/genid/29dc3540-bce5-4324-bff8-74e230ab6937/fcr:export?format=jcr/xml> <> <> .

    <> <> "jcr/xml"^^<> .

    <http://localhost:8180/fcrepo/rest/.well-known/genid/29dc3540-bce5-4324-bff8-74e230ab6937> a <> , <> ;
    <> <http://localhost:8180/fcrepo/rest/.well-known/genid/29dc3540-bce5-4324-bff8-74e230ab6937> ;
    <> <> ;
    <> "true"^^<> ;
    a <> , <> , <> , <> ;
    <> "true"^^<> ;
    a <> , <> , <> , <> ;
    <> <http://localhost:8180/fcrepo/rest/.well-known/genid> ;
    <> "true"^^<> ;
    a <> , <> , <> , <> ;
    <> "nt:unstructured"^^<> ;
    <> "Custom BNode property"^^<> ;
    <> "scossu"^^<> ;
    <> "fedora:blanknode"^^<> ;
    <> "fb5c065b-3733-41a4-b01e-0e0a9a11b4a4"^^<> ;
    <> "true"^^<> ;
    a <> , <> , <> , <> .


    I see my custom properties stored there, but no relationship between the two nodes. 

  2. Regarding F4 Federation: Greg, I agree with you that Federation should not handle the complexity of access policies. That's why a REST API approach is better since the public mirror can request resources as a 'web' user and I can set up XACML policies in the master repo for what that 'web' user can get.