Property Lists: When Metadata Outweighs the Specimen

A mineral specimen without locality data is scientifically worthless. Beautiful malachite, perfect crystal habit, stunning colour—but if you don’t know where it came from, it’s decorative at best. Type locality specimens (the first-ever example from a specific location) command five to ten times the price of identical minerals from elsewhere. The metadata is the value.

Property lists solve this problem in code: attach arbitrary key-value metadata directly to an object. In 1960s Lisp systems, every symbol could carry a property list—a flexible way to store facts without rigid schemas.

(define property-table '())

(define (properties obj)
  (let ((entry (assoc obj property-table)))
    (if entry (cdr entry) '())))

(define (without-object obj entries)
  (cond ((null? entries) '())
        ((eq? (caar entries) obj) (without-object obj (cdr entries)))
        (else (cons (car entries) (without-object obj (cdr entries))))))

(define (put-property obj key value)
  (let* ((plist (properties obj))
         (updated (cons (cons key value) plist)))
    (set! property-table
          (cons (cons obj updated)
                (without-object obj property-table)))))

(put-property 'specimen-427 'species 'malachite)
(put-property 'specimen-427 'locality "Bisbee, Arizona")
(put-property 'specimen-427 'collected "1952-08-12")
(put-property 'specimen-427 'hardness 3.5)
(put-property 'specimen-427 'crystal-system 'monoclinic)

Java inherited this pattern through the Properties class, though it’s strictly string-to-string. For minerals, you’d use a HashMap<String, Object> to store mixed types.

import java.util.*;

public class Specimen {
    private Map<String, Object> properties = new HashMap<>();
    
    public void put(String key, Object value) { properties.put(key, value); }
    public Object get(String key) { return properties.get(key); }
    
    public static void main(String[] args) {
        Specimen s = new Specimen();
        s.put("species", "malachite");
        s.put("locality", "Bisbee, Arizona");
        s.put("hardness", 3.5);
        System.out.println(s.get("locality"));
    }
}

The trade-off: flexibility versus type safety. Property lists let you add new facts without changing schemas—perfect for museum catalogues where you might add “UV fluorescence” decades after initial entry. But you lose compile-time guarantees. The key "hardnes" (typo) will compile fine and fail silently at runtime. Mineral databases still use this pattern because the flexibility wins: every specimen is slightly different, and the properties you care about evolve.