Data Provenance (DPS) TC

 View Only
  • 1.  Geographic Restrictions

    Posted 08-13-2025 11:18
      |   view attached

    Yesterday we discussed use cases and metadata representation for geographic restrictions on processing and storage.  The D&TA states that both blacklists of denied locations and whitelists of allowed locations are required, so we need an ambiguous way for users to determine, given the metadata for a dataset, if processing is approved in location X.

    Stefan and I believe that layers are a necessary and easily-understood mechanism.  Anyone who has made Powerpoint diagrams has seen layering - the "move to top, move up, move down, move to bottom" commands to control visibility of shapes.  Geographic restrictions can be specified the same way, ordered from most general on the bottom layer up to most specific and highest precedence at the top.  Attached is a proposed schema for layered geographic restrictions, and JSON data examples to go in the processing and storage fields.  Of note, a virtual base layer covers "everywhere" without needing to create a name for everywhere or include it in metadata.  It's allow/forbid status is the opposite of the first layer in the metadata, and making it automatic makes metadata more robust.

    Does this make sense?



    ------------------------------
    David Kemp
    National Security Agency
    ------------------------------

    Attachment(s)

    pdf
    DPS-Geography.pdf   42 KB 1 version


  • 2.  RE: Geographic Restrictions

    Posted 08-13-2025 12:42

    Hi David (and Stefan, and all!),

     

    Thank you for all of your time and efforts invested thus far and guiding us down a clear path for clarifying the standards requirements. The layering analogy is a good one, and I think it will be intuitive for users who have worked with visual stacking concepts before. The implicit "everywhere" base layer with inverted allow/forbid status is a clean way to avoid special values for global scope and yet keeping the rules unambiguous.

     

    The schema and JSON examples look good.

     

    Thanks again for putting this together. Hopefully we can all think through (and contribute) any edge cases we should account for.

     

    Kristina