# Re: date in URN

Peter Deutsch (peterd@bunyip.com)
Sun, 25 Jun 1995 13:02:05 -0400

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Peter Deutsch: "Re: date in URN"
- Previous message: Peter Deutsch: "<SIGH> (was: Re: date in URN)"
- Maybe in reply to: Michael Shapiro: "date in URN"
- Next in thread: Peter Deutsch: "Re: date in URN"

    Message-Id: <9506251702.AA16886@expresso.bunyip.com>

    From: Peter Deutsch <peterd@bunyip.com>

    Date: Sun, 25 Jun 1995 13:02:05 -0400

    In-Reply-To: Mark Madsen's message as of Jun 23, 17:14

    To: Mark Madsen <msm@ansa.co.uk>

    Subject: Re: date in URN

g'day,

[ Mark Madsen wrote: ]

} Peter Deutsch wrote:
}
} > What we're currently doing in Silk for our headlines (the
} > URN-like results lists generated by URAs) is to have an
} > internal structure which contains a human readible string
} . . . and an
} > accompanying URL. In addition, we've also added a
} > placeholder for IETF URNs which will be filled in by any
} > URN supplied by the net, once they start to arrive.
}
} This description makes a headline sound like a member of the URC
} class. Is this the case? If so, could you expand on how exactly
} they differ?

I see the term URC being used for a variety of
amalagamated information needs, and if you see this
suggestion for a two part URN as really two separate
components then yes it is a form of URC. All I ask is that
syntax for such URCs allows us to specify my new, bivalve
URN and if I can, then great.

The issue I was trying to bring up was that as Karen has
now pointed out, at some point we need to worry about a
human readible part and at others we need these things to
be fairly mechanical for automated processing. Thus, I am
suggesting that to satisfy these conflicting requirements
we should consider adding another "field" to the current
URN proposals that would allow both, as is currently done
in gopher menu items, for example.

Hmmm, upon reflection Karen may be right that we need to
reconsider the "name" in URN...

} > Comparison (remember comparison? Some of us still think
} > that being able to compare URNs is going to be vital) will
} > be done on that URN, not the displayable string, but
} > allowing both lets us maintain a usable human interface.
}
} Sounds like comparison should be possible in a variety of ways. Don't
} insist on something that's more restrictive than you need.

Sorry, I didn't think I was. I fact, the reason I propose
separate "human URN" and "mechanical URN" fields is to
allow people to come up with their own comparison and
dereferencing schemes long after we freeze the spec.
We've already seen the need for both fields in Silk and
suspect that this experience will generalize to others
when they get to building true URI (as opposed to URL)
tools.

- peterd

    --
    ------------------------------------------------------------------------------

      ...there is reason to hope that the machines will use us kindly, for
      their existance will be in a great measure dependent on ours; they will
      rule us with a rod of iron, but they will not eat us...

                                                   - Samuel Butler, 1872
    ------------------------------------------------------------------------------

- Next message: Peter Deutsch: "Re: date in URN"
- Previous message: Peter Deutsch: "<SIGH> (was: Re: date in URN)"
- Maybe in reply to: Michael Shapiro: "date in URN"
- Next in thread: Peter Deutsch: "Re: date in URN"