Skip to content

August 24, 2016

Jump to bottom Edit New page
Nick Ruest edited this page Aug 24, 2016 · 8 revisions

Time/Place

This meeting is a hybrid teleconference and IRC chat. Anyone is welcome to join. Here is the info:

Attendees

  • Nick Ruest
  • Aaron Coburn
  • Bryan Brown
  • Danny Lamb
  • Kim Pham
  • Don Richards
  • Mark Cooper
  • Ben Rosner
  • Jared Whiklo ⭐
  • Melissa Anez
  • Ed Fujikawa
  • Bethany Seeger
  • Trey Pendragon
  • Diego Pino
  • Martin Dow

Agenda

  1. Sprint check-in
  2. PCDM 2.0
  1. ... Feel free to add agenda items

Minutes

  1. No sprint updates in IRC, but lots of discussion in GitHub.
  • Danny - Read specs, Github issues, Alpaca release stuff
  • Kim - Looking into different possibilities for versioning, will draft something
  • Jared - Read ORE, Github issues.
  • Nick - Read ORE, IIIF Presentation and IIIF Image, Waiting on Alpaca code review, so he can release it.
  • Melissa - Read ORE, and Github issues.
  • Don - CLAW Security Proposal Docs (Follow-up from previous sprint)

  1. caveat - These are horrible notes, my brain can listen, think, speak and type coherently.

    Can we refer to ore:aggregates on a type pointing to another type but cover sub-classes?

    OWL allows for more complex interactions such as union or disjoint sets.

    RDFS is an OWL FULL ontology, which means that it allows anything. So you can't use any of the rich semantics of OWL.

    If everything is valid in this structure then, it is impossible to have interoperable constructs.

    If we are going to stick to PCDM, there must be some compromises on both sides to make this clearer.

    If we are going for ORE, then we can build a small restricted ontology on top or use EDM.

    An ontology defines structure, like lots of different pieces that should be built in one way only then we need OWL.

    Ontology needs to be self-explanatory, they can have some documentation

    We were not ready for data modeling discussions when PCDM was being created, now that we are thinking about this.

    If we want a restrictive ontology, does this force FileSets on everyone?

    The Works extension includes the idea of a "work". PCDM was originally a common structure, not for defining a "Work".

    In Semantics predicates are like verbs, and we are using "has" as our verb for everything.

    I'm fine with the concepts, but I want to be able to use them to model anything. That is possible, but you would create a new class off of the lower level concepts. So if PCDM changes then all our models based on it have to change.

    We need to move forward now. We can't sit and wait for PCDM 2.0 or OWL PCDM.

    We implement PCDM 1.0, and decide if we have time later for PCDM 2.0 changes. It seems like it means even more work, for Hydra.

    No triplestore in Hydra, they store the graph in Fedora.

    If we had time, we could model using Protege and build something out of the elements that PCDM gives you. Do the same for ORE and EDM.

    Curious how we reconcile the ORE ReM in a triplestore?

    With talk of order, with any predicate you want so probably iana:first, iana:next, iana:previous, iana:last

    So each individual resource would have a resource map and we would build it out of triplestore. Not persist it.

    There was a call a more restrictive ontology, but we are talking about using ORE as the base which is a very open ontology. The idea was to add a secondary type which would add the restrictions to the individual types.

    We don't understand how the PCDM spec was designed not accounting for the inherited ORE spec.

    Using PCDM automatically excludes you from using a reasoner because we don't create valid ORE models.

    How does EDM handle Resource Maps? EDM is a OWL conversion from RDFS, so they added some restrictions. They have a task force working on resolving these issues.

    TL;DR - Resource Map is a RDF version of the FOXML file from Fedora 3.

    So the reason PCDM uses ORE is that it had the best context for ordering. If we leave don't want the Resource Map, then we need to write our own SPEC.

    Resource Map must know where the graph starts and ends, because we don't have top level elements it would have to traverse the entire tree to get context for a node.

    Is the burden of creating the hacky named graph worse than the burden writing our own spec.

    There was a long discussion in the Hydra community previously along the same vein as the current FileSet discussion. That is why they know have a common view and understanding.

    Hydra has a use case for crosswalk our models to IIIF, in practice we had enough hierarchical structure in Hydra-Works to map. But if you do PCDM 1.0, there is no way to crosswalk to IIIF. You can only crosswalk to other metadata schemes that are as generic as my scheme is.

    We can continue to work in Drupal right now, and not have to nail down whether PCDM.

    Nick and Michael Giarlo are going to have a call tomorrow.

Jared's notes are not good today, too much thinky thinky not enough typey typey.

You may be looking for the islandora-community wiki · new to islandora? · community calendar · interest groups · roadmap

This is an archive. For new Tech Call notes, click here

⚠️ ARCHIVED Islandora Tech Calls

⚠️ ARCHIVED Islandora User Calls

Clone this wiki locally