-
Notifications
You must be signed in to change notification settings - Fork 71
November 25, 2015
This meeting is a hybrid teleconference and IRC chat. Anyone is welcome to join. Here is the info:
- Time: 1:00pm Eastern Daylight Time US (UTC-4)
- Dial-in Number: (641) 715-3570
- Participant Code: 304589#
- International numbers: Conference Call Information
- Web Access: https://www.freeconferencecallhd.com/wp-content/themes/responsive/flashphone/flash-phone.php
- IRC:
- Join the #islandora chat room via Freenode Web IRC (enter a unique nick)
- Or point your IRC client to #islandora on irc.freenode.net
- Daniel Lamb
- Jared Whiklo
- Nigel Banks
- Donald Moses
- Lingling Jiang
- Diego Pino ⭐
- December sprint planning
- Sprint topic (at the bottom of the article)
- Need to create tickets and assign them to CLAW milestone and Chullo milestone
- Merge 7.x-2.x-dev into 7.x-2.x
- Discuss: rdf namespaces and properties: dc, dcterms, schema.org and DPLA alignment
- Drupal 8
- Who's the master?
- Fedora as a warehouse?
- Drupal that just flushes to Fedora?
The next sprint will, December 7th - 18th will have focus on planning and developing PHP Services for our current Apache Camel Workflow and Drupal interaction. This also means API design. We will have to create/assign tickets/issues to CLAW milestone and Chullo milestone. Idea is to move/port some of the current other languages functionality plus new ones to php.
Daniel: basically what needs to be done is define features, starting with the obvious ones. Will open a github issue to open/keep this discussion and we will probably have a pre-sprint planning meeting.
Jared did a massive pull (great Jared!) to bring latest 2.x-dev branch changes to 7.x-2.x branch. This involved rebasing and manual fixes. This also means the end for 7.x-2.x-dev branch because it's too difficult to maintain.
Dani: asked if everyone is OK with assuming that 7.x-2.x is master, but an unstable one. Will probably have our own release branches in the future. Everyone was OK!
Discussion around why keep old history in Islandora-CLAW (7.x-1.x and previous branches), pros and cons since it's also a fork of Islandora.
Nigel: In favour of keeping everything in the same place. Makes working on both, 1.x and 2.x more centralised.
Jared: Not sure, makes forking complicated, if you already have forked github.com/islandora/islandora, but OK with continuing like this if others agree.
Conclusion: no changes in the current Islandora-CLAW repository structure.
3. Discuss: rdf namespaces and properties: dc, dcterms, schema.org and DPLA alignment #108
Discussion comes from previous meeting:
Diego: the idea is to open a discussion on what RDF properties/ ontologies should be considered base ones for Islandora resources, and which should and could be handled as part of our new notion of content models. Current Islandora-CLAW drupal architecture uses Nodes and fields for properties. Idea is to move the most important ones to Custom Entities properties and make somehow other properties bundled and configurable. PCDM is our main consensus ontology but to be able to talk to external consumers (like DPLA) it could be good to enable a easy aggregation of other rdf:types
and their properties.
Dani: explained we already had a similar ontologies talk during the Islandora Conference 2015 at UPEI and the idea was interesting.
Diego: Has already a Ontologies import/use functionality working in Islandora 7.x-1.x. The proposal is to work on a way users (Admins) can import Ontologies into the system, they get parsed and exposed to entities
-> bundles
-> fields
-> assigned to Islandora objects/resources. This new rdf:type
types can then be assigned by the "ingester". This way we can manage multiple parallel types (PCDM
+ other domain specifics). This also makes our programming more flexible in the sense that we not longer need to define in code what a specific resource type is, it's controlled by a real Ontology.
Nigel: asked about implementation cons/pros and assert that
composition of types will make programming easier in the long run, as we can make certian assumptions based on each type.
Daniel: asked for Donald's opinion on metadata preferences and concerns.
Donald: also asked about implementation details and how this ontologies could be used.
Diego: answered that using a workflow similar to: import Ontology, parse, choose which properties the user wants to enable, assign the rdf:type
to a new resource (using Entities
and bundles
). This also means we can have multiple types that semantically enrich our resources and keep a layer of compatibility with Hydra using PCDM
.
Nigel and Diego: talked about possible duplication of same meaning properties from different Ontologies, how to mitigate and also a way to map multiple same type and meaning ones to a single input field.
Dani: suggested Diego should open an issue and should work on this as a way to make Content Models/RDF type definition in Islandora 7.x-2.x possible.
Diego: agreed, will do so.
Discussion focused mainly on community feedback about moving to Drupal 8 and what does this mean in terms of the current/past founding for Islandora 7.x-2.x. Community had a positive response to Drupal 8, there is also a post on the general list by Diego.
Daniel: fully possible on the developer's side.
Nigel: talked on how to move was for Drupal 5.x - 6.x to 7.x.
Donald: since we are also changing Fedora and adding middleware, there is really nothing to port, so positive on Drupal 8 since many of the extras needed in Drupal 7 for Islandora CLAW are now part of the core.
Diego: tried to volunteer on porting current modules CLAW modules to Drupal 8
Daniel: recommended to wait for the Board and Roadmap decision on this. Nick and Melissa where already bringing this to discussion there. Also raised the relevant question to investigate what current Drupal 7 modules where not already ported to Druapl 7 that could be of use for Islandora users.
Conclusion: positive on Drupal 8, will wait on discussion at higher levels.
Daniel exposed the need to define/choose which side of the "stack" will be considered as the master in terms of sync. Both Drupal and Fedora4 have can be seen as a source for new resources and updates. If both are being updated/ingested we need a way of making sure which one will have the priority in a race condition. This is also related to where certain resources will live and figuring out which the best workflow is, real role of Fedora and Drupal.
Donald: would like to have Fedora as main the storage system. Means being able to fetch resources directly from there. Also exposed http://flysystem.thephpleague.com/ as an idea. The main idea of having a new Repository is to make use of it.
Nigel: exposed a few algorithm ideas to explore options.
Diego: thinks Drupal is a good way of caching local resources, but since Fedora is not exposed to the public we need to have a Drupal representation of the data to make LDP a reality. Expressed also we could give the user also a choice on what to sync. Also exposed how Zookeeper does an ensemble.
Daniel: expressed that anyway, we need to define a consistent sync mechanism and this is an open discussion.
Donald: asked if sync was not implemented for deletes originated on the Fedora 4 side.
Dani: said it was and if not working there could be a bug. @TODO: make an issue.
This conversation ended well over the hour, and should be continued because: it's of fundamental need to sort this out since currently even with a few concurrent operations from multiple sources the system can/could fail.
You may be looking for the islandora-community wiki · new to islandora? · community calendar · interest groups · roadmap