[tei-council] the "key" attribute

[Lou Burnard]

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
> syntax.
>
> <!-- 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.:
>
> <name
> key="http://www.nzetc.org/tm/scholarly/name-121558.html">Conal</name>
>
> 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
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
>