├── meetings
├── 02.md
├── 06-xml-forms-special-meeting.md
├── 08.md
├── 12.md
├── 01.md
├── Denver - CO Fedora 4 Training Workshop - 16 Oct 2014.md
├── 11.md
├── 10.md
├── 07.md
├── 05.md
├── 03.md
├── 06.md
├── 09.md
└── 04.md
├── design
└── gdd.md
└── README.md
/meetings/02.md:
--------------------------------------------------------------------------------
1 | # Islandora Fedora 4 Interest Group: Meeting 02
2 |
3 | ## August 21, 2014 11:00-12:00 ADT
4 |
5 | ## Agenda
6 |
7 | 1. Review of last meeting
8 |
9 | 2. Project plan
10 |
11 | 1. What’s missing
12 | 2. Estimating the level of effort to plan and build an initial prototype
13 | 3. Who needs to be involved?
14 |
15 | 3. Resources
16 |
17 | 1. Who can do the work?
18 | 2. How do we secure funding and coordinate development effort?
19 | 3. Which institutions should we reach out to?
20 |
21 | ## Attendees
22 |
23 | * David Wilcox (DuraSpace)
24 | * Nick Ruest (York University)
25 | * Danny Lamb (discoverygarden)
26 | * Kevin Clarke (UCLA)
27 | * Rosemarie Le Faive (UPEI)
28 | * Caleb Derven (University of Limerick)
29 |
30 | ## Notes
31 |
32 | **Review of last meeting**
33 |
34 | Nick reviewed the [minutes from the last meeting](https://github.com/Islandora/Islandora-Fedora4-Interest-Group/blob/master/meetings/01.md)
35 |
36 | **Project plan**
37 |
38 | Initial questions
39 |
40 | * Peter: Is this the right time to rewrite the software?
41 | * Danny: Ideally yes, but it depends on available resources.
42 | * Rosie: Do we need to design a new data model?
43 | * David: We can use the same data model in Fedora 4 that we used in Fedora 3, but there are new opportunities to change/improve.
44 |
45 | Building a prototype
46 |
47 | * Danny: How we choose to use Fedora 4 will dictate how we port tuque, which will dictate the rest of the integration process.
48 | * The first attempt will be to mirror what we do in Fedora3 with Fedora4 and then figure out how to affix JCR properties at a later time.
49 | * Need to define MVP for Fedora4 integration.
50 |
51 | **Resources**
52 |
53 | * We should make a plan first, then pitch that to get funding (not the other way around!)
54 | * Create a document similar to the [Fedora 4 Prospectus](https://wiki.duraspace.org/display/FF/Fedora+Four+Prospectus)
55 | * dgi will most likely contribute Danny and Adam’s time on a rolling basis sometime after October.
56 | * It is important that this is a community effort, particularly for the distribution of knowledge of the codebase.
57 |
58 | ## Actions
59 |
60 | * Add detail and estimates to the [Project planning document](https://docs.google.com/document/d/17Rl7qC5CRHfiMLQnRiMqdp5kR7kcL9ok-Bb9MJkwUgE) for an initial MVP (Danny)
61 | * Create prospectus for the work that includes financial and development resources requirements (David and Nick)
62 |
--------------------------------------------------------------------------------
/design/gdd.md:
--------------------------------------------------------------------------------
1 | #Islandora 7.x-2.0 General Design Doc
2 |
3 | Islandora is lightweight, scalable middleware that connects a Fedora Commons JCR with a Drupal CMS and offers a pipeline of RESTful services for the common tasks such as thumbnail generation and metadata extraction.
4 |
5 | ### Design Summary
6 | In the end, Islandora is built on the premise of using the right tool for the right job, and there's plenty of different jobs that all have to get connected together. That's why it's middleware. Shoehorning all tasks through a single solution is inappropriate, and leads to unsatisfactory results. A JCR is not a relational database, which in turn is not a triple store. A preservation system shouldn't be serving thumbnails, they should reside on a CDN. A web server shouldn't be converting video files, it should be serving web pages.
7 |
8 | In order to achieve this, Islandora adheres to the following design principles:
9 |
10 | ##### Decoupled
11 | Although Islandora connects two popular pieces of software, it references neither unless absolutely neccessary.
12 |
13 | ##### Asynchronous
14 | Islandora makes extensive use of messaging and queues, so that data can be processed when and where appropriate.
15 |
16 | ##### Distributed
17 | The all-in-one setup is fine for small organizations with small amounts of data, but heavy usage and content will quickly crush even the beefiest of servers. All of the important components that Islandora glues together are capable of running on individual hardware. This includes but is not limited to:
18 | - Fedora
19 | - Drupal (Both web server and db)
20 | - Services pipeline
21 | - Activemq
22 | - Logging
23 |
24 | ##### Invisible
25 | Fedora content are Nodes, and therefore first-class Drupal citizens. This opens up the whole Drupal ecosystem to the Islandora community. The end user feels like they are using Drupal, with changes automatically making their way to Fedora. Conversely, content manipulation directly in Fedora is reflected in Drupal.
26 |
27 | ##### Installable
28 | With a stack this big, installation is too complicated to be manually left up to the user. Each component has installation scripts, which can be combined to construct any type of infrastructure that fits the need of your organization.
29 |
30 | ##### Flexible
31 | Each organization has different needs, utilizing different metadata standards with different types of data. If options for manipulating, displaying, and processing a particular type of content are not out-of-the-box with Islandora, adding it is straight forward.
32 |
--------------------------------------------------------------------------------
/meetings/06-xml-forms-special-meeting.md:
--------------------------------------------------------------------------------
1 | # XML Forms Special Meeting
2 |
3 | ## May 5, 2015
4 |
5 | Call details: Skype
6 |
7 | ## Agenda
8 |
9 | 1. Expanded discussion on [Islandora 7.x-2.x Issue 28](https://github.com/Islandora-Labs/islandora/issues/28).
10 |
11 | ## Participants
12 |
13 | * Andy Wagner (UofT)
14 | * Kim Pham (UTSC)
15 | * Lingling Jiang (UTSC)
16 | * Jared Whiklo (University of Manitoba)
17 | * Chuck Schoppet (USDA)
18 | * Melissa Anez (Islandora Foundation)
19 | * Nick Ruest (York University)
20 | * Danny Lamb (dgi)
21 | * Robin Dean (Colorado Alliance of Research Libraries)
22 | * Mark Jordan (SFU) :star:
23 |
24 | ## Notes
25 |
26 | Focus on https://github.com/Islandora-Labs/islandora/issues/28
27 |
28 | * Danny: Xpath Field module works well for display, but doesn't write content to XML fields. jquery.xmleditor and doctored.js would need a lot of work to function within Drupal. Form Builder is still a real possibility but there are sustainabilty issues.
29 |
30 | * Robin asked how Hydra allows editing of XML binaries. Nick responded that there is no single way that they handle metadata. We know that we need MODS plus any other metadata schemas that exist in the Islandora. MODS-RDF is not a viable option at this time.
31 |
32 | * Long passionate discussion about treating XML Form Builder as an integral component and not a "utility module." This is an organizational issue, not a technical issue.
33 |
34 | * Option of moving the form <-> XML translation to the middleware. Robin points out that we need to be able to keep doing bulk XML metadata ingests, and the middleware approach would accommodate this. Also that we need to be able to customize transformation and not need to rely on the LoC transformations.
35 |
36 | * Use case of having a general XML editor, not just a descriptive metadata-specific solution.
37 |
38 | * Technical metadata will be properties on a file, but we'll still need to accommodate a FITS datastream/binary file (for example). See Hydra [Technical Metadata Application Profile](https://wiki.duraspace.org/display/hydra/Technical+Metadata+Application+Profile).
39 |
40 | * Chuck described how the USDA Agricultural Library uses Form Builder to heavily.
41 |
42 | * Robin nailed it: "In Fedora 4 we will need to be able to create XML, edit it, transform it, and index it". Many thumbs were raised to support this general use case. Lots of support for making a business case for sustaining Form Builder.
43 |
44 | * Action item: Nick to create a Google Doc to gather feedback to determine which features are must-have and which are not used: [Islandora XML Forms 2.x -- Functional requirements](https://docs.google.com/document/d/1zkyy40v4lz03rpjpmVHWujU9LQcxrsA4EC75D1d7X7A/edit?usp=sharing)
45 |
46 | * Danny brought up the question of whether we edit RDF triples in (a version of) Form Builder. Lots of discussion but we need to address this question before we move ahead on adopting FB as our XML editor.
47 |
--------------------------------------------------------------------------------
/meetings/08.md:
--------------------------------------------------------------------------------
1 | # Islandora Fedora 4 Interest Group: Meeting 08
2 |
3 | ## June 23, 2015 1:00-2:00 EST
4 |
5 | Call details:
6 |
7 | Call-in number - 866-994-3769
8 | Participant Code - 3226955
9 |
10 | IRC:
11 | Join the #islandora chat room via Freenode Web IRC (enter a unique nick)
12 | Or point your IRC client to #isladora on irc.freenode.net
13 |
14 | ## Agenda
15 |
16 | 1. Introductions
17 | 2. OR2015 updates
18 | * [Upgrading? Migrating? There’s a portmanteau for that!](http://hdl.handle.net/10315/29516)
19 | * [Islandora and Fedora 4; The Atonement.](http://hdl.handle.net/10315/29505)
20 | 3. [migration-utils](https://github.com/fcrepo4-labs/migration-utils) updates
21 | 4. [Portland Common Data Model](https://wiki.duraspace.org/display/FF/Portland+Common+Data+Model) ([repo](https://github.com/duraspace/pcdm)) updates
22 | 5. Drupal integration updates
23 | 6. [Use cases](https://github.com/Islandora/Islandora-Fedora4-Interest-Group/labels/use%20case)
24 | 7. [WebAccessControl](https://groups.google.com/forum/#!topic/islandora/lwP7bUIlvAc)
25 |
26 | ## Attendees
27 |
28 | * Nick Ruest (York University)
29 | * Danny Lamb (discoverygarden)
30 | * Melissa Anez (Islandora Foundation) :star:
31 | * Jared Whiklo (University of Manitoba)
32 | * Kim Pham (UTSC)
33 | * Mark Cooper (LYRASIS)
34 | * Andrew Woods (Duraspace)
35 | * David Wilcox (Duraspace)
36 | * Kevin Clarke (UCLA)
37 |
38 | ## Notes
39 |
40 | * OR2015 updates:
41 | * Pretty fantastic. See agenda for links to presentations relating to Fedora 4. Danny gave a high-level review of the stack. Important points: RDF to drupal, with user interfaces to handle the mapping! Use xpath to extract metadata and use that to create a drupal field. "Add Content" now works!
42 | Migration Utils:
43 | * A brave soul is trying out migration utils with Fedora 2
44 | * A few things left to do with checksums and we will have a generic Fedora 3 to 4 upgration tool. Next step is to use the PCDM. May be a sidecar util, may be a standalone tool.
45 | * PCDM: a group got together and worked through issues around ordering. See links in the agenda if you have opinions about ordering in PCDM.
46 | * Rob has put together some diagrams.
47 | * Nick and Karen are going ot migrate the PCDM info from the wiki to github.
48 | * Andrew will do some work to make PDCM.org a thing.
49 | * Integration updates:
50 | * Danny talked to a lot of folks at OR2015. Feedback is informaing the project. The biggest change: excising the java part of the stack (still using Camel, but just XML DSL). For processing, command-line PHP, which should be more comfortable for the Islandora community. Goal is to lower the barrier to contribution.
51 | * Starting serious work to make the project easier to share. Tickets are coming, some marked for "newbies" to take on as an entry point to the project. Basic Image SP will be the first target. Contributors SO welcome!
52 | * A project update is coming. We have met and/or exceded pretty much all of our goals (not basic Image SP, but the over-acheivements on everything else kinda make up for it).
53 | * WebAccessControl
54 | * Am informal call with the Fedora group is coming up tomorrow to talk about how this might be integrated (all are welcome!). WAC is an emerging W3C standard and a way to move away from XACML (not that we're doing away with XACML!). Also has opportunities for a PCDM-like universal access control standard. Hydra stores their access control in Fedora using access conrol ontology.
55 | * Other ways we can get folks involved:
56 | * Nick will send a friendly note out to the listserv to welcome folks in on entry level tickets
57 | * If anyone wants ot help craft that message, it's welcome
58 | * Organize some sprints? Maybe a joint Fedora/Islandora sprint, with tweaks at both levels.
59 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 | # DEPRECATED - [Join us on weekly CLAW CALLS](https://github.com/Islandora-CLAW/CLAW/wiki#islandora-7x-2x-tech-calls)
2 |
3 |
4 | # Islandora Fedora 4 Interest Group
5 |
6 | ## Convenors
7 |
8 | * Nick Ruest (York University)
9 | * Daniel Lamb (discoverygarden)
10 |
11 | ## Terms of Reference
12 |
13 | * The name of the IIG is the Islandora Fedora 4 Interest Group
14 | * The purpose of the Islandora Fedora 4 Interest Group is to implement Fedora 4 in the context of Islandora.
15 | * [Islandora/Fedora 4 Prospectus](https://docs.google.com/document/d/1Qge1EKDkISNugfZQCaNzK6rJptgmWV37OO_s65Wgw3c/edit)
16 | * [Islandora/Fedora 4 Project Plan](https://docs.google.com/document/d/1C6JvuHEJok4FxnXsZoLNGAMGYCezY_Utz6SDht3CZdU/edit)
17 | * Specific goals, activities, outcomes may include:
18 | * Create a generic "[upgration](https://wiki.duraspace.org/display/FF/Fedora+3+to+4+Upgration)" document for Islandora and:
19 | * Identify pilot partners
20 | * [York University](https://wiki.duraspace.org/display/FF/Upgration+Pilot+-+York+University)
21 | * Reviewing Fedora 3 to 4 [Upgration Checklist](https://wiki.duraspace.org/display/FF/Fedora+3+to+4+Upgration+Checklist) and:
22 | * Identifying what features are neccessary in Fedora 4
23 | * Mapping Fedora 3 features to Fedora 4 features
24 | * Mapping Fedora 4 features to Islandora
25 | * Determining how Islandora will leverage new Fedora 4 features
26 | * Outreach and communication
27 | * Engaging other interested Islandora community members
28 | * Recruiting developers to work on integration tasks
29 | * The interest group will meets weekly virtually ([call-in info](https://github.com/Islandora-CLAW/CLAW/wiki/January-20,-2016#timeplace). A call for agenda items will be posted to the Islandora Google Group 1 week prior to the meeting. The convenor will appoint a note taker for the meeting and meeting notes will be made available at some url.
30 | * The convenors will produce a report to be submitted to the Islandora Roadmap Committee following the IF4IG’s meeting.
31 |
32 | ## Links
33 |
34 | * [Fedora 4 Downloads](https://wiki.duraspace.org/display/FF/Downloads)
35 | * [Denver, CO Fedora 4 Training Workshop](https://wiki.duraspace.org/display/Events/Denver%2C+CO+Fedora+4+Training+Workshop+-+16+Oct+2014)
36 | * [Fedora 3 to 4 Data Migration](https://wiki.duraspace.org/display/FF/Fedora+3+to+4+Data+Migration)
37 | * [Fedora 3 to 4 Upgration Pilots](https://wiki.duraspace.org/display/FF/Fedora+3+to+4+Upgration+Pilots)
38 | * [Fedora 4 Glossary](https://wiki.duraspace.org/display/FEDORA40/Glossary)
39 | * [Fedora 4 Ontology](http://fedora.info/definitions/v4/repository)
40 | * [Fedora Community Data Model](https://wiki.duraspace.org/display/FF/Fedora+Community+Data+Model)
41 | * [Upgration](https://wiki.duraspace.org/display/FF/Fedora+3+to+4+Upgration+Pilots)
42 |
43 | ## Membership
44 |
45 | * David Wilcox (DuraSpace)
46 | * Mark Leggott (UPEI)
47 | * Martin Dow (Acuity Unlimited)
48 | * Kevin Clarke (UCLA)
49 | * Mark Jordan (SFU)
50 | * Ernie Gillis (Berklee)
51 | * Peter Murray (LYRASIS)
52 | * Euwe Ermita (UWS)
53 | * Donald Moses (UPEI)
54 | * Chad Nelson (LYRASIS)
55 | * David John Evans
56 | * Andrew Woods (DuraSpace)
57 | * Ed Fugikawa (Colorado Alliance)
58 | * Caleb Derven (University of Limerick)
59 | * Jared Whiklo (University of Manitoba)
60 | * Ashok Modi (Cherry Hill Company)
61 | * Nick Ruest (York University)
62 | * Andy Wagner (University of Toronto)
63 | * Daniel Lamb (discoverygarden)
64 | * Lingling Jiang (UTSC)
65 | * Kevin Bowrin (Carleton University)
66 | * Melissa Anez (Islandora Foundation)
67 | * Logan Cox (University of Oklahoma)
68 | * Tao Zhao (University of Oklahoma)
69 | * Alex Garnett (SFU)
70 | * Diego Pino (REUNA)
71 | * Kim Pham (UTSC)
72 | * [James Griffin (Lafayette College Libraries)](https://github.com/jrgriffiniii)
73 | * Chuck Schoppet (USDA)
74 | * Mark Noble (Marmot Library Network)
75 | * Jordan Fields (Garfield County Libraries)
76 | * [Marcus Emmanuel Barnes] (https://github.com/MarcusBarnes) (Simon Fraser University)
77 |
--------------------------------------------------------------------------------
/meetings/12.md:
--------------------------------------------------------------------------------
1 | # Islandora Fedora 4 Interest Group: Meeting 12
2 |
3 | ## October 23, 2015 1:00-2:00 EST
4 |
5 | Call details:
6 | * Call-in number - 866-994-3769
7 | * Participant Code - 3226955
8 | * IRC:
9 | * Join the #islandora chat room via [Freenode Web IRC](https://webchat.freenode.net/) (enter a unique nick)
10 | * Or point your IRC client to #isladora on irc.freenode.net
11 |
12 | ## Agenda
13 |
14 | 1. Introductions
15 | 2. [Committers Process](http://islandora-labs.github.io/islandora/contributing/committers/)
16 | * Welcome
17 | * Diego Pino
18 | * Aaron Coburn
19 | * 7.x-2.x Committers/Tech calls
20 | 3. [Chullo](http://github.com/islandora-labs/chullo)
21 | 4. [Porkpie](https://github.com/daniel-dgi/porkpie)
22 | 5. Coding standards
23 | 6. [Hydra/Islandora Common Practices](https://docs.google.com/document/d/1BDrInNgg2aA6i6i4fi7zH6pK6HfsPamJgkce3pjRslg/edit#heading=h.uk7m472me211)
24 | * Islandora Camp CT
25 | 7. Sandbox - future.islandora.ca
26 | 8. Community sprint
27 | 9. Selecting a PHP microframework based on [this conversation](https://github.com/islandora-interest-groups/Islandora-Fedora4-Interest-Group/issues/38)
28 |
29 | ## Attendees
30 |
31 | * Nick Ruest (York University)
32 | * Danny Lamb (discoverygarden) :star: (1-5)
33 | * Melissa Anez (Islandora Foundation) :star: (6-9)
34 | * Diego Pino (REUNA)
35 | * Jared Whiklo (University of Manitoba)
36 | * Aaron Coburn (Amherst College)
37 |
38 | ## Notes
39 |
40 | (See also [irc log](http://irclogs.islandora.ca/2015-10-23.html) from 13:00-14:00)
41 |
42 | 6. Danny went to HydraConnect for a day, met up with the Hydra folks and talked about interoperability. Worked out some issues with PCDM around descriptive metadata. Concluded that we can stick things like DC terms on files, even though PCDM files aren't really supposed to have descriptive metadata. No naming conventions for LDP containers. You should have to do a query to find members of a file's container. Talked about read-only versus read-write interoperability. Aiming for read-only first. We want to be able to put Islandora or Hydra on top of a PCDM Fedora and at least have it displayed. Being able to manage is a step for later. Hylandora Day (today!) has been alot of talk about data formats, hook derivatives.
43 | 7. Sandbox. Aaron, Danny, Nick, Jared, and Mark J had a wroking group to get an Islandora 7.x-2.x sandbox up and running. We had one for Camp but destroyed it afterwards because it was on Digital Ocean. UManitoba is sponsoring a year of hosting for a new one, which lives at future.islandora.ca. Built with vagrant witha DO provider tool. We have a snapshot so when/if it goes bad we can reload. Still needs a little work with users and security before we advertise it broadly - [related ticket](https://github.com/Islandora-Labs/islandora/issues/78). Aaron is going to use our snapshot for a presentation soon!
44 | 8. [Community Sprint](http://islandora.ca/content/7x-2x-sprint-001-planning). November 2 - 13. On the first day Danny and Nick will do an on-air Hangout (so there will be a recording) and go over the stack and how things work, then we can have a dicussion about the tickets we have and how best to use our two weeks. Most sprinters are in Eastern time, so we will start at 10 EST. Expect to learn as we go, spend a lot of this sprint getting people up to speed on the new stack - may not get any code written, and THAT IS FINE.
45 | 9. Danny: We don't HAVE to do this, if people don't want to. We could do this all in java - but, the best way to do this if we want to emulate the benefits of OSGi, we shoud use a PHP microframework. We'll still lose some stuff, but this is the closest we can get. We have options: Silex (sp?), Slim, Symfony, Falcon. Let's just pick one - as long as we agree, we can make any of them work. Jared: would like whichever one will get used - but also a way to continue to use Camel if possible. Danny: this is just for microsrvices - all of the async stuff will still be in Camel. It does not have to be a complete replacement. At the end of the day, we need whatever will get more people working on the stack. This may be a decision for after the first couple of sprints, when more folks are in a position to have an informed opinion.
46 |
47 | * Final thoughts from Diego: Get involved with PCDM. There is a mailing list, much discussion happening there and in GitHUb issues. The more Islandora people involved, the better.
48 |
--------------------------------------------------------------------------------
/meetings/01.md:
--------------------------------------------------------------------------------
1 | # Islandora Fedora 4 Interest Group: Meeting 01
2 |
3 | ## July 10, 2014 2:00-3:00 ADT
4 |
5 | ## Agenda
6 |
7 | 1. Introductions: Who are you and why did you join this group?
8 |
9 | 2. Fedora 4 features
10 |
11 | 1. What features of Fedora 4 are most interesting in the context of Islandora?
12 | 2. Are there any missing features that would impact integration?
13 | 3. Do you have any use cases you’d like to submit?
14 |
15 | 3. Islandora/Fedora 4 integration
16 |
17 | 1. What is the roadmap for integration?
18 | 2. Can we start with a minimum prototype?
19 | 3. What is the level of effort involved?
20 | 4. Who can contribute either developer time or money?
21 |
22 | 4. Next steps: How do we move this forward?
23 |
24 | ## Attendees
25 |
26 | * Andrew Woods (DuraSpace)
27 | * David Wilcox (DuraSpace)
28 | * Chad Nelson (LYRASIS)
29 | * David Evans
30 | * Jared Whiklo (University of Manitoba)
31 | * Ed Fugikawa (Colorado Alliance)
32 | * Ashok Modi (Cherry Hill Company)
33 | * Donald Moses (University of Prince Edward Island)
34 | * Nick Ruest (York University)
35 |
36 | ## Notes
37 |
38 | **Introductions**
39 |
40 | Andrew Woods
41 |
42 | * Fedora Technical Lead
43 | * Important that the concerns/sensibilities that Islandora has are represented in the process/development
44 | * Getting Islandora into the convo more prominently
45 |
46 | Chad Nelson (LYRASIS)
47 |
48 | * Working with Islandora (D7/F3)
49 | * Interested in Fedora 4
50 |
51 | David Evans
52 |
53 | * Has worked with Islandora, D6 and D7
54 | * Interested in F4 and D8
55 | * Has done some experimental work
56 |
57 | Donald Moses (UPEI)
58 |
59 | * Has downloaded and installed Fedora 4.0 Beta
60 | * Interested in new features like Linked Open Data support (e.g. RDF metadata)
61 |
62 | Jared Whiklo (University of Manitoba)
63 |
64 | * Tasked with learning how the backend of Fedora 4 works
65 | * Investigating a production ready way to run multiple systems
66 |
67 | Nick Ruest (York University)
68 |
69 | * Interested in Fedora4
70 | * Likes what Fedora4 brings to the table
71 |
72 | Ed Fugikawa (Colorado Alliance)
73 |
74 | * Multiple versions of Fedora running (2.x/3.x)
75 | * Would like to merge all of those into one version (Fedora 4.x)
76 |
77 | Ashok Modi (Cherry Hill)
78 |
79 | * Started with Fedora 3.6, upgraded to 3.7
80 | * Interested in F4
81 |
82 | David Wilcox (DuraSpace)
83 |
84 | * Straddles both communities (Islandora and Fedora)
85 | * Product Manager for Fedora
86 | * Sees a lot of potential in F4 for improving Islandora
87 | * It’s possible to represent F3 content in F4 (eg. mirror the modeling) but there is an opportunity to take advantage of the new features F4 provides
88 |
89 | **Ramping Up with Fedora 4**
90 |
91 | Fedora training/workshops/camps
92 |
93 | * Learn about Fedora4
94 | * Ashok:
95 | * “Interesting. Since a large chunk of the folks in here are in the Islandora/Fedora camp, would it make sense to have a combined camp of both (or one after the other within the same city/venue)?”
96 | * Posts to mailing lists re: training
97 |
98 | Pilot projects
99 |
100 | * Will need a few of those
101 | * Lots of different content models and data structures
102 | * More than one migration path
103 |
104 | Focus on Greenfield (new) installations initially
105 |
106 | * New content, not migrations
107 |
108 | What would a prototype look like?
109 |
110 | * What models?
111 | * Core Module
112 | * Collection Module
113 | * Tuque
114 |
115 | Discussion re: D7 and D8 implementation
116 |
117 | * A number of votes for D7 and F4 … we may miss the boat if we wait for D8
118 | * D.Evans thinks that D8 offers some advantages
119 | * D.Wilcox … thinks it makes sense to put some effort towards a D7/F4
120 |
121 | How to get that work done ?
122 |
123 | * How do we fund it
124 | * How do we get developers involved
125 | * Nick
126 | * Further discussion in Roadmap
127 | * Produce a [doc](https://docs.google.com/document/d/17Rl7qC5CRHfiMLQnRiMqdp5kR7kcL9ok-Bb9MJkwUgE/edit) to work through the details
128 | * Similar to F4 sprints
129 | * Organize sprint and community efforts/resources
130 | * Sprint planning
131 | * Use cases for the three items identified
132 | * Identify the benefits
133 | * Decouple dependency on discoverygarden for development
134 |
135 | Andrew
136 |
137 | * Discuss the F4 community effort
138 | * Collected use cases
139 | * Defined sprints and the priorities
140 |
141 | David W
142 |
143 | * Need buy in from developers, repository managers, and upper managers
144 | * Esp managers if we want to free up dev time
145 |
146 | Jared
147 |
148 | * Outline of tasks
149 | * eg. migrating tuque library
150 | * Learning by doing
151 |
152 | Chad
153 |
154 | * Identify the benefit each sprint
155 | * eg. new features not in F3, fixing an existing problem, etc.
156 | * Andrew would be interested in what those improvements might be.
157 |
158 | David W
159 |
160 | * Create project plan
161 | * Use cases and grievances/improvements/benefits
162 | * Scratchpad for brainstorming ideas
163 |
--------------------------------------------------------------------------------
/meetings/Denver - CO Fedora 4 Training Workshop - 16 Oct 2014.md:
--------------------------------------------------------------------------------
1 | # Denver, CO Fedora 4 Training Workshop - 16 Oct 2014
2 |
3 | ## Links
4 |
5 | * [Denver, CO Fedora 4 Training Workshop - 16 Oct 2014](https://wiki.duraspace.org/display/Events/Denver%2C+CO+Fedora+4+Training+Workshop+-+16+Oct+2014)
6 | * [Training - Administrator Introduction](https://wiki.duraspace.org/display/FF/Training+-+Administrator+Introduction)
7 |
8 | ## Notes
9 |
10 | ### Introduction and Feature Tour
11 |
12 | * Core Preservation Components
13 | * Fixity
14 | * basically same setup at 3.x
15 | * but it is only SHA1
16 | * the SHA1 determines where the object is on the disk
17 | * Backup and Restore
18 | * Export and Import
19 | * a specific Fedora object
20 | * exported objects are serialized (JCR xml)
21 | * an exported object or hierarchy of objects can be imported at anytime
22 | * Versioning
23 | * version can be created via API
24 | * previous versions can be restored via the API
25 | * Data Modeling
26 | * Resources
27 | * both objects and datastreams are represented as resources
28 | * object resources can have both objects and datastreams
29 | * tree structure allows for inheritance of things like security policies
30 | * Properties
31 | * resources have a number of properties (expressed as RDF triples)
32 | * properties can be RDF literals or URIs
33 | * any number of RDF namespaces can be defined and used
34 | * Content Models
35 | * content can be modeled using Compact Node Definitions (CNDs)
36 | * Mixins can be used to define any number of properties
37 | * objects can inherit properties from any number of mixins
38 | * Linked Data
39 | * F4 is compliant with the LDP 1.0 spec
40 | * metadata can be represented as RDF triples that point to objects outside the repository
41 | * External Components
42 | * Indexing
43 | * index repository content for external applications with the JMS Message Consumer
44 | * the consumer replays repository objects to one more external applications
45 | * repository content needs to be assigned the rdf:type property "indexible"
46 | * no GSearch
47 | * Role-based Authorization
48 | * Role-based authorization compares the user's role(s) with an Access Control List defined on a Fedora resource
49 | * ACLs can be inherited; if a given resource does not have an associated ACL, Fedora will examine parent resources until it finds one
50 | * XACML Authorization
51 | * a default policy must be defined for the repository, and each resource can override the default with another policy
52 | * a XACML policy reference by a resource will also apply to all the resource's children, unless they define their own xacml policies
53 | * Transactions
54 | * multiple actions can be bundled together into a single repository event
55 | * transactions offer performance benefits by cutting down on the number of times data is written to the repository filesystem (usually the slowest action)
56 | * Clustering
57 | * two or more fedora instances can be configured to work together in a cluster
58 | * fedora currently supports clustering for high-availability use cases
59 | * a load balance can be setup in front of two or more fedora instances to evenly distribute read requests across each instance
60 |
61 | ### Migrating From Fedora 3 to Fedora 4
62 |
63 | * XML Objects vs. Resources
64 | * Fedora 3
65 | * FOXML objects
66 | * Inline XML and XML datastreams
67 | * Fedora 4
68 | * Web resources (Objects & datastreams)
69 | * RDF properties
70 | * Flat vs. Hierarchy
71 | * Fedora 3
72 | * Objects and datastreams at the top level
73 | * no inheritance tree structure
74 | * Fedora 4
75 | * objects and datastreams in a hierarchy
76 | * all resources descend from a root node
77 | * File system
78 | * Fedora 3
79 | * objects directory and datastreams directory
80 | * both objects and datastreams are in a PairTree
81 | * Fedora 4
82 | * objects directory and datastreams directory
83 | * datastreams in a PairTree
84 | * objects in a database (e.g. LevelDB)
85 | * PID vs. Path
86 | * Fedora 3
87 | * object have a PID
88 | * PID can never be altered
89 | * Fedora 4
90 | * objects have an internal ModeShape UUID
91 | * objects have a repository path
92 | * this can user-defined or generated via a PID-minter
93 | * Ingest or Projection?
94 | * Fedora 4 supports projection over content in an external system
95 | * project over Fedora 3 REST-API is possible
96 | * Security
97 | * what kind of security does your Fedora 3 repository use?
98 | * many Fedora 3 repositories use XACML
99 | * Versions
100 | * does your Fedora 3 repository use versioning
101 | * Fedora 3 versions must be iterated through to create new version in Fedora 4
102 | * How should version dates be handled? Will you use the system modified date, or a special date property
103 | * Content Models
104 | * How are content models used in your Fedora 3 repository
105 | * Do they have any logic built into them, or is that handled at a higher application level? (Hydra/Islandora)
106 | * Disseminators
107 | * Does your Fedora 3 repository make use of disseminators?
108 | * What are they used for? XSL transforms? Derivatives?
109 | * How can we support the existing disseminator use cases in Fedora 4 without recreating disseminators?
110 | * Enhancements
111 | * Taking advantage of properties
112 | * lightweight and granular compared to XML
113 | * inline xml is no longer supported
114 | * converting inline xml and/or xml datastreams (RELS-EXT/RELS-INT) to RDF properties
115 | * Enhancing your metadata
116 | * XML metadata datastreams are still supported, but there are new opportunities to explore
117 | * XML metadata can be converted into RDF metadata using an RDF-based schema
118 | * RDF metadata is easier to query and share
119 | * take advantage of linked data by pointing to authority URIs
120 |
--------------------------------------------------------------------------------
/meetings/11.md:
--------------------------------------------------------------------------------
1 | # Islandora Fedora 4 Interest Group: Meeting 11
2 |
3 | ## September 25, 2015 1:00-2:00 EST
4 |
5 | Call details:
6 | * Call-in number - 866-994-3769
7 | * Participant Code - 3226955
8 | * IRC:
9 | * Join the #islandora chat room via [Freenode Web IRC](https://webchat.freenode.net/) (enter a unique nick)
10 | * Or point your IRC client to #isladora on irc.freenode.net
11 |
12 | ## Agenda
13 |
14 | 1. Introductions
15 | 2. [Hydra/Islandora Common Practices](https://docs.google.com/document/d/1BDrInNgg2aA6i6i4fi7zH6pK6HfsPamJgkce3pjRslg/edit#heading=h.uk7m472me211)
16 | * Hydra Connect
17 | * Islandora Camp CT
18 | 3. [Interest group report](https://docs.google.com/document/d/15TEYhj9HCyO6AR7_UobB2PzDIx0brr4C8x47seu1si0/edit#heading=h.o5x2g31mva0r)
19 | 4. Future of the projects
20 | * [Committers proposal](https://gist.github.com/ruebot/74ada12e0813319eec51)
21 | * Interest groups
22 | * DevOps
23 | * Metadata
24 | * UIIG
25 | * Documentation
26 | * Preservation
27 | * IR
28 | 5. Community sprints
29 | * November 2-14, 2015
30 | * Focus
31 | 6. Sandbox
32 | 7. Training/Study groups
33 | 8. Fedora API Extension architecture and overlap with current efforts
34 | 9. Call for input on another design iteration, including ^^
35 |
36 | ## Attendees
37 |
38 | * Nick Ruest (York University)
39 | * Danny Lamb (discoverygarden)
40 | * Melissa Anez (Islandora Foundation)
41 | * Aaron Coburn (Amherst College)
42 | * Diego Pino (REUNA)
43 | * Kelli Babcock (University of Toronto)
44 | * Andy Wagner (University of Toronto)
45 | * Rosie La Faive (UPEI)
46 | * Donald Moses (UPEI)
47 | * Mark Jordan (Simon Fraser University) :star:
48 | * Ed Fugikawa (University of Wyoming)
49 | * Ryan Townsed (discoverygarden)
50 | * Jared Whilko (University of Manitoba)
51 | * Lingling Jiang (UTSC)
52 |
53 | ## Notes
54 |
55 | (See also [irc log](http://irclogs.islandora.ca/2015-09-25.html) from 13:00-14:00)
56 |
57 | 1. Introductions
58 | 2. [Hydra/Islandora Common Practices](https://docs.google.com/document/d/1BDrInNgg2aA6i6i4fi7zH6pK6HfsPamJgkce3pjRslg/edit#heading=h.uk7m472me211)
59 | * Hydra Connect: Danny's report:
60 | * Ben Armintor showed how to migrate form F3 and F4; Danny had a TN listener running which worked.
61 | * PCDM: We now have a standardized (Hydra and Islndnora) way of locating non-RDF descriptive metadata in F4. Ex. dcterms.conformsTo a metadata namespace (inc. versions)
62 | * Work on read-only interoperabilty but have a while to go before we have read/write. We can read theirs objects but they can't read ours yet. Some discussion among the group about use cases for this interoperability: one F4, multiple heads; using Hydra for administrative tasks, something else for public access; shared bulk loading tools.
63 | * Revisiting how orderings are implemented to use hash URIs instead of proxies.
64 | * Rob Sanderson is creating a W3C working group for PCDM. Danny: "We're big kids now."
65 | * Islandora Camp CT on [Oct 23 a day on common/shared practices](http://islandora.ca/camps/ct2015/hylandoraday)
66 | 3. [Interest group report](https://docs.google.com/document/d/15TEYhj9HCyO6AR7_UobB2PzDIx0brr4C8x47seu1si0/edit#heading=h.o5x2g31mva0r)
67 | * Nick highligted the sustainability issue described at the end.
68 | * Kelli asked about a switchover date; Nick responded that the more resources we have to work on 7.x-2, the sooner we'll have a first version.
69 | * Danny added that community should drive the development, not only clients with money.
70 | 4. Future of the projects
71 | * [Committers proposal](https://gist.github.com/ruebot/74ada12e0813319eec51)
72 | * Interest groups
73 | * DevOps
74 | * Metadata
75 | * UIIG
76 | * Documentation
77 | * Preservation
78 | * IR
79 | * Mark asked about how formal the relationship between the F4 group and the various interest groups. Consensus was that we may not want to formalize the relationships but having reps from those groups in the F4 group and the development of 7.x-2 is extremely important.
80 | * Nick pointed out that for Islandora to move into the future, we need a Technical Lead. To hire one, the Islandora Foundation needs financial support. Please contact Melissa or Mark J. if you want some tips on advocating to your employer for financially supporting the Islandora Foundation.
81 | 5. Community sprints
82 | * First one to focus on 7.x-2.x is November 2-14, 2015
83 | * Focus
84 | * Danny reminds people to play with 7.x-2 so they can start providing feedback
85 | * Donald reported a potential issue in populating initial collections; Danny will follow up.
86 | * Lingling also reported a similar issue; Danny responded by asking her to open a ticket.
87 | * Maybe get some assistance from the Documentation IG and also do some work on documentation during the sprint.
88 | * Some possible ideas:
89 | * Rosie suggested developing some docs on using Camel.
90 | * Maybe a reasonable focus is to get more devs and other users comfortable with the vagrant, docuemntation, and use cases.
91 | 6. Sandbox
92 | * Sanbox was taken down after the conference because of the cost of running it. Nick, Jared, Aaron, and Danny are working on finding an alternative at a community site.
93 | * Nick and Dan Aitken working on a Jenkins server for the project: http://xi.library.yorku.ca/
94 | 7. Training/Study groups
95 | * Rosie and Donald have been setting aside a couple of hours on Fridays to concentrate on 7.x-2.x. "If we don't start somewhere, we won't get anywhere."
96 | * Aaron mentioned the weekly Fedora Tech call (https://wiki.duraspace.org/display/FF/2015+-+Tech+Meetings) that is open to everyone to hang out in.
97 | * Danny pointed out that the hardest part of learning F4 will be understanding how data is modeled in F4. *Learn [PCDM](https://github.com/duraspace/pcdm/wiki) and [LDP](https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-primer/ldp-primer.html).* ([This](http://hectorcorrea.com/#/blog/introduction-to-ldp/67) post by Hector Correa is also useful)
98 | 8. [Fedora API Extension architecture](https://wiki.duraspace.org/display/FF/Design+-+API+Extension+Architecture) and overlap with current efforts
99 | * Aaron explained it as affort to rethink monolithic repos like the current Islandora and Hydra as consumers of discrete services. Consistent with to current rearchitecting Islandora 7.x-2.x to use Camel.
100 | 9. Call for input on another 7.x-2.x design iteration
101 | * Danny suggested that now is a good time to refocus on the 7.x-2.x design. Community needs to get involved! "Let's make this software all that we want!"
102 | 10. Meeting adjourned at 2:00 EST.
103 |
--------------------------------------------------------------------------------
/meetings/10.md:
--------------------------------------------------------------------------------
1 | # Islandora Fedora 4 Interest Group: Meeting 10
2 |
3 | ## August 28, 2015 1:00-2:00 EST
4 |
5 | Call details:
6 | * Call-in number - 866-994-3769
7 | * Participant Code - 3226955
8 | * IRC:
9 | * Join the #islandora chat room via [Freenode Web IRC](https://webchat.freenode.net/) (enter a unique nick)
10 | * Or point your IRC client to #isladora on irc.freenode.net
11 |
12 | ## Agenda
13 |
14 | 1. Introductions
15 | 2. Islandora Conference
16 | 3. Future of the project
17 | * Roles
18 | * Danny & Nick
19 | * Committers
20 | * Interest groups
21 | * Community sprints
22 | * November 2-14, 2015
23 | 4. Sandbox
24 | 5. [Hydra/Islandora Common Practices](https://docs.google.com/document/d/1BDrInNgg2aA6i6i4fi7zH6pK6HfsPamJgkce3pjRslg/edit#heading=h.uk7m472me211)
25 | * Hydra Connect
26 | * Islandora Camp CT
27 | 6. Interest Group report
28 |
29 | ## Attendees
30 |
31 | * Nick Ruest (York University)
32 | * Danny Lamb (discoverygarden)
33 | * Melissa Anez (Islandora Foundation)
34 | * Andrew Woods (DuraSpace)
35 | * Jared Whiklo (University of Manitoba) :star:
36 | * Diego Pino (REUNA)
37 | * Rosie Lefaive (UPEI)
38 | * Mark Cooper (LYRASIS)
39 | * David Wilcox (DuraSpace)
40 |
41 | ## Notes
42 |
43 | ####1. Introductions
44 |
45 | - - -
46 | #### 2. Updates
47 | * Nick and Danny did another update at the Islandora conference, new things since OR 2015.
48 | * Also had a workshop at the Islandora conference, it was more of an in-depth dive into the stack.
49 | * Got it functioning enough to put on sandbox for the Islandora Conference
50 | * Danny needs more eyes on it, more review of code and also process. Does it do things the best way, is there another way. Now is the time to discuss.
51 | * York donated VM to get setup with Islandora 7.x-2.x sandbox
52 |
53 | - - -
54 | #### 3. Future of project
55 | * Initial phase started last Dec, got Danny till Islandora Conference
56 | * Foundation is ready for the community to step up.
57 | - Fedora 3 is end of life, so we need to start investing in the new stack.
58 | - First community sprint on the Islandora 7.x-2.x stack happens the first 2 weeks of November 2015.
59 | - Formalizing committers for the new stack using the Fedora model
60 | - https://wiki.duraspace.org/display/FF/Fedora+Committers
61 | - https://wiki.duraspace.org/display/FF/New+Committer+Processes
62 | - Good to have involvement from most if not all of the Interest Groups as committers.
63 | - Andrew: On the Fedora4 side we pushed it too far before formalizing the process. The Islandora community could can get informal agreement on the initial 3 committers (Nick, Danny & Jared). Then make it the initial committers job to expand the base after a set amount of time and by a set amount of committers.
64 | - Send out the list, informing about initial committers with be addressed at the Roadmap committee meeting (Sept 4). Make your voice heard if you don't agree.
65 | - Nick: Suggests to stop adding new features to the 7.x-1.x stack and move more effort to the new stack.
66 |
67 | Rosie : UI interest group's main focus was on the issues in the current stack, what would they do if we stop adding new features to 7.x-1.x
68 | - Adding use cases so the same mistakes made in old are not repeated.
69 | - Make UI not an after-thought, make active steps to provide a much better interface.
70 | - Drupal still has UI issues.
71 | - Discuss how future developments might appear (ie. headless interfaces).
72 |
73 | Mark : Technical lead or project manager was discussed at the Islandora conference. Has there been any movement regarding raising funding for this position?
74 | - At the AGM, there is a push to get funding for continuing the project from all the initial funders at the same funding level to help with the project as a whole and funding a technical lead/project manager.
75 |
76 | Danny : Get this work started so we don't get under the bus of a large project paid for by a single institution.
77 | - - -
78 | #### 4 - Sandbox
79 | - York has a VM ready to become a sandbox.
80 | - Comes down to Labour/time/resources
81 | - Simple sandbox, VM does not allow for templating.
82 |
83 | Andrew :
84 | - Fedora has a Jenkins server at U Maryland integrated with GitHub.
85 | - Commit to certain projects in GitHub, then Jenkins downloads HEAD from Github, builds it.
86 | - Deploys java modules to Maven repositories.
87 | - Builds core codebase and pushes the WAR to a VM at U of Texas.
88 |
89 | Check for anyone else that has a machine that could do templating. (vagrant/puppet/chef/ansible)
90 | - Jared to see if U of M has templating with it's VMs.
91 |
92 | - - -
93 | #### 5 - Hydra Connect
94 | Danny:
95 | - Going to HydraConnect
96 | - Small presentation on building services around Fedora.
97 | - Talk about PCDM and what we mean by Hydra/Islandora interoperability. Which probably leads to a solidifying of PCDM.
98 | - Hydra is already modeling with PCDM, so Islandora is a little behind. But PCDM is still in-process,
99 | - Ideally standardize the relationships can be consistent between both types of applications. Common object modelling.
100 |
101 | Andrew:
102 | - 2 very large communities that both leverage F4
103 | - Fedora is moving in a direction of making a very clear interface and API for higher-level apps.
104 | - Oppourtunity to consider what it would take to have an Islandora instance inter-changeable with a Hydra instance.
105 | - What would it take to make sense of the under-lying resources in Fedora.
106 | - Are there aspects of the API that are making this discussion more difficult, and could be reconsidered.
107 | - Similar use cases and similar concerns, let's talk about the fundamental aspects and how we could interact with Fedora in a similar way.
108 | - What features do we use / don't use. What are the commonalities and differences?
109 | - Continue over to the day at the end of the Islandora Camp CT.
110 | - Fedora is trying to use standards to ensure that you could swap other features in and not tie you to the Fedora product itself.
111 |
112 | - - -
113 | #### 6. Interest Groups reports
114 | - Board of Directorys would like reports from all the interest groups, reporting to start this fall.
115 | - Nick and Danny will be collecting information and will send out to the group to review.
116 |
117 | - - -
118 | #### Other Business
119 | - Islandora 7.x-2.x has been architectured to be scalable but hasn't been stress tested.
120 | - Goal is to push tasks/messages out to remote task queue, possibly anywhere.
121 | - Danny has played with Gearman and Celery.
122 | - Has anyone had any experience with any other products?? No responses.
123 |
124 | Next meeting September 25, 2015 @ 13:00 ET,
125 |
--------------------------------------------------------------------------------
/meetings/07.md:
--------------------------------------------------------------------------------
1 | # Islandora Fedora 4 Interest Group: Meeting 07
2 |
3 | ## May 22, 2015 1:00-2:00 EST
4 |
5 | Call details:
6 |
7 | Call-in number - 866-994-3769
8 | Participant Code - 3226955
9 |
10 | IRC:
11 | Join the #islandora chat room via Freenode Web IRC (enter a unique nick)
12 | Or point your IRC client to #isladora on irc.freenode.net
13 |
14 | ## Agenda
15 |
16 | 1. Introductions - recorded in the Attendance
17 |
18 | 2. [migration-utils](https://github.com/fcrepo4-labs/migration-utils)
19 | * [Portland Common Data Model](https://wiki.duraspace.org/display/FF/Portland+Common+Data+Model) ([repo](https://github.com/duraspace/pcdm))
20 | * Mike and Danny have been doing alot of work on this recently. A recent ticket took care of legacy systems and FOXML.
21 | * There is a [new table](https://github.com/fcrepo4-labs/migration-utils#property-mappings) with mappings. Some decisions have been made about how to map Fedora 3 properties that don't exist in Fedora4 (details in the table)
22 | * Undeclared namespaces will show up as ns001, ns002, etc. [This](https://jira.duraspace.org/browse/FCREPO-1553?jql=labels%20%3D%20fedora-3-to-4-migration) allows users to register useful namespace prefixes.
23 | * Andrew: are we encouraging folks to test these mappings or waiting until more mapping is done?
24 | * Nick: We are definitely encouraging people to test. If you are using the Islandora 7.x-2.x vagrant machine and install migration utils on it you can configure it to do some testing.
25 | * Andrew: If you want to run migration utils, there's a [PR going in today](https://github.com/fcrepo4-labs/migration-utils/pull/19) that will have it packaged as an executable .jar file.
26 | * [Hydra Metadata Working Group](https://wiki.duraspace.org/display/hydra/Hydra+Metadata+Working+Group)
27 | * Next steps: Working with Hydra and greater Fedora community on PCDM. Concentrate on mappings and modelling. Help is welcome! Please contact Nick. And get involved in the [Hydra Metadata Working Groups](https://wiki.duraspace.org/display/hydra/Hydra+Metadata+Working+Group) (it's just a name. All are welcome).
28 | * [Islandora Metadata Interest Group](https://github.com/Islandora/Islandora-Metadata-Interest-Group) is not quite related, but may touch on this is asked.
29 | * [migration modeling](https://github.com/Islandora-Labs/islandora/blob/7.x-2.x/docs/technical-documentation/migration.md)
30 | * [Islandora Ontology](https://github.com/Islandora-Labs/islandora_ontology)
31 | * Nick built up Islandora Ontology, mapping how things currently stand with Islandora 7.x and Fedora 3. There is one for [RELS-EXT](https://github.com/Islandora-Labs/islandora_ontology/blob/master/relsext.rdf) and [RELS-INT](https://github.com/Islandora-Labs/islandora_ontology/blob/master/relsint.rdf). Some are Solution Pack specific (Paged Content, Compound, Image Annotation), some are from XACML. We can use this to start the discussion on how these should carry over to Fedora 4 - leave them as legacy, map them, etc?
32 | * Robin: Should we record in the comments what SP each of these is used by? Where would be the best place to record why the field exists at all?
33 | * Nick: All of those things would be good in the RDFS comments
34 | * Robin: Should we documents things used by single SP's seperately? Image Annotation brings a lot of odd things to the table
35 | * Conclusion: As long as we're just documenting modules in the release, it's ok. We can ask community members to follow this template for documenting their own unique predicates. [Example from Islandora 7.x-2.x](https://github.com/Islandora-Labs/islandora/blob/7.x-2.x/docs/technical-documentation/islandora-namespace-predicates.md) and how it's been done so far.
36 | * Definitely should start adding comments for where these come from. Will ask on the list for opinions about how this should be included.
37 | 3. Drupal integration... GO DANNY! GO!
38 | * New features!
39 | * 7.x-2.x branch of Islandora Labs has a vagrant environment that will demonstrate all of this:
40 | * There is now an interface for field <-> RDF mapping for Drupal nodes.
41 | * Interface for namepsaces and prefixes
42 | * All from third party module: [RDFX](https://www.drupal.org/project/rdfx)
43 | * There is a proof of concept where you can create collections using the Drupal "Add Content" button (for the first time, EVER.). There are Islandora specific content types: Collection and Basic Image. Create with Drupal, end up with it in Fedora, with information send back from Fedora to the node (like hasPath and hasPredicate).
44 | * DC and MODS modules can be enabled to define ready made fields. Attach a MODS doc to a node, define the RDF mapping on that field, create the node and it will extract that MODs into Fedora.
45 | * You can work in RDF, you can work in XML, you can do a little of both- it all works, with a Drupal UI.
46 | * For now it only works at creation time, but edit is coming.
47 | * Once it works for editng and the full sync is working all the time, Danny will move on to Basic Image & others.
48 | * We are starting to need testers to find the bugs.
49 | * Mark: What about Solution Packs? How does Camel replace these?
50 | * Danny: We're not calling them SPs right now, but the content types are there. They will probably stil exist as packages for content types, viewers, etc. The middleware will provide service-per content-type to handle the objects. It will accept Drupal info and hand it over to the services middleware (with the caveat that not everything will live in Drupal, such as the high res OBJ datastream).Solution Pack functionality will get sliced up: Display in Drupal, creation/update in middelware, derivative creation elsewhere. Some may end up in sub-modules, which could then be shared by more than one "solution pack"
51 | * Drupal stuff may get seperated out into its own Git repo so that we can put it on Drupal.org.
52 | 4. [Islandora XML Forms use cases](https://docs.google.com/document/d/1zkyy40v4lz03rpjpmVHWujU9LQcxrsA4EC75D1d7X7A/edit)
53 | * We will have another meeting just for this, some time in mid to late June (after OR2015) to review, merge, and weight the use cases. Still collecting more in the meantime.
54 | 5. [Documentation](http://islandora-labs.github.io/islandora/)
55 | * Not much is new. Migration utils readme is the canonical mapping place for now.
56 | 6. [Audit Service](https://wiki.duraspace.org/display/FF/Audit+Service+Implementation+Proposal)
57 | 7. * Fedora 4.2 (just released) contains new audit service. Islandora community participation has helped to make sure this will suit our needs. It's half externalized, half stored within the repo.
58 | 7. [Issues](https://github.com/islandora-labs/islandora/issues)
59 | * Not much new here either.
60 | 8. [Install/DevOps](https://github.com/Islandora-Labs/islandora/tree/7.x-2.x/install)
61 | * New vagrant stuff went up recently.
62 | 9. [Use cases](https://github.com/Islandora/Islandora-Fedora4-Interest-Group/labels/use%20case)
63 |
64 | ## Attendees
65 |
66 | * Nick Ruest (York University)
67 | * Danny Lamb (discoverygarden)
68 | * Melissa Anez (Islandora Foundation)
69 | * Andy Wagner, University of Toronto
70 | * Chuck Schoppett, USDA
71 | * Mark Jordan, SFU
72 | * Robin Dean, Colorado Alliance
73 | * Andrew Woods, Duraspace
74 | * Kevin Clarke, UCLA
75 | * Jared Whiklo, University of Manitoba
76 |
77 | ## Notes - Inline in the agenda.
78 |
--------------------------------------------------------------------------------
/meetings/05.md:
--------------------------------------------------------------------------------
1 | # Islandora Fedora 4 Interest Group: Meeting 05
2 |
3 | ## March 27, 2015 1:00-2:00 EST
4 |
5 | Call details: Skype (add ruestn as a contact)
6 |
7 | Attending? Fill out [this](https://docs.google.com/forms/d/1CMMt2LkrEz9Sx0NLONvg0R_JRjeSQjruVnS_Uv26gjg/viewform) form.
8 |
9 | ## Agenda
10 |
11 | 1. Introductions
12 | 2. [migration-utils](https://github.com/fcrepo4-labs/migration-utils)
13 | 3. Data modeling
14 | * [Portland Common Data Model](https://wiki.duraspace.org/display/FF/Portland+Common+Data+Model) ([repo](https://github.com/duraspace/pcdm))
15 | * [Hydra Metadata Working Group](https://wiki.duraspace.org/display/hydra/Hydra+Metadata+Working+Group)
16 | * [migration modeling](https://github.com/Islandora-Labs/islandora/blob/7.x-2.x/docs/technical-documentation/migration.md)
17 | 4. [Audit Service](https://wiki.duraspace.org/display/FF/2015-02-20+-+Audit+Service+Planning+Meeting)
18 | 5. [Issues](https://github.com/islandora-labs/islandora/issues)
19 | 6. [Technical design](http://islandora-labs.github.io/islandora/technical-documentation/technical_design/)
20 | 7. [Documentation](http://islandora-labs.github.io/islandora/)
21 | 8. [Install/devops](https://github.com/Islandora-Labs/islandora/tree/7.x-2.x/install)
22 | 9. [Use cases](https://github.com/Islandora/Islandora-Fedora4-Interest-Group/labels/use%20case)
23 |
24 | ## Attendees
25 |
26 | * Nick Ruest (York University)
27 | * Danny Lamb (discoverygarden)
28 | * Melissa Anez (Islandora Foundation)
29 | * Andrew Woods
30 | * Andy Wagner
31 | * David Wilcox
32 | * Gavin Morris
33 | * Mark Cooper
34 | * Jared Whiklo :star:
35 | * Mark Jordan
36 | * Lingling Jiang
37 | * James Griffin
38 | * Rosie Le Faive
39 | * Donald Moses
40 | * Paul Pound
41 |
42 | ## Notes
43 |
44 | * migration-utils
45 | * Working on [fcrepo4-labs/migration-utils](https://github.com/fcrepo4-labs/migration-utils) with Apache Camel to make [camel based migration-utils](https://github.com/Islandora-labs/migration-utils/tree/camel-service)
46 | * This solves a future issue of batch ingesting for Islandora. Camel has handy XML processing tools. Also adding an ActiveMQ broker to maintain objects but not in-memory.
47 | * Trying to re-create relationships in Fedora 4 using old ones from RELS-EXT. Store Fedora 3 to Fedora 4 mapping in SQLite DB.
48 | * migration-utils to support (in this order):
49 | * traversing the objectStore filesystem
50 | * archive export format
51 | * migrate export format
52 | * Export format has size limit bug, will that be an issue? Traversing the filesystem uses the objectStore so does not have that issue and will probably be the primary channel of migration. Trying to use alternates (ActiveMQ) to not hold everything in memory as processing.
53 |
54 | * Data Modeling
55 | * Checkout [PDCM](https://wiki.duraspace.org/display/FF/Portland+Common+Data+Model) and get involved in the discussion.
56 | * Hydra Metadata Working Group - dealing with some of the same issues we will be dealing with in migrating data models.
57 | * Nick started [draft of large image](https://raw.githubusercontent.com/wiki/Islandora-Labs/islandora/images/Islandora-SP-Large-Image-Fedora4.jpg) data model in new PDCM.
58 | * Trying to resolve some property conversions. fedora:ownerId -> fedora:createdBy. However this is system-managed and is immutable. May need a second property to transfer the original Fedora 3 owner.
59 | * Draft data model does not use PCDM relationships in it.
60 | * Planned for 2-stage process, migrate content and then deal with the change to PCDM second. Unless we want to do it all now.
61 | * Question: Do we have to use hasParent for our models?
62 | * Not required, it is actually a system assigned property and is downward facing pcdm:hasMember.
63 | * Question: Isn't downward pointing references lead to more updates and a possible scalability issue?
64 | * This does cause more interactions, but is not necessarily a scalability issue.
65 | * Some of these relationships are system-managed and created automatically as PCDM is a combination of relationships
66 | * Should we define a prefix and get an ontology published?
67 | * Islandora is part of larger Fedora community, it would be nice to have a common set of predicates across the Fedora community. Send information to fedora-tech list to ask about commonalities that can be shared to avoid duplication of relations. (Nick todo)
68 | * Change fedora prefixed relations to pcdm relations. fedora:hasContent -> pcdm:hasFile
69 | * Need to create all PCDM relationships in our data models.
70 | * [draft datastream property mapping](https://github.com/Islandora-Labs/islandora/blob/7.x-2.x/docs/technical-documentation/migration.md#fcrepo3-datastream-properties-to-fcrepo4)
71 | * Format URI should have a standardize property to use.
72 | * Mapping Fedora 3 properties into Fedora 4 namespace properties can cause problems as they are system-managed and immutable. There are some ways to get around some properties, but not guaranteed.
73 | * What about *External* and *Redirect* datastreams?
74 | * Focus has been on Managed and Inline from Fedora 3, Fedora 4 does not differentiate.
75 | * Example redirect datastreams or edge-case examples to be shared to https://github.com/Islandora-Labs/upgration-test-fixtures.
76 | * Creating an external link in Fedora 4 ```curl -X PUT -H"Content-Type: message/external-body; access-type=URL; URL=\"http://www.example.com/file\"" "http://localhost:8080/rest/node/to/create"```
77 | * Side-effects of migration
78 | * No need for *islandora:root* object
79 | * In general not going to have default solution pack *content model* objects, can be a RDF property label.
80 | * Some people are using these to create inherited properties in new content-models. Perhaps set as an optional on install.
81 | * Discussion...
82 | * Does that assume there are no other objects in the repository that use the islandora:root.
83 | * Can islandora:root be a reference to a remote object?
84 | * Content-models act as useful examples of the content type.
85 | * Overloading the content models by creating inter-relationships between content models.
86 | * What about Collection Policy? Only DS-Composite(??) to restrict mime-types.
87 | * Mark will add this to [Islandora migration issue queue](https://github.com/Islandora-Labs/islandora/issues) to discuss.
88 | * Currently no way to do Content-Model validation at the Fedora layer. Stefano Cossu (Chicago Art Institute) has a use-case but no plans in place to add to Fedora.
89 | * What about a centrally managed ontology and content-models, instead of handling them in each repository.
90 | * Add unique content-types to [Upgration Test Fixture](https://github.com/Islandora-Labs/upgration-test-fixtures) repo.
91 | * Once default Islandora content is modelled, then worry about unique content.
92 | * Audit Service
93 | * Hydra/Fedora/Islandora/etc designed a plan for an [Audit Service](https://wiki.duraspace.org/display/FF/Design+-+Audit+Service). Sprint to start on March 30th. Esme Cowles to lead the sprint.
94 | * Danny : Triplestore was optional, but is now required for the Audit Service. So we need a [good triplestore](https://github.com/Islandora-Labs/islandora/issues/30).
95 | * Issue / Technical updates
96 | * Danny has some changes, to come soon.
97 | * Documentation - Not much
98 | * Install/devops - Not much
99 | * Use cases - Add them!
100 |
101 | Next meeting Friday April 24, 2015 @ 1pm Eastern.
102 |
--------------------------------------------------------------------------------
/meetings/03.md:
--------------------------------------------------------------------------------
1 | # Islandora Fedora 4 Interest Group: Meeting 02
2 |
3 | ## January 30, 2015 1:00-2:00 EST
4 |
5 | Call details: Skype (add ruestn as a contact)
6 |
7 | ## Agenda
8 |
9 | 1. Introductions
10 |
11 | 2. Updates
12 | * Overall updates (Nick/Danny/Melissa)
13 | * Technical overview (Danny)
14 | * [Upgration](https://wiki.duraspace.org/display/FF/Upgration+Pilot+-+York+University) (Nick)
15 |
16 | 3. Planning
17 | * Communication
18 | * Github issues
19 | * Volunteers
20 | * Sprints
21 |
22 | ## Attendees
23 |
24 | * Nick Ruest (York University)
25 | * Danny Lamb (discoverygarden)
26 | * Melissa Anez (Islandora Foundation)
27 | * Robin Dean (Colorado Alliance)
28 | * Ed Fugikawa (Colorado Alliance)
29 | * Mark Jordan (SFU)
30 | * Diego Pino (REUNA)
31 | * Lingling Jiang (UTSC)
32 | * Jared Whiklo (University of Manitoba)
33 | * Mark Cooper (LYRASIS)
34 | * Caleb Derven (University of Limerick)
35 | * Donald Moses (UPEI)
36 | * Alex Garnett (SFU)
37 | * Mike Durbin (UVA)
38 | * Aaron Coburn (Amherst)
39 | * Logan Cox (University of Oklahoma)
40 | * Gavin Morris (Common Media)
41 | * Andrew Woods (Duraspace)
42 | * David Wilcox (Duraspace)
43 | * Andy Wagner (University of Toronto)
44 | * Bryan Brown (FSU)
45 |
46 | ## Notes
47 |
48 | ### Introductions
49 | * Introductions and thanks to Diego for answering questions on the Islandora mailing list
50 |
51 | ### Updates from Nick (community/project)
52 | * Created the Islandora labs [Github org](https://github.com/islandora-labs/) repo with [proof-of-concept module](https://github.com/islandora-labs/islandora)
53 | * Learning from the past by starting with a nice devops environment: https://github.com/Islandora-Labs/islandora_chef
54 | * Nick and Danny are on the Fedora 4 tech calls every week and working with Fedora community
55 | * Every other week, there's a call with Fedora community members specifically about Fedora/Islandora integration (contact Nick if interested in participating)
56 |
57 | ### Updates from Danny (software/technical overview)
58 | * Rough draft of technical documentation: https://github.com/Islandora-Labs/islandora/blob/7.x-2.x/docs/technical_documentation.md
59 | * Camel app that consumes messages from Fedora 4 and converts them into appropriate JSON format for interacting with Fedora 4 (building on Aaron Coburn's fcrepo camel module, thanks Aaron!)
60 | * Working on defining separate layers of Islandora; focusing on the "middle layer" that has formerly been Drupal php modules
61 | * Benefits
62 | * Start using persistent queues, can allow for putting the middleware layer on separate servers
63 | * Current thinking: will not have tuque, xml forms, gsearch anymore because middleware layer will provide those functionalities
64 | * Treating Drupal like any other component of the stack; indexing in Drupal for display using nodes, fields, and other parts of the Drupal ecosystem
65 | * Trying to have many granular components rather than generic tools that try to do everything
66 | * Question about Drupal 8: are we making decisions now that will make it easier to move to the very different architecture in Drupal 8?
67 | * Answer: services module will help with this: https://www.drupal.org/project/services
68 | * Headless Drupal 7: is it possible to use this? Some would prefer to do it this way (+4 from group). Services in Drupal 7 seems to be pretty well supported and should do what we need it to do.
69 | * REST API endpoints could be the same in Drupal 7 and Drupal 8? Yes, trying to use standard endpoints.
70 | * Aaron was using a headless repository with tuque/ Drupal 7 but has moved on to a custom Hydra head for admin interface plus a backbone.
71 | * Focus right now is Fedora-Drupal connection, admin interface will happen later
72 | * Bulk upload/bulk ingest into Fedora is a big unknown right now
73 |
74 | ### Feedback & Questions
75 | * Diego currently using ontologies & Solr Cloud to sync repositories; will have to rethink everything if tuque goes away
76 | * Danny: would still be able to use PHP / Guzzle to interact with repos. Mapping how you interacted with F3 to F4 will be the bulk of the work, but if you're already relying on triplestores, that should make things easier. There will still be Solr and a triplestore in the stack.
77 | * Nick: need to have use cases to make sure we're keeping functionality that people need. Please add use cases to the issues queue in the Fedora 4 IG: https://github.com/Islandora/Islandora-Fedora4-Interest-Group/issues
78 | * Will also be good to look at Hydra use cases/methods. What should be in interfaces and what should be in the Fedora layer for both projects to share?
79 | * Mark: Is the triplestore going to be optional in Fedora 4? Required for collection hierarchy now.
80 | * Danny: Will need to map node IDs in Drupal to paths in Fedora for inter-object relationships.
81 | * Not sure how Drupal 7's built-in RDF functionality can help: only exports RDF, and can't import it
82 | * Andrew: Fedora code translates between how things are stored in infinispan/modeshape and what is exposed in the REST API, which is triples. Fedora 4 "looks like" a triplestore but is not really storing things as triples and doesn't have a SPARQL endpoint. Stores data as name-value pairs and translates to/from triples when needed.
83 |
84 | ### Upgration
85 | * What is upgration? A portmanteau of "upgrade" and "migration"
86 | * https://wiki.duraspace.org/display/FF/Fedora+3+to+4+Upgration
87 | * https://wiki.duraspace.org/display/FF/Upgration+Pilot+-+York+University
88 | * Have identified objects made from each solution pack as test cases for upgration
89 | * York UL Islandora keeps closely to core Islandora code (not highly customized) but doesn't include Scholar module
90 | * Fedora community talking about a migration utility that will go through FOXML and map datastreams to Fedora 4
91 | * https://wiki.duraspace.org/display/FF/Fedora+3+to+4+Data+Migration
92 | * Will need audit trail & audit functionality - possibly in March 2015 sprint
93 | * Discussions about archive vs migrate versions of FOXML
94 | * What about restricted objects/XACML? Can cause problems with migrations.
95 | * What are we going to do about content models? Not sure yet, will need community discussion.
96 |
97 | ### Original migration plan/proposal
98 | * https://docs.google.com/document/d/1C6JvuHEJok4FxnXsZoLNGAMGYCezY_Utz6SDht3CZdU/edit
99 | * Do we need a new, generic upgration page? Can we work from the 2 existing use cases? Use cases don't include Scholar or Newspaper at the moment; community is welcome to add to the use case issue queue in GitHub.
100 | * Have enough to start on the command line utility for migration, can adapt it to more use cases later.
101 | * Hydra use cases/content models? Penn State doing some pilot upgration work. Hydra emphasized RDF-based models in Fedora 3. Change is that RDF was being stored as a datastream in F3 and is stored as RDF properties on a node in F4, so it's a matter of translating the datastream to the properties.
102 | * Nick will work on taking a DS Composite datastream and mapping it to Fedora 4 model
103 |
104 | ### Communication
105 | * Meetings of this group will be announced on the Islandora mailing list.
106 | * This meeting will be a monthly meeting: every 4th Friday at 1 PM Eastern time.
107 | * Please volunteer for coding, testing, documentation if you can. Some institutions have pledged in-kind time; contact Nick so he can start to arrange sprints.
108 | * Parting thoughts from Diego: will this still be Islandora when we're done? Or do we need a new name? Something to gather input about in the future...
109 |
--------------------------------------------------------------------------------
/meetings/06.md:
--------------------------------------------------------------------------------
1 | # Islandora Fedora 4 Interest Group: Meeting 06
2 |
3 | ## April 24, 2015 1:00-2:00 EST
4 |
5 | Call details: Skype (add ruestn as a contact)
6 |
7 | Attending? Fill out [this](https://docs.google.com/forms/d/1gb07-US0hymvDAcTpIytAIiWruWXFu6j-64OT9Gozp4/viewform) form.
8 |
9 | ## Agenda
10 |
11 | 1. Introductions - recorded in the Attendance
12 | 2. [migration-utils](https://github.com/fcrepo4-labs/migration-utils)
13 | * [Portland Common Data Model](https://wiki.duraspace.org/display/FF/Portland+Common+Data+Model) ([repo](https://github.com/duraspace/pcdm)) - past month and a half has been focussed on this area, crossing over with Fedora sprints. Also doing modelling and mapping from Fedora 3 -> 4 to bring us into compliance with PCDM.
14 | * [Hydra Metadata Working Group](https://wiki.duraspace.org/display/hydra/Hydra+Metadata+Working+Group)
15 | * Not just Hydra! It's just a name. Good work being done here, broken into sub groups. Nick with technical, descriptive , and rights metatdata groups. Work is wrapping up in the next two weeks, where it can be pulled into out project.
16 | * [migration modeling](https://github.com/Islandora-Labs/islandora/blob/7.x-2.x/docs/technical-documentation/migration.md)
17 | * [auditTrail mapping](https://github.com/Islandora-Labs/islandora/blob/7.x-2.x/docs/technical-documentation/migration.md#audit-log-migration)
18 | * Feedback from Fedora tech list [here](https://github.com/Islandora-Labs/islandora/blob/7.x-2.x/docs/technical-documentation/migration.md#audit-log-migration)
19 | * Also looking to make sure we have all fedora 3 audit trails and that the mappings make sense.
20 | * [RELS-EXT Islandora namespace](https://github.com/Islandora-Labs/islandora/blob/7.x-2.x/docs/technical-documentation/isladnora-namespace-predicates.md)
21 | * [RELS-EXT Fedora namespace](https://github.com/Islandora-Labs/islandora/blob/7.x-2.x/docs/technical-documentation/fedora-namespace-predicates.md)
22 | * Predicates: had a valid use case in Fedora 3. What do they do for Fedora 4? `isMemberOf` and `isPageOf` in a Book, for example. How do they differ? Other predicates [here](https://github.com/Islandora-Labs/islandora/blob/7.x-2.x/docs/technical-documentation/fedora-namespace-predicates.md). Answer: we use these but we do not yet have a defined ontology. Nick is going to work on pulling together and publishing one in the near future, to go on islandora.ca. Right now they are just out there in the code and usage is based on how they have been used in the past. In Fedora 4 predicates like the examples may merge into "hasParent," simplifying matters. Further discussion on the details may wait for when we put together an ontology.
23 | * [Visualization](https://raw.githubusercontent.com/wiki/Islandora-Labs/islandora/images/Islandora-PCDM-Fedora4.jpg) of the PCDM and its structure. Made with [yEd](http://www.yworks.com/en/products/yfiles/yed/). And [here](https://raw.githubusercontent.com/wiki/Islandora-Labs/islandora/images/Islandora-SP-Large-Image-Fedora4.jpg) it is exploded.
24 | * There's an idea to take the DC datastream and apply it as properties to the object. There would be no explicit DC datastream on the object. OR - if the community wants to keep it, it could be an LDP/RDF source in plain xml on the PCDM object.
25 | 3. [Documentation](http://islandora-labs.github.io/islandora/)
26 | * [Services](https://github.com/Islandora-Labs/islandora/blob/7.x-2.x/docs/technical-documentation/services.md)
27 | * Danny's proposal for how services should work. Not an exhaustive list, because Islandora is meant to be a plugable framework. Instead, this defines the interface for how these plugable bits can be built. Everything is keyed by the Drupal ID, which can collide if you have a multisite (thanks for catching this, Paul Pound!), so it will be changed to UUID.
28 | * Currently creating CRUD operations for PCDM object types. Following conventions as much as possible. File services make things a little hazy. In Fedora 3 we'd have DSID. Services will be boxed by DSID.
29 | * Next task is to make this happen in Camel.
30 | * Derivative services comes next. Making this RESTful is taking some creativity, but it's coming along. Patch will be used to regenerate - Danny is open to suggestions if there's a better way.
31 | * Asynchronousity for the win.
32 | * It will be up to the implementation whether derivatives are stored in Fedora or not. This still needs some debate. Danny proposes that anything subject to regeneration should not be in Fedora. Maybe we just make it configurable.
33 | * Zip ingest is going to be a core function. Other techniques available for files that exceed zip limits.
34 | * Standardizing on a manifest file format and sticking with it would be great. Perhaps holey bags.
35 | * For Fedora 4: the default assumption should no longer be "everything on the same server." Horizontal scaling comes out of the box.
36 | 4. [Audit Service](https://wiki.duraspace.org/display/FF/2015-02-20+-+Audit+Service+Planning+Meeting)
37 | * [Audit Service Implementation Proposal](https://wiki.duraspace.org/display/FF/Audit+Service+Implementation+Proposal)
38 | * [Using Audit Events Phase 1](https://wiki.duraspace.org/display/FF/Using+Audit+Events+Phase+1)
39 | * Fedora Sprints: first phase is over. Testing went smoothly for initial implementation of audit service; standalone triplestore. One of our requirements for migration. We will use PREMIS migration vocabulary to store audit trails.
40 | * Timeline: next ticket to go in is implementation of audit trail mappings. A few weeks off.
41 | 5. [Issues](https://github.com/islandora-labs/islandora/issues)
42 | * [Investigate the Xpath Field module](https://github.com/Islandora-Labs/islandora/issues/27)
43 | * From Alex O'Neil, Islandora Developer of Yore. [Our fork](https://github.com/islandora-labs/xpath_field)
44 | * Danny and Jared have created Drupal Content type for Basic Image that we are experimenting with.
45 | * Form Builder may have to carry over. We don't have the resources for this right now, but someone is going to have to take this on. This should be a community effort - if the community wants it, we have to come together to gather the resources for it to happen.
46 | * [Investigate XML editors to replace XML Forms](https://github.com/Islandora-Labs/islandora/issues/28)
47 | * [Create Drupal Content Type for Basic Image](https://github.com/Islandora-Labs/islandora/issues/26)
48 | * [Performance testing triplestores for Islandora community recommendations](https://github.com/Islandora-Labs/islandora/issues/30)
49 | * Mulgrara has burned us a little. We would like to recommend something robust in the future. Diego Pino has put together potential benchmarks. A lot of crossover with Fedora community in general, also DPLA.
50 | * The role of the triplestore in the stack: things are indexed in Drupal, so no triplestore to view things. Middleware/syncservices will require a triplestore to line things up
51 | 6. [Install/DevOps](https://github.com/Islandora-Labs/islandora/tree/7.x-2.x/install)
52 | * PHP Code Sniffer has been added
53 | * Fuseki 2.0.0 has also been added. Deployable war, so it can go in Tomcat.
54 | 7. [Use cases](https://github.com/Islandora/Islandora-Fedora4-Interest-Group/labels/use%20case)
55 | * Check them out, add yours (there's a template!), bug Nick if you need help.
56 |
57 | ## Attendees
58 |
59 | * Nick Ruest (York University)
60 | * Danny Lamb (discoverygarden)
61 | * Melissa Anez (Islandora Foundation) :star:
62 | * Mark Jordan (SFU)
63 | * Lingling Jiang (USTC)
64 | * Gavin Morris (Common Media)
65 | * Kelli Babcock (UofT)
66 | * Jared Whiklo (University of Manitoba)
67 | * Martin Dow (Acuity Unlimited)
68 | * Mark Cooper (LYRASIS)
69 | * Chuck Schoppet (USDA)
70 |
71 | ## Notes
72 |
73 | In-line.
74 |
--------------------------------------------------------------------------------
/meetings/09.md:
--------------------------------------------------------------------------------
1 | # Islandora Fedora 4 Interest Group: Meeting 09
2 |
3 | ## July 30, 2015 1:00-2:00 EST
4 |
5 | Call details:
6 | * Call-in number - 866-994-3769
7 | * Participant Code - 3226955
8 | * IRC:
9 | * Join the #islandora chat room via Freenode Web IRC (enter a unique nick)
10 | * Or point your IRC client to #isladora on irc.freenode.net
11 |
12 | ## Agenda
13 |
14 | 1. Introductions
15 | 2. Stack updates
16 | * OSGi
17 | * Vagrant
18 | * Moving forward
19 | 3. Metadata Interest Group collaboration
20 | * [Fedora4 Metadata Subgroup](https://github.com/Islandora/Islandora-Metadata-Interest-Group/wiki/Fedora4-Metadata-Subgroup)
21 | * [Islandora XML Forms use cases](https://github.com/Islandora/Islandora-Metadata-Interest-Group/issues/13)
22 | 4. Islandora Conference
23 | * Islandora & Fedora 4 presenation
24 | * Islandora & Fedora 4 workshop
25 |
26 | ## Attendees
27 |
28 | * Nick Ruest (York University)
29 | * Danny Lamb (discoverygarden)
30 | * Melissa Anez (Islandora Foundation)
31 | * Christina Harlow (University of Tennessee Knoxville) :star:
32 | * Andrew Woods -- regrets, on holiday
33 | * David Wilcox (DuraSpace)
34 | * Andy Wagner (University of Toronto)
35 | * Martin Dow (Acuity Unlimited)
36 | * Lingling Jiang (UTSC)
37 |
38 | ## Notes
39 |
40 | ### Introductions
41 |
42 | ### Stack updates
43 |
44 | - **OSGi**
45 | - Danny: As it stands, since last meeting, completely rewritten stack in order to take advantage of OSGi
46 | - OSGi container is now there, using karaf - but there is nothing stopping you from using something else
47 | - The services are now adopting micro-services style architecture, meaning they are all independent of one another, and that you can restart single parts without needing to restart the whole stack
48 | - It can be set up to monitor maiden so things automatically redeploy on updates
49 | - This all goes towards modularity we’re trying to achieve, and camel realm has same modularity we’re trying to have
50 | - A lot of php added, and a component that can be use to call component scripts, all using command line / modern php
51 | - This means that basically you can do everything with xml deployed in usage container using php now, so there is no real need for java
52 | - **Vagrant**
53 | - all this stuff will now work with vagrant, so you can deploy it with all this described
54 | - **Moving forward**
55 | - All of this extra functionality needs to be shown off at Islandora conference
56 | - So instead of Danny making tickets for every one else, he has been scrambling to do a lot of the work himself and then the tickets issued will be for clean up/tweaking.
57 | - There is a lot of stuff hardcoded so we can push into config in drupal forms
58 | - There remains a lot of small stuff to do, and Danny is hoping to get community involvement on these
59 | - When done, there will be a functional image solution pack, and then other folks can take on others solution packs
60 | - **Questions**
61 | - *Question*: Are you are writing documentation, and will that be for developers?
62 | - Yes, but all of the documentation work was hijacked by the mandate for new functionality. But yes, the documentation is geared to developers, and covers topics such as how to use vagrant environment, where things are, how to monitor stuff in OSGi, the architecture, etc. No end-user documentation yet.
63 | - *Question follow-up:* Where will this documentation live?
64 | - In repository, docs folder, in couple categories. MK Docs
65 | - Or you can see live when pushed to github pages, pushed occasionally: http://islandora-labs.github.io/islandora/
66 | - *Question follow-up:* A lot of the documentation on the wiki, other places, seems not to reflect the current work.
67 | - Danny/Nick: We’re not there yet, but trying to get there. A lot of the documentation out there was written when things were at a high-level, now they have a lot of details to report on and expand upon.
68 | - If you are thinking of things you specifically want to see in documentation, it would be helpful to put into Github issues/tickets so they can follow up on them.
69 |
70 | ### Metadata Interest Group collaboration
71 |
72 | - **Fedora4 Metadata Subgroup**
73 | - We are looking for ways to encourage/support collaboration between the Fedora4 IG and the Metadata Fedora4 subgroup
74 | - Possible areas: MODS/RDF, Collaborating with Hydra Metadata Group and subgroups, potentially work on Islandora XML Forms
75 | - **Islandora XML Forms use cases**
76 | - A couple of months ago, the Fedora 4 group went on a bit of a side path discussing the future of XML forms, and how to handle these in Islandora 7.x-2.x:
77 | - Summary: do we port what exists now? do we kill and create something new? Or make a hybrid thing?
78 | - We attempted to start gathering use cases and users stories
79 | - Link to issue re:use cases moved to metadata group: https://github.com/islandora-interest-groups/Islandora-Metadata-Interest-Group/issues/13
80 | - **Subgroups formation**
81 | - Discussion of RDF properties, PCDM, descriptive metadata expansion:
82 | - For handling MODS/RDF or other descriptive metadata as RDF, a question is can we generate things on fly or do we keep it as a file on filesystem that we preserve.
83 | - Now that standard metadata is MODS/XML, we will need to have support for handling MODS as XML or RDF.
84 | - One area the metadata group can help: identifying core set of RDF properties that you’d want on the PCDM object, exposed for further use/discoverability/other.
85 | - *Question:* What does this mean for end user looking to load descriptive metadata XML file, and how that is handled?
86 | - You could create all either rdf entries as fields in a form, or provide them as xml and use xpath fields to transform to RDF. Basically, you should be able to tell drupal how to pull out bits you want to get converted to RDF. So you will need to add configuration on your drupal node type to set up this for the metadata, whichever option you go.
87 | - The Islandora Fedora4 metadata subgroup then should be responsible for survey/use cases related to above discussed points, and the XML form uses cases should move over to metadata group as the Islandora Fedora4 metadata group is becoming a subgroup of both Fedora4 and Metadata IGs (members of the subgroup are in both groups).
88 | - **Hydra MODS/RDF group:** https://wiki.duraspace.org/display/hydra/MODS+and+RDF+Descriptive+Metadata+Subgroup
89 | - By the end of the year, the group hopes to create recommendations of what mappings are possible for MODS elements
90 | - Last meeting was spent primarily going over of focus/scope of group
91 | - The homework was to review the MODS:title element, provide use cases, possible mappings: https://wiki.duraspace.org/display/hydra/MODS+Title+Individual+Institution+Usage+And+RDF+Conversion
92 | - Notes from last meeting: https://wiki.duraspace.org/display/hydra/MODS+and+RDF+Call+2015-07-27
93 | - *Question:* Is there interest in helping with other Hydra groups?
94 | - Nick co chaired technical metadata subgroup, which wrapped up just before Open Repositories.
95 | - Nick also was in rights metadata subgroup, which just wrapped up. Recommendations are on the Hydra wiki site: https://wiki.duraspace.org/display/hydra/Rights+Metadata+Recommendation
96 | - The plan is to implement some of these recommendations that coincide with webACL stuff in fedora.
97 | - So, when webacl happens, if you have repo with webacl and is compliant, you should be able to put islandora over top and read.
98 |
99 | ###Islandora Conference
100 |
101 | - **Islandora & Fedora 4 presenation**
102 | - Danny and Nick are giving an updated version of their Open Repositories presentation.
103 | - The updates will be everything that has happened since OR
104 | - **Islandora & Fedora 4 workshop**
105 | - 1.5 hour workshop - more in depth to technical side of things than as presented in the presentation, depending on time.
106 | - Game plan: do a crash course into contributing to the project, so take a newbie ticket or two and work through that ticket together, solve, and walk through contribution whole process.
107 | - if they need to create any new tickets to document the process, they’ll do that as well.
108 | - Danny: a lot of the time will be showing the new functionalities and stepping people through that, then time left over will be for working through a ticket.
109 | - **Questions:**
110 | - Will workshop be recorded?
111 | - Don’t believe it will be recorded, no.
112 | - Then is possible to produce a recorded session for what will be discussed in the conference workshop?
113 | - The documentation that exists right now:
114 | - There is a section on contributing to the project
115 | - There is some documentation called "hacking on islandora", produced by danny, which is very helpful.
116 | - It is all slowly getting flushed out.
117 | - If you want to see things get better, or get more from project, let danny and nick know what you want via issue tickets, as well as put some time and energy into it. We need more people involved.
118 |
119 | Next meeting: month or so from now, notice to mailing list
120 |
--------------------------------------------------------------------------------
/meetings/04.md:
--------------------------------------------------------------------------------
1 | # Islandora Fedora 4 Interest Group: Meeting 04
2 |
3 | ## February 27, 2015 1:00-2:00 EST
4 |
5 | Call details: Skype (add ruestn as a contact)
6 |
7 | ## Agenda
8 |
9 | 1. Introductions
10 |
11 | 2. Updates
12 | * Code4Lib
13 | * [Fedora Community Data Model](https://wiki.duraspace.org/display/FF/Fedora+Community+Data+Model)
14 | * [Islandora and Fedora 4 proof of concept](https://www.youtube.com/watch?v=j6Yw5c4XZp4)
15 | * [Technical design](http://islandora-labs.github.io/islandora/technical-documentation/technical_design/)
16 | * [Documentation](http://islandora-labs.github.io/islandora/)
17 | * Install/devops
18 | * [Audit Service](https://wiki.duraspace.org/display/FF/2015-02-20+-+Audit+Service+Planning+Meeting)
19 | * Upgration
20 | * Use cases
21 | * [Template](https://github.com/Islandora/Islandora-Fedora4-Interest-Group/wiki/Use-Case-template)
22 | * [Use cases](https://github.com/Islandora/Islandora-Fedora4-Interest-Group/labels/use%20case)
23 |
24 | ## Attendees
25 |
26 | * Nick Ruest (York University)
27 | * Danny Lamb (discoverygarden)
28 | * Melissa Anez (Islandora Foundation)
29 | * Kirsta Stapelfeldt (UTSC ) :star:
30 | * Andy Wagner (University of Toronto)
31 | * Aaron Coburn (Amherst)
32 | * Kevin Clarke (UCLA)
33 | * Gavin Morris (Common Media)
34 | * Mark Cooper (Lyrasis)
35 | * David Wilcox (Product Manager for Fedora with Duraspace)
36 | * Martin (Acuity)
37 | * Alex Garnett (SFU)
38 | * Diego Pino (REUNA)
39 | * Jared Whiklo (Univeristy of Manitoba)
40 | * Lingling Jiang (UTSC)
41 | * Mark Cooper (LYRASIS)
42 | * Logan Cox (University of Oklahoma)
43 |
44 | ## Notes
45 |
46 | 1. Introductions
47 |
48 | 2. Updates
49 | * Code4Lib - oppourtunity for face to face work. Tremendous progress:
50 | * [Fedora Community Data Model](https://wiki.duraspace.org/display/FF/Fedora+Community+Data+Model)<--emerging shared data model in Fedora. Andrew Woods gathered Code4Lib attendees for a working lunch. Nick documented main data models for Islandora. Good news is that there is a good overlap with the Hydra work. This document now refers to a shared Fedora data model to be used by Hydra and Islandora. Most like the Compound data model says Nick, but simple objects can still be built, says David. Merge the whole paged content and compound concepts into one with different ways of ordering "children" and the use of "proxy" for recording multiple orderings. Three different types of objects (containers) one is a generic collection, a generic "container," and a generic "file." "Container" nomenclature is still up in the air. Read the document for additional details, and the conversation remains quite active, so all are invited to wiki page or Andrew Woods thread. The emerging model would cover Islandora use cases.
51 | * [Islandora and Fedora 4 proof of concept](https://www.youtube.com/watch?v=j6Yw5c4XZp4) <-- Danny got together the proof of concept and gave brief presenatation. See Youtube video. Drupal/Fedora 4 and middleware running. If you go and start making objects or "containers" in Fedora it will start creating Drupal nodes and put Fedora RDF as the node article text. Just a proof of concept to show that we can listen to Fedora's messages and consume them/do meaningful things in Drupal. Hinges on Drupal services module. JSON message constructed from Fedora message and posted to Drupal. Lots left to do for security, and indexing to Solr and Triplestore. Chef was a problem at Code4lib, so a bunch of bash scripts were written and tied together with Vagrant. See http://islandora-labs.github.io/islandora/install/README/. Can install demo in about 10 minutes from this repo. If people want to develop they can come develop, can show to bosses, etc. The idea is that everybody can use bash scripts in whatever approach they choose, so not tied to chef, ansible, or anything else. If you want to contribute to this project, you do not have to follow LSAP at this stage. All contributions welcome! Getting to the point where steps can be outlined and distributed to those helping with the project. Bash scripts likely to be broken down a little further. Eventually it would be great to make modular enough so that we one can set up distributed installation a lot more easily.
52 | * [Technical design](http://islandora-labs.github.io/islandora/technical-documentation/technical_design/)
53 | * Danny put together this document. Danny has updated document since last meeting. Additional topics have been added. "The Plan" has been fleshed out as well as the use of Camel (Apache Camel component). Scripting language part is likely to evolve for more freedom of choice. A lot more to do on the Drupal end of things. Lots of other modules implicated, including Drupal relationships. More documentation will be written about the use of services. Piece of middleware doing two things - (consuming Fedoraqueue messages and doing things with them).[See this gif](https://raw.githubusercontent.com/wiki/Islandora-Labs/islandora/images/layer-interaction.gif) <-- should be much more robust use of Drupal's native features and functions. For each complex action (performing a sequence of operations) the middleware will expose a new service. There will be issues with messaging (ordering and timing) but hopefully this will give us much better performance, and won't be 'bothering' Fedora as much. Lots more traffic for Drupal. Review next week for a lot more documentation. There is a question about scalability in Drupal, but much will depend upon how Drupal is tuned (postgres tuning and caching). There will be a lot of sysadmin work involved. But you can scale and cluster Drupal, just like you can scale and cluster Fedora. It will be a challenge, but is very doable. Solr approach is still up for grabs, but project is very open to leveraging existing Drupal solutions, such as Apache Solr if it works. The proposed solution for replacing XML forms will play heavily into what approach is followed. What do we do with our descriptive and technical metadata streams? XML standard will be persisted in the repository. Review XML field in Drupal and xpath module. Discussion of MODSRDF (including issue of blank nodes). Think carefully, warns Aaron, before jumping into MODS RDF, especially when you need to continue to produce XML. More strict RDF route can be mapped to field in Drupal. Need a good solution for everybody, not just push people toward RDF.
54 | * [Documentation](http://islandora-labs.github.io/islandora/)
55 | * One of the goals has been to keep things in a single repository. Everything lives [here](https://github.com/islandora-labs/islandora). There is a folder called documentation, and Nick is using a Python program (mkdocs) wich has yaml file to outline documentation structure. Two commands will generate Git Pages based on up to date documentation. [See also](http://islandora-labs.github.io/islandora/technical-documentation/docs-build/). Information for how to contribute to the project is [provided on Github as well](http://islandora-labs.github.io/islandora/contributing/contributing/). Please contribute and comment on this documentation.
56 | * [Audit Service](https://wiki.duraspace.org/display/FF/2015-02-20+-+Audit+Service+Planning+Meeting)
57 | * Met on the audit services at Code4lib and had a call last week for use cases and proposals for the Audit service. There are lots of todos to ouline the differences between approaches. [Meeting notes from the Audit Services Meeting](https://wiki.duraspace.org/display/FF/2015-02-20+-+Audit+Service+Planning+Meeting) These meetings are outlining use cases will inform functional requirements and tickets that will be taken care of at the end of March. David notes that there are two code sprints beginning end March. They need a total of 3 developers on each sprint, and have 2 developers currently for each one. Four action items have been assigned. Once the actions are finished and unanswered questions are answered, functional requirements can be finalized. Meeting happening last week. Here is the [Doodle poll](http://doodle.com/52b5dwtxmztehadf). Here is also the [plan being developed for Audit service](https://wiki.duraspace.org/display/FF/Design+-+Audit+Service)
58 | * Upgration
59 | * [Migration Approaches are being designed](https://github.com/fcrepo4-labs/migration-utils). Mike and Danny working together on a migration approach.
60 | * [Here are the Github issues for the project around this so far](https://github.com/Islandora-Labs/islandora/labels/upgration)
61 | * Camel in combination with FOXML crawl. Mike has dealt with a lot of the challenges for Fedora 3 and now it is poised to become a service in the stack. A fair bit is in solid enough footing that we can continue - some things will change in the community content model and will require some refactoring, but we can get most of the way there with this start.
62 | * Danny is open to helping others who are getting up to speed with some components. Beginning next week! Lots of progress.
63 | * Migration likely happen to happen in phases, recursively 1. create collections; 2. create simple objects; 3. develop compounds. PIDs will likely be mapped in a table so that it can be recorded for new object. Datastream label still be developed. Mapping also needs to exist between path in Fedora 4 and NID.
64 | * Use Cases
65 | * [Template](https://github.com/Islandora/Islandora-Fedora4-Interest-Group/wiki/Use-Case-template)
66 | * Please add use cases based on this template
67 | * Islandora folk encouraged to get engaged with Fedora 4 community's discussion, but no perceived blockers or red flags in the Fedora development. It would be especially good to hear from more librarians in the Islandora community.
68 | * [Use cases](https://github.com/Islandora/Islandora-Fedora4-Interest-Group/labels/use%20case)
69 |
70 | Next Meeting March 27th at 1:00 EST. Nick will put out call for attendees the week before, but let him know as soon as possible in case we need to revise meeting method (get booted from Skype)
71 |
72 |
--------------------------------------------------------------------------------