CharterProject PageTerminologyReferencesWorking DocumentsDeliverablesMeeting Notes


Attendees

  • Dave Eichmann
  • Jeff Mixter
  • Vitas Tang
  • Kevin Ford
  • Simeon Warner

Regrets

  • Steven Folsom

ACTION ITEMS (From Last Time):


Agenda & Notes

  • Our specification currently also has Split and Merge Activities, and I'd (Steven) like to propose that we remove them. The reasons being...
    • Partial Splits and Merges will be difficult to make clear using these structures.
    • We already have an established pattern of relying on dereferencing the entity URI and/or using RDF Patch for more complicated semantics.
    • Datasets could represent this data how every they want in the entity description, but if they do this in a machine actionable way they could normalize it in the ActivityStream with
      • useInstead for Deprecate Activities for full Replacement/Merges and full Splits (full Splits would have two or more useInstead statements)
      • seeAlso for Updated Activities where the entity still exists but there is a partial Merge or partial Split.
    • Discussion
      • Dave notes that we have come full circle from thinking about large actions to small scale atomic actions
      • Jeff notes that this aligns with directions in IIIF to keep simple. Datasets can represent the detail but we will still have the needed pointers
      • Simeon notes that this is a simplification that perhaps aligns with what we can realistically agree across the community. Wonder whether this precludes and future extension?
      • Dave – this is question of small atomic changes vs some larger notion of transaction
      • Vitas shared examples in Slack channel. Based on that discussion think we can have just 3 types of activity and use these are basis for all changes. Consumer will need to get additional information from provider to handle deprecation – this includes getting a pointer to the replacement in cases of deprecation
      • Kevin - we retread this ground without resolution which suggests we should not include in 1.0. Could be something we do later. So, for now, agree we should remove Split and Merge for now. 
      • Kevin - notes that not uncommon with LC NAMES to have replacement information in the notes field but it isn't 100% and we are parsing a notes field to extract the data. There is also some inconsistency in how upstream data is managed.
      • Kevin - what does LCSH delete mean? Is it still OK to use old ref but use new for new things, or should all be replaced? useInstead vs seeAlso?
      • Jeff - see also https://iiif.io/api/discovery/1.0/#seealso in IIIF change discovery
      • AGREEMENT that we should move ahead with removing Split and Merge
  • Date properties
    • When to use the following in our context:
      • endTime property definition
        • Getty usage - used on each Activity, the value is the same as for the "created" property (see issues with "created" below)
        • LOC usage - not used presently.
      • startTime property definition
        • Getty usage - not used presently.
        • LOC usage - not used presently.
      • published property definition
        • Getty usage? - not used presently.
        • LOC usage - used for each Activity Object like "Add" or "Remove" or "Update."  I.e., not used for each Object of an Activity.   Represents when the Activity Object was 'published.'
      • updated property definition
        • Getty usage - not used presently.
        • LOC usage - used for each Object of an Activity.  Represents the (last) 'update' date of the Object which is the focus of the Activity.
      • deleted property definition
        • Getty usage - not used presently.
        • LOC usage  - not used presently.
      • 'created' - is used by Getty, but understood not to be an AS property; this will be dropped by JSON-LD tooling (ok, because redundant with endTime value)
    • Not discussed

Meeting Materials


Notes

Inline above in agenda



  • No labels

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.