Skip to content

Internal data wishlist

Purpose: Practical data request for ORS and purchasing partners supporting a pilot import into the DePaul Resource Map.
Companion: ors-demo-readiness.md · grant-data-intake-template.md

Preferred formats: CSV or parquet with stable IDs; optional JSON lines for narrative excerpts. One row per proposal, award, equipment line, or facilities mention.

A. Grants and proposals from ORS

Requested fields

Field Description Required for pilot
proposal_title Title as entered in routing system yes
award_title Official award title if different from proposal if applicable
pi_person_id or pi_email Primary PI (DePaul directory ID preferred) yes
co_pis List of co-PI emails or IDs yes
investigators Other named investigators (postdocs, staff) optional
unit Department / school / college (canonical code) yes
funder Sponsor name yes
program Program or mechanism name yes
internal_external internal | external yes
proposal_status e.g., submitted, under review, declined yes
award_status e.g., not funded, active, closed yes
start_date Award start (ISO 8601) yes
end_date Award end (ISO 8601) yes
amount Award amount (numeric); or use amount band yes
abstract Full abstract text yes (internal)
facilities_resources_section Full text of facilities / resources / cores section critical
equipment_instrumentation_section Full text of equipment / instrumentation section critical
collaborators Named external collaborators optional
community_partners Named community partners optional
keywords Controlled or free-text keywords optional
proposal_id ORS internal tracking / routing ID yes
award_id Sponsor award number if external if applicable
public_flag May any field appear on public site yes
permitted_display_level e.g., internal_only, aggregate_public, full_public yes

Notes for ORS

  • Map to existing GRA-* records where possible; provide legacy_grant_id column if crosswalking.
  • Include unfunded proposals only if policy allows (permitted_display_level = internal_only).
  • Do not strip HTML or bullet lists from facilities sections — exact text supports quoting in evidence_text.

B. Facilities and resources text from proposals

Structured extraction (can be separate table keyed by proposal_id):

Field Description Required for pilot
proposal_id Foreign key to § A yes
named_facilities Normalized facility names (ORS taxonomy or free text) yes
named_labs Lab / center names yes
named_centers Institute / center names yes
named_equipment Instrument or system names yes
named_contacts Faculty or staff named as resource contacts optional
room_building Room / building if stated optional
exact_text_excerpt Verbatim paragraph mentioning the resource yes
display_permission Same as proposal permitted_display_level yes

Use in resource map

  • Match excerpts to resource_id (CDM-, CSH-, etc.) with human review.
  • Create grant_resource_links only when excerpt explicitly names use, access, or support — not topical mention alone.
  • Store excerpt in evidence_text; store proposal_id in evidence_file or notes.

C. Purchasing / equipment data

Field Description Required for pilot
item_description Line item description yes
vendor Vendor name optional
purchase_date ISO 8601 date yes
cost Exact cost internal
cost_range Bucket if exact cost restricted (e.g., $10k–$25k) public alternative
unit_account_project FOAPAL or project code yes
pi_responsible PI or responsible person (email or ID) yes
funding_source Grant ID, gift, or operating yes
grant_id Link to ORS proposal_id / award_id if available yes
asset_tag Capital asset tag if policy allows
building_room Location optional
category Map to equipment_taxonomy.yaml category if possible yes
public_display_allowed yes | no yes
sensitivity_notes e.g., export control, HIPAA, embargo optional

Use in resource map

  • Enrich data/resource_equipment.yaml line items with purchase provenance.
  • Validate person–resource and grant–resource edges (e.g., equipment grant GRA-007 ↔ MUS resources).
  • Never publish asset tags or exact costs on public site unless public_display_allowed: yes.

D. Data governance notes

  1. Separate public display from internal graph use
    A record may be imported for ORS analytics and graph export (include_in_graph: true) while remaining off the MkDocs site (include_in_public_site: false).

  2. Do not expose sensitive proposal text unless approved
    Full abstracts and facilities narratives stay in internal stores; public pages get summaries or aggregated stats only.

  3. Aggregate costs when needed
    Use cost_range or unit-level totals for public views; retain exact cost in restricted exports.

  4. Protect unpublished proposal content
    Submitted-but-not-awarded proposals default to internal_only unless ORS signs off.

  5. Mark evidence source and permission level on every imported edge:

  6. evidence_source: ors_export, purchasing_export, public_web, …

  7. permission_level: internal_only | aggregate_public | full_public

  8. Allow graph-useful but non-public records
    Example: grant PI activity on UNI-001 for audit trail without implying lab collaboration on the public site.

  9. Retention and refresh
    Version each export (export_date, export_batch_id); pilot imports should be idempotent on proposal_id / asset_tag.

  10. FERPA / personnel
    Exclude student names from purchasing and proposal investigator lists unless cleared for research-directory use.

Pilot scope suggestion

Source Suggested slice Target outcome
ORS One internal cycle (e.g., Fall 2021 URC/QIC) + 5 sponsored awards with facilities text +15–30 grant–resource edges reviewed
Facilities excerpts All proposals mentioning CDM-001, CSH-001, UNI-003, CDM-016 Validate SPARK / IRL / Cinespace threads
Purchasing Equipment lines for 3 PI accounts (chemistry, CDM makerspace, music) 20–50 enriched equipment line items

Contact for technical intake: resource-map maintainers · Registry paths: data/grants.yaml, data/grant_resource_links.yaml, data/resource_equipment.yaml