2016-12-01—FileSets WG Meeting

December 1st 2016, 2pm EDT

Google Hangouts: https://hangouts.google.com/hangouts/_/artic.edu/pcdm-filesets?authuser=0

• scossu

• Andrew Myers

• Esmé Cowles

• kefo

• Juliet Hardesty

• nikhil trivedi

• Joshua Allan Westgard 

1. Review deliverable list changes in charter:  FileSets Working Group

2. Decide how to proceed with implementation. We have 2 options: 

   1. Apply the intended changes to FileSets and use these as the reference aggregator for Files

      1. Leave the the option to relate Files directly to Objects?

   2. CC does not use FileSets at all

      1. Define a new sub-class of pcdm:Object within a Hydra namespace and use that as the File aggregator

3. Lay out action plan

   1. Resources

   2. Timeline

   3. Enter tickets in Github repo: https://github.com/projecthydra-labs/hydra_file_sets_wg

Previous action Items:

• Because the group no longer envisions making changes to PCDM, the WG charter and work plan have been updated. 

• Discussion of the action plan for implementation.

• Question of "pcdmuse" terms and whether the available list of terms should be updated or supplemented to meet the use cases we have discussed.  This is the one way the work of this group might touch the PCDM ontologies.

  • Does the 'use' of a particular file connect the file to another file in the fileset, or to the fileset itself

  • Question of whether a fileset can contain more than one 'original' file?  This does not seem to be something that is (or can be?) enforced in the ontology, though it could be done at the application layer.

• Possible resolution of the fileset question: Filesets could be just a normal pcdm:Object that is also a special class in Hydra (in CurationConcerns/HydraWorks) only.  PCDM would be unaware of them.

• Most manageable solution is probably for Hydra to always create a FileSet between an "work object" and its files.

• Discussion of the workflow for getting changes pulled into the Hydra codebase.

  • For the PCDM ontology, which lives in the Duraspace Github, we can do pull requests against the main branch directly.

  • Adding forms and controllers to curation concerns is also unlikely to get in anyone's way or cause other problems that might warrant creating their own branches, etc.

  • Generally speaking, let's avoid creating unnecessary branches and forks in projecthydra-labs or elsewhere.

  • Do what you would normally do to submit a PR, but be sure to reference the FileSets WG and the relevant use case in the comment's section for the PR.

• If we get the tickets well defined, that might make is easier to recruit developers for a sprint in January.

• The deadline for deliverables in the charter is March 1.

Everyone who created a diagram: Associate the existing diagrams to their use cases.

Andrew Myers - add these as tickets in github, so we can discuss/track our work.

Everyone should finish putting their use cases into tickets in general terms, which can then be refined and further specified by folks who might be doing the actual coding.