CharterProject PageTerminologyReferencesWorking DocumentsDeliverablesMeeting Notes


Attendees

Steven, Nancy, Vitus, David, Kevin

Regrets

Christine

ACTION ITEMS (From Last Time):

TODO reflect three state consumer focused decision for create/add, update, and delete/remove

Agenda

  • How do we represent deprecation and deletes?
    • From last time 
      • We were leaning toward our recommendation really only focusing on the consumer needs, leaving room for the data producer to define their own needs/internal implementation
        • Create and/or Add be used for new things
        • Update for any type of update
        • Delete and/or Remove for no longer in use entities
  • Steven brought this discussion to the Slack Channel after the last meeting to try to get some asynchronous decisions.
    • https://github.com/LD4/entity_metadata_management/pull/75
      • Should we remove the Create vs. Add section?
        • If you don't want someone to know about an entity yet, and you're using Create for internal operations, don't add it to the consumer stream. TODO add language to the Create vs. Add section.
      • Is it ok to collapse 5.3 and 5.4 into one section?
        • Section "Making an entity obsolete"
          • Remove vs. Delete
            • These can be at the same time, the important point for the consumer is the moment when an entity is obsolete. This allows the provider to have separate states.
            • Deletes in theory, would result in 404. The spec should support add/update/remove even if the http isn't done "correctly".
            • Getty uses Delete for Deprecation.
              • Could they be open to Deprecation activities? (Would require code updates and using an ActivityStream extension) TODO Steven to ping David.


  • (Didn't have time to discuss) 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)
      • Getty advertises as Create, Update, Delete Types
      • LOC advertises as Add, Update, and Remove Types. Deletes is really what they are doing (deprecation is the default to keep URIs from disappear). If changed to Delete , they wouldn't actually delete, still deprecating. Remove is pointing out that these terms are removed from a scheme when deprecated. Add is pointing out that when a term is created, it's added to a scheme.
      • Could proceed with these differences, or align if the distinctions aren't important.
        • Moving a term from one scheme to another, not just deleting, is reflected like a normal deprecate with a separate add in another stream.
        • Could have multiple types (Create/Add, Remove/Delete/Change)
          • E.g. "type": ["Create","Add"],
          • E.g. "type": ["Delete","Remove","Update"],
        • From AS, "When an implementation uses an extension type that overlaps with a core vocabulary type, the implementation must also specify the core vocabulary type."
        • Think more about origin/target before deciding on types.
        • TODO does Getty actually delete?
  • TODO from last meeting: Dave will create a 7.0, and we can compare it to 7.1 and an eventual 7.2 (for Getty's activity stream). Then we can decide what might be removed and/or added to an appendix
  • Continue to discuss examples (updated)
    • Examples: https://gist.github.com/sfolsom/07338b416ca605d92984c24c346ba5fe 
      • From previous meeting: Multi typing is probably not the best way to work through the Deprecation, Merging, and Splitting. They may happen over time. Creations of objects that  are the new targets needs to happen before Splits and Merges.
        • X and Y replaced by Z (full merge), X and Y are deprecated
        • Parts X are now considered Z (partial Split)
        • Parts X are now considered Z (Partial split), and all of Y are Z (replaced), Y is deprecated
        • X is now either Y or Z (full Split), X is deprecated
        • What happens in the moment?
          • E.g. two names for the same person. You deprecate one and then point to the remaining authority
          • E.g. undifferentiated name, some of the things linked to can now be attributed to a specific other name.
          • E.g. undifferentiated name, all thinks linked to are now attributed to two or more other names.
          • E.g. undifferentiated name, status changed to because everything is attributed to 
          • E.g. shared pseudonyms TODO flesh out possible changes that occur related to shared pseudonyms.
          • E.g. two units within and organization, the two existing units are collapsed into one (the authorities remain), and a new one is used.
            • Time period for applicability can be recorded. 

Meeting Materials



  • No labels

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