[tei-council] the "key" attribute
lou.burnard at computing-services.oxford.ac.uk
Tue May 22 17:57:50 EDT 2007
I wondered about this, even as I made the changes proposed. It's clear
that there is going to be some overlap: if for example my special
database actually provides a web front end, then I might be able to
access it either by means of the (magic) key "blort", or by means of a
URI such as "http://mySpecialDatabase/frontEnd?key=blort"
But I don't think this affects the issue. The idea is that there are two
ways of finding something:
(a) you point at it with a URI.
(b) you do it some other way
In the latter case, the value supplied in your document is a magic
token. We make no assumptions about how you will use that magic token to
find the thing you're looking for: that's up to you. You might look it
up in a database, you might stick some extra stuff on the front and turn
it into a URL, you might attach it to a carrier pigeon.
There are probably only a few cases where (b) is the best way of doing
things, but they do exist: the way we hook modules and elements into a
TEI schema spec is one -- we supply an identifier (the magic token) and
the Odd processor Does The Right Thing with it. Another case might be
where everybody *just knows* what you mean by a given code -- say, for
example, identifying the books of the Bible. You don't want to have to
spell out in every single Biblical commentary you encode that "Gen"
means "Genesis", etc. You just want to say "Gen". Yes, of course it's
better to spell things like that out. But there are limits to people's
willingness to be explicit!
The proposal (now implemented) is to reserve @key, with datatype
data.key, for that latter usage.
Case (a), using a URI, is of course far and away the better solution for
the vast majority of practical usages. The attribute name in this case
varies, depending on the semantics: so we have @ref, @target, @ana,
@corresp, inter alia.
Conal Tuohy wrote:
> On Tue, 2007-05-22 at 14:14 +0100, Sebastian Rahtz wrote:
>> Matthew James Driscoll wrote:
>>> It would be helpful if I had a clearer idea of the difference between key,
>>> ana and target (and ref), all of which seem to do similar, but subtly
>>> different, things. It's the "subtly different" bit that gets me.
>>> key "provides a means of locating a full definition for the entity being
>>> named such as a database record key or a URI" ]
>> no, scrub that "or a URI" bit. It can't work.
> Can you explain why? Do you mean because of your earlier point that
> there's no failsafe way to determine whether a @key is intended to
> represent a db record key on the one hand, or a URI on the other?
> I have to say I am very much a fan of @key as a URI (and of URIs as a
> preferred reference mechanism is general).
> If the problem with "or a URI" is as I supposed, another approach would
> be to require that @key always contains a URI, and recommend to encoders
> who wish to encode a locally-defined database record key that they
> encode the record key, slightly more verbosely, in some kind of URI
> <!-- not a URI -->
> <name key="name-121558">Conal</name>
> The @key above is actually a key in a database here at work. There are
> several usable http URLs I could construct from it, e.g.:
> Without using http or another resolution protocol, the key could still
> be encoded in URI syntax using the "tag" URI scheme:
> <!-- a URI -->
> <name key="tag:nzetc.org/2007,name-121558">Conal</name>
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
More information about the tei-council