Time: 10:00 am PST / 1:00 pm EST

Call-In Info: +1 (641) 715 3660, access code 651025

Moderator: Julie Hardesty (Indiana University)
Notetaker: cmharlow (UTK)
Attendees:

Agenda & Notes

Subgroup reports
1. Descriptive Metadata Working Group
  1. carolyn.hansen reporting
    1. Did not meet last week because of DLF Forum.
    2. They will be meeting next week, however.
    3. Currently working on the element set, looking at additional items on the Descriptive WG Charge - e.g. bnodes, nested attributes, other work areas.
2. MODS and RDF Descriptive Metadata Subgroup
  1. sanderson not present at start. Juliet Hardesty reporting:
    1. There was tentative agreement to look at EDM:hasType for mods:genre, following the DPLA MAP v.4, though the DPLA restricts this predicate's object to URIs only
      1. Not sure if restricting the object to URI will work for use cases presented to group
      2. However, the Europeana DM doesn’t restrict to a URI
      3. General interest in trying to use that predicate, without object restriction
      4. Simple version of this mapping is being written up right now.
    2. sanderson also demoed his prototype upload/interface for mapping MODS/XML to MODS/RDF in a sample Fedora 4 instance hosted by Northwestern.
      1. Can upload MODS/XML file, then view the item (with MODS RDF mappings as decided so far) in Fedora.
      2. One piece is still needed: the Fedora link still being worked out. Other users cannot actually view their test records in that Fedora instance yet due to permissions, but Steven is working on it.
    3. Up for viewing on the MODS/RDF WG page are the different conversions for field decided so far: title, names, typeOfResource. Next field: mods:originInfo/mods:date*
  2. sanderson reporting later in meeting:
    1. MODS/RDF WG Notes from the last meeting will be up soon - today perhaps.
    2. His contact at Northwestern said it is okay for Steven to create username/password for that test Fedora instance holding the conversion tool, so in next few hours, check the MODS/RDF meeting notes and then try the login provided there for playing with the conversion tool.
3. Samvera Applied Linked Data Interest Group
  1. sanderson reporting:
    1. They didn't have enough participants available to hold the meeting last week due to DLF Forum.
    2. The few present did do some research to storing fields in Solr response for faster Solr querying.
    3. Next meeting, they hope to produce/have more detailed notes for handling full text in Solr while doing atomic updates - i.e. not needing to regenerate Solr record if just updating label.
4. Segment of a File Structural Metadata Working Group
  1. Juliet Hardesty reporting:
    1. They met last Monday and discussed the use cases put together so far, as well as the open annotation selector specification.
    2. They realized they have questions on the open annotation selector spec - namely, there are 2 ways to deal with selectors, general fragments selectors or specific selectors for certain open fragments. But there isn’t a complete list of things that can be used in that second option, so it is unclear what they'd want to recommend from Open Annotations without further research.
      1. They decided they want to be clear on the recommendation they create, and the use cases will help define which selectors and how to use.
      2. As such, they are continuing with use case gathering, such as for working with different formats, e.g. - XML, PDF, time-based, images
      3. The Images use case/format brings up a mention of the IIIF specification and if that’s registered anywhere, so it could be more complete selectors list than what OA is showing at present.
        
        Juliet Hardesty will email with Robert Sanderson before the next Segment of a File WG to get his feedback on the IIIF possibilities and see if he can attend the meeting.
    3. They are starting on a draft for making recommendation for referring to segments of a file, based on use cases, outlines, what OA is specifying in that fragment selector portion.
    4. Meeting again in few weeks.
Islandora Metadata Interest Group collaboration, with Jennifer Eustis and Christina Harlow
1. cmharlow and Jennifer Eustis present from the Islandora Metadata Interest Group.
  1. Jennifer Eustis:
    1. Islandora Metadata Interest Group is relatively new - a few months old.
      1. People wanted to have more enhancements for metadata work in Islandora, which lead to the group forming.
      2. The subgroups pulled together so far somewhat drift away from Islandora-specific work, though.
      3. List of subgroups at present:
      - metadata tools (not Islandora specific)
        
        enhancement features (for Islandora)
        
        fedora 4 interest
        
        hydra compatibility
        
        best practices + authorities
    2. The Islandora Group would like to collaborate on this work with the Hydra Metadata Interest Group, not duplicate work or effort.
      1. Some of the Islandora MIG subgroups will fold too because not enough people in the group.
      2. There are other Islandora Interest Groups (the Institutional Repository IG, the Islandora Fedora 4 IG) that also interact with metadata.
  2. Juliet Hardesty:
    1. She spoke with cmharlow at DLF and they talked a bit about specific subgroup activities that potentially overlap.
    2. As for the Hydra Metadata Group:
      1. MODS/RDF group - already have Islandora members involved
      2. Technical Metadata - had Islandora members involved.
    3. Agrees that there are areas where the groups can and should work together.
      - cmharlow: Hylandora work is going forward, metadata cross-pollination could help that. No 'Hylandora Group', but often that comes out of the Islandora Fedora 4 IG.
      - cmharlow: happy to serve as liaison to the folks interested in Hylandora work and look for opportunities where the Hydra or Islandora Metadata Groups can help.
    4. Technical metadata: already had baseline recommendation out, and there were Islandora members involved in that.
      - An area of future further discussion: wanting to offer more tech metadata for specific formats.
      - Islandora members are already involved in this working group, but we could use input from both groups in future work.
  3. How to move forward?
    1. Check in again? Hydra meets every 2 weeks. Check in before end of year?
    2. Islandora meets monthly, 2nd monday of each month, 1-2 PM, Islandora Google Groups announcements. Everyone invited to attend next meeting.
    3. Jennifer Eustis: At Islandora meeting - say here are possibilities for collaboration with Hydra, see what the Islandora Metadata IG members respond with.
    4. cmharlow: She will make sure to email both Google groups (Hydra and Islandora) with upcoming Islandora MIG meeting announcements.
