CharterProject PageTerminologyReferencesWorking DocumentsDeliverablesMeeting Notes


Attendees

Vitus, Dave, Christine, Nancy, Kevin

Regrets

Simeon

ACTION ITEMS:

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

Agenda

  • How do we represent deprecation and deletes?
    • Related Activity types: Create, Add, Update, Remove, Delete
    • Related date types: below.
    • One option would be to use all the types listed above and make the distinction between create and deletes of entities, and add and remove from a scheme. Few consumers would probably care about the latter and few datasets move things across schemes without deprecating the resource and creating a new URI for the entity. (so maybe it's not important to maintain this distinction)
    • Another option is to commit to Create, Update and Delete (focusing on the core moments of an entity, with Delete being used for deletes and/or deprecation). As Kevin has mentioned, LOC could always assert multiple types given they've already started with Add and Remove. Create and Add could be used together, and Remove and Delete could be used together. Consuming apps could just focus on Create and Delete.
    • Discussion:
      • One outcome could be we only speak to Create, Update and Delete
      • Another is Removed could support uses like MESH, where they remove entities, and after three years actually delete.
      • Similarly, created (followed by a review process), then added officially.
      • Create, Updated, Deleted could be adequate, but potential for 5 types
        • Emphasize Add, Update, Remove for consumers.
        • Create and Delete could be additional types, particularly useful for data producers
          • Producers should make clear if they are conflating Create and Add together, and Remove and Delete together. Consumers may want to use Create and Add as synonyms, depending on the stream implementation, but in some cases there is a meaningful distinction between Create and Add, and Remove and Delete.
        • The producer may want to keep "under the hood" internal maintenance needs, versus what needs to be consistent for consumer needs.
        • Generally (whether Create or Add) we need a message to Consumers that there's a new entity to consider, and (whether Remove or Delete) when to stop using a particular entity. Update can be used for all other meaningful changes.
  • TODO - Steven to bring this discussion to the Slack Channel to try to get some asynchronous decisions.
  • 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.