...
- Andrew Woods
- Nick Ruest
- Unknown User (acoburn)
- David Wilcox
- Osman Din
- Doron Shalvi
- A. Soroka
- Unknown User (daniel-dgi)
- Yinlin ChenBenjamin Armintor
- Egbert Gramsbergen
- John Doyle
- Michael Durbin
- Stefano Cossu
Agenda
- Code4Lib report-out
- Fedora Community Portland Common Data Model
- Islandora/Fedora 4 proof of concept (Camel)
- Use case Transformation of (meta)data for certain types of resources
- F4 and blank nodes
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.
POC For Proof of Concept for Islandora. Pretty rough, but does the job.
...
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 Egbert has use case for providing services (such as transformations) as objects in Fedora 4 to facilitate re-use (similar to disseminatorsdiseminators). 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 scolemize 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 anymoreany 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. Scolemnization 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.