Owner: URN -> Principal
The owner namespace and the owner-local namespace are hierarchical:
Pricipal-Parent: Principal -> Principal u {}
Path-Parent: Path -> Path u {}
The relationship between URNs and Entities (i.e. typed bytestrings)
is NOT a function: the same URN may relate to different Entities
under different circumstances. Hmmm... perhaps it's useful
to say that at a given time, a resource has some set of
representative entities, i.e.:
Represent : Resource x Time -> SET(Entitiy)
Then, given a URN n and a time t, we can test whether a given
entity e is a representation of the named resource, by asking whether
e in Represent(Identify(n), t)
This is the sort of thing that can be represented by authentication
certificates (digital signatures). For example, we can write:
AssertRepr(md5(...), urn:davenport/docbook.dtd/1.1,
1994-05-23-10:45:23Z)
to mean
"The octets ... represent urn:davenport/docbook.dtd/1.1
as of 1994-05-23-10:45:23Z"
And take as an axiom that if
owner says AssertRepr(entity, urn:owner:name, time)
then
entity in Represent(Indentify(owner, name), time)
(b.t.w. P says S is a primitive in authentication formalisms.
See, for example,
*************** SRC Research Report #39
Date: February 28, 1989
"A Logic of Authentication."
Michael Burrows, Martin Abadi, and Roger Needham.
48 pages.
ftp://gatekeeper.pa.dec.com/pub/../.2/DEC/SRC/research-reports/SRC-039.ps.Z
for details)
For caching purposes, the times can be generalized to intervals
of time (ala Last-Modified: thru Expires:), or probabability
distributions around a given time (i.e. given e is ok at time t0,
the probability that e is right at time t1 is a function of t1-t0).
Whew! Finally... it all makes sense. Now... to write this up
and ad it to my research notbook...
Dan