[tei-council] the "key" attribute

[Syd Bauman]

SR> all the things which are members of att.naming

Thank you.


SR> OK, how about we do this:
SR>   - leave @key on <memberOf> etc as is

sure


SR>   - change att.naming to remove @key and put in @ref as pointer
SR>     instead

I am not in favor. I don't mind renaming @key, but I think its
functionality has to stay.[1] E.g., the US LOC may have changed
recently, but as of a few years ago you could not access an LOC name
authority record via a URI.


SR>   - discuss at places meeting next week whether they need the @key 
SR>     functionality back, and if so ask them to choose a name

I don't think there is really any need for discussion -- it has to
stay.[1] (Its name, on the other hand ... :-)


LB> The idea is that there are two 
LB> ways of finding something:
LB> (a) you point at it with a URI.
LB> (b) you do it some other way
LB> In the latter case, the value supplied in your document is a magic 
LB> token. We make no assumptions about how you will use that magic token to 
LB> find the thing you're looking for: that's up to you. You might look it 
LB> up in a database, you might stick some extra stuff on the front and turn 
LB> it into a URL, 

In which case it really should be a cRef=. Which makes some sense.


LB> There are probably only a few cases where (b) is the best way of
LB> doing things, but they do exist: the way we hook modules and
LB> elements into a TEI schema spec is one -- we supply an identifier
LB> (the magic token) and the Odd processor Does The Right Thing with
LB> it.

I am unconvinced that this is a correct analysis. As I've said, I see
three categories:
1. point at it with a URI
1a. use the cRef= mechanism for shorthand of a URI
2. point at it by matching its ident= (remember this is used not only
   be key= of <memberOf> et al., but also by xml:lang=)
3. a user-defined magic token
The <memberOf> usage is not a user-defined black box method of
finding something. This is clearly defined: the value has to match an
ident= in the same document, no?


LB> Another case might be where everybody *just knows* what you mean
LB> by a given code -- say, for example, identifying the books of the
LB> Bible. You don't want to have to spell out in every single
LB> Biblical commentary you encode that "Gen" means "Genesis", etc.
LB> You just want to say "Gen". Yes, of course it's better to spell
LB> things like that out. But there are limits to people's
LB> willingness to be explicit!

This is a really good example, and a potential reason why the tag:
URL scheme won't really solve the problem -- people who don't want to
bother being explicit are certainly not going to want to develop tag:
URLs. 


LB> I wondered about this, even as I made the changes proposed. ...
LB> The proposal (now implemented) is to reserve @key, with datatype
LB> data.key, for that latter usage.

I'm sorry, what has now been implemented? What change (if any) has
been made?


Notes
-----
[1] However, Conal's suggestion of using the tag: URI scheme bears
    further thought and discussion -- it may actually provide
    sufficient functionality, but I'm not convinced yet. And I don't
    really have the capability to read up on it right now from
    dial-up land, but it's worth reading up on:
    http://www.rfc-editor.org/rfc/rfc4151.txt