Re: About the AV and L1 fields

Quoting Torsten Bronger <[email protected]>:

> I'd like to store non-URL location information in the bibliographic
> datasets, e.g. "a printed copy is available in the office of
> Dr. Meier".  This should be *global* information, i.e. not only
> available to a single user.
>
> The AV tag is only available to one user.  While the RefDB tutorial
> says that only N1, AV, and RP are personal, the manual suggests that
> this is also true for L2.  Besides, L2 seem to store only URLs.
> However, I don't really know, as RIS itself is very poorly
> specified.
>
> I don't want to waste a valuable U1..U5 field for this.  So can I
> use L2?
>

Basically yes. To the best of my knowledge refdbd does not check  
whether the contents of L2 look like an URL. Any string should be ok.  
It may just be a bit surprising if the html backend tries to render  
random strings as links, but this may not be a problem in your custom  
interface.

However, there used to be a more ingenous way to handle this. The  
get_reprint() backend function takes a username as an argument (among  
others). If this is not NULL, only the AV info of that particular user  
is returned. If you pass NULL instead, a sequential search tries to  
locate AV fields among all users that either have it in file or on  
request, and returns the first match. This would give each user a  
chance to locate at least one copy, regardless of who provided the  
information. This mechanism has the advantage that each user can still  
request his own availability if needed.

The thing is that this mechanism is simply not used by any of the  
backends at this time. All backends pass usernames to retrieve  
personal information. This is especially true for the risx backend as  
this is designed to preserve the personal information for individual  
users. In your case this is undesired. I can imagine two ways out:

- use yet another switch for the getref command that consolidates  
personal information if the current user does not have any.

- define a special username ("refdb" comes to mind) that retrieves  
consolidated information instead of that of an existing user.

Both changes seem reasonably simple to implement. Let me know if that  
would meet your needs.

regards,
Markus



-- 
Markus Hoenicka
[email protected]
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de



------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H