Report on help request from Hydra developers: https://github.com/projecthydra/sufia/issues/1327
1. A request for the Metadata Group to help with a list of predicates the Hydra developers are contemplating, including the question of creating a new namespace for those they need to create.
  1. At the Hydra tech call last week, Former user (Deleted) and Nick Ruest gave a good evaluation of the predicates they are looking at currently.
  2. Notes from that Hydra Tech call show that they are trying to use existing RDF vocabularies to proceed instead of making new terms/vocabularies.
2. Question for this group: anything more specific we need to do?
  1. Esmé Cowles (?): Need to get the summary from the last Hydra Tech call, including feedback, into the original GitHub ticket so it gets followed up on.
  1. 1. However, there are good options already existing for most of the terms needing predicates, but one example of a term not having a predicate to map to at present was for proxy depositor.
  1. Juliet Hardesty will contact Former user (Deleted) + Nick Ruest to see if they can list of the terms and mapped predicates being considered in that GitHub ticket. At that point, the MIG will see if there are ones without predicates that they can work on.
3. Also up for discussion: is a namespace required for creating new predicates? Are other people are using the Oregon Digital opaque namespace in this way? Is there better namespace to use if something is to be created?
  1. The only answer that came up in the Hydra Tech Group: they don’t want to create new predicates.
  1. The PCDM namespace was brought up in the Hydra Tech Group, but the people on call were not interested in using that.
  2. sanderson: for the MODS/RDF group, when they can’t find a predicate, they use the Oregon Digital opaque namespace for predicates created for the time being.
    1. An example of using the opaque namespace is also found in the Princeton System (Trey Terrell) working on a title for sort property - they also are using the Oregon Digital opaque namespace.
  3. Juliet Hardesty: So there is precedence for using that opaque namespace in the situation of having to create new predicates.
    1. In resolving the ticket, if one of terms isn’t coming up with existing vocabulary, the MIG can finalize that this opaque namespace is okay for use in creating new predicates.
4. Other considerations on this? (No response)
Workflow for active Hydra development metadata questions (Google Groups post with details)
1. Discussion at last Hydra tech group for getting MIG feedback on Hydra development questions. Some options brought up:
  1. Project Hydra/Project Hydra Labs Github teams: This would need membership management, and the GitHub teams would include the MIG facilitator(s) and potentially MIG Working Group facilitators. The Team would then be tagged when metadata questions come up. This does require GitHub set up and team management work, requirement Hydra and Hydra Labs admin help.
  2. Tag HMIG facilitator only: This would work for Project Hydra or Project Hydra Labs, as the MIG facilitator ( Juliet Hardesty) would be notified of new MIG questions, and she would route the questions. This does narrow down time for response, as there is only one person handling the questions.
  3. New metadata Github repo: They would need the MIG github repository to be at least in Project Hydra Labs. The repository would be organized around vocabularies in progress, open issues, and people can then can opt-in for participation/handling questions. The developers would need to know to be asking questions there.
2. Other options?
3. Esmé Cowles: A GitHub team would be nice, but it requires much more management. You’d need to set it up in each organization you want to be involved in. Tagging seems more flexible. There is a lot of work spread out among GitHub (not just in Hydra Project/Hydra Labs), so it would be nice to have the tagging option because can occur anywhere.
  1. Juliet Hardesty: This also seems like what happened in the past, that Karen would get tagged for MIG questions.
4. Juliet Hardesty: For now, try tagging the MIG facilitator, Juliet Hardesty - and Julie will bring this up at the next Tech call. Ok? (Agreement)
Issues / Questions
1. None raised.
Review Metadata IG Requests and Priorities
1. Something from Google Group list for the MIG: Rick Johnson from Notre Dame asked for best practices for representing people in Hydra.
  1. Suggestions along that line for FOAF, VIVO, schema.org. But none seem a perfect fit? The Google group thread contemplates how to approach this work of non-object entities creation in Fedora/Hydra.
    1. Is there/should there be a MIG working group to address this question somewhat soon?
  2. Esmé Cowles: UCSD has a lot of non-object entities in their Fedora repository. The old UCSD data model uses MADS for that, with extensions from VRA terms. They will continue to do that work, migrating these entities over to use something like SKOS.
  3. Juliet Hardesty: Is there something that we can point to for Rick Johnson and others interested to look at that work by UCSD?
    1. Esmé Cowles: yes, there is a Google spreadsheet. Its a mapping of DPLA MAP and how that fits in with PCDM then how UCSD extends that for their local stuff. See more on the MODS/RDF page about the UCSD MAP.
    2. This MAP shows the entities they’re creating and the properties they’re attaching to those entities at UCSD. This can be sent back to Google Group list as an example of how to proceed, with the option to see if the MIG needs to present something more.
Additional Items
1. None mentioned.
Action Items
1. Everyone should feel welcome to attend the Islandora Metadata Group meeting next Monday, 1-2 PM EST.
2. Juliet Hardesty in touch with Former user (Deleted) and Nick Ruest re:the open GitHub issue. She'll ask for a response a list of the precise predicates found so far to use, and to also see if any terms don’t match existing predicates. She will also ask about using the opaque namespace.
3. Juliet Hardesty will be joining the Hydra tech call to let them know that the MIG can be contacted by tagging Juliet Hardesty, the MIG facilitator.
4. Juliet Hardesty will send the UCSD latest mapping to the Google Group discussion re:entities, see if that gives him some ways to move forward for modeling non-object entities, or see if he needs something more formal from the MIG.
5. Next meeting: 2 weeks, Wednesday 11/18, 1 PM EST