Thread: [Refdb-users] About the AV and L1 fields
Status: Beta
Brought to you by:
mhoenicka
Menu
▾
▴
refdb-users
|
From: Torsten B. <br...@ph...> - 2009-03-05 03:32:21
|
Hallöchen!
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?
Tschö,
Torsten.
--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: tor...@ja...
|
|
From: Markus H. <mar...@mh...> - 2009-03-05 15:33:57
|
Quoting Torsten Bronger <br...@ph...>:
> 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
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de
|
|
From: Torsten B. <br...@ph...> - 2009-03-05 21:46:24
|
Hallöchen!
Markus Hoenicka writes:
> Quoting Torsten Bronger <br...@ph...>:
>
>> 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. [...]
But is L2 a personal or a global field? According to the manual,
they "hold information which is stored for each user separately".
The RISX DTD has <link> tags in both the pubinfo (global) and the
libinfo (personal) elements.
> 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). [...] 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.
This sounds neat, however, it would not help me because I need three
things: a global link to a file, a local link to a file, and a
real-world place of an offprint. It is so complicated because some
collegues need personal copies of PDFs in order to write notes in
the PDF file. (Weird.)
Currently, I use the extension fields like this:
U1: globally set relevance, from "*" to "*****"
U2: global notes, in Markdown syntax
U3: relative path to the PDF on the central server
U4: locations of printed copies
M1: comma-separated list of Django group IDs to which this reference
belongs
M2: "1" for "institute publication", "0" for "not".
The distinction between "U" and "M" is that I may use extended notes
for "M" someday when I have too much time. ;-) Furthermore:
RP: can never be "on request"
AV: link to the personal file for the user on the central server
N1: personal notes, in Markdown syntax
> [...]
>
> - use yet another switch for the getref command that consolidates
> personal information if the current user does not have any.
This sounds more explicit so I would prefer this. But again, do it
only if you see a real use case. I am not such a case because I
need a clearly defined fallback to the *central* PDF if the user's
AV is empty. Besides, I need a PDF link and an offprint location.
Tschö,
Torsten.
--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: tor...@ja...
|
|
From: Markus H. <mar...@mh...> - 2009-03-06 00:05:52
|
Torsten Bronger writes: > > But is L2 a personal or a global field? According to the manual, > they "hold information which is stored for each user separately". > > The RISX DTD has <link> tags in both the pubinfo (global) and the > libinfo (personal) elements. > The sources say that L1 through L4 elements from risx pubinfo elements are imported without being attached to a particular user. In contrast, L1 through L4 elements from libinfo elements are owned by the corresponding user. When you retrieve risx data, you'll get back both types, i.e. the "global" pubinfo links and the personal libinfo links. A global paper copy cannot be defined at this time, except by abusing L2. > This sounds neat, however, it would not help me because I need three > things: a global link to a file, a local link to a file, and a > real-world place of an offprint. It is so complicated because some > collegues need personal copies of PDFs in order to write notes in > the PDF file. (Weird.) > If I understand correctly, all this information could be stored using risx. It is just that AV is not a global field per se, but if you employ some mechanism to set this only once you'd get close. Otherwise, as I've mentioned previously, you'd get the first available AV entry which may or may not be useful. > Currently, I use the extension fields like this: > > U1: globally set relevance, from "*" to "*****" > U2: global notes, in Markdown syntax > U3: relative path to the PDF on the central server > U4: locations of printed copies > M1: comma-separated list of Django group IDs to which this reference > belongs What are these group IDs used for? Is that similar to Unix groups? > M2: "1" for "institute publication", "0" for "not". > In general, it is not recommended to store user-defined information in RIS M1 through M3 fields. RIS uses an arcane mechanism to map information in these fields to reference type specific data (e.g. area for maps, ostype for computer programs, doi for various types). You'll lose information if you write your own stuff to these fields. If you use global and personal links as intended, you'd free U3 and U4 for the information you'd like to store in M1 and M2. regards, Markus -- Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de |
|
From: Torsten B. <br...@ph...> - 2009-03-07 08:58:40
|
Hallöchen!
Markus Hoenicka writes:
> Torsten Bronger writes:
>
>> But is L2 a personal or a global field? According to the manual,
>> they "hold information which is stored for each user separately".
>>
>> The RISX DTD has <link> tags in both the pubinfo (global) and the
>> libinfo (personal) elements.
>
> The sources say that L1 through L4 elements from risx pubinfo
> elements are imported without being attached to a particular
> user. In contrast, L1 through L4 elements from libinfo elements
> are owned by the corresponding user. When you retrieve risx data,
> you'll get back both types, i.e. the "global" pubinfo links and
> the personal libinfo links. A global paper copy cannot be defined
> at this time, except by abusing L2.
Sounds close to perfect for my plan. Okay, then:
L1 (pubinfo): path to the public PDF
L2 (pubinfo): locations of offprint
L1 (libinfo): path to personal PDF
AV: location of personal offprint
RP: whether there is a personal offprint
U1: relevance
U2: global notes
U3: group ID list
U4: whether it is an institute's publication
It's slightly strange to distinguish between "personal" and "global"
offprint, but maybe there are people who don't want to share their
copies. ;-) Be that as it may, I'm closer to the original
semantics now, which is certainly good.
> [...]
>
>> Currently, I use the extension fields like this:
>>
>> U1: globally set relevance, from "*" to "*****"
>> U2: global notes, in Markdown syntax
>> U3: relative path to the PDF on the central server
>> U4: locations of printed copies
>> M1: comma-separated list of Django group IDs to which this reference
>> belongs
>
> What are these group IDs used for? Is that similar to Unix groups?
Yes, very similar. A user can be in zero or more groups.
Actually, the Django framework defines groups to organise users,
however, you can connect everything to them. For example, if there
is a "polymer technology" user group in an institute, there is also
a bunch of "polymer technology" papers.
Tschö,
Torsten.
--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: tor...@ja...
|
|
From: Torsten B. <br...@ph...> - 2009-04-10 19:51:24
|
Hallöchen!
Markus Hoenicka writes:
> Torsten Bronger writes:
>
>> But is L2 a personal or a global field? According to the manual,
>> they "hold information which is stored for each user separately".
>>
>> The RISX DTD has <link> tags in both the pubinfo (global) and the
>> libinfo (personal) elements.
>
> The sources say that L1 through L4 elements from risx pubinfo elements
> are imported without being attached to a particular user. In contrast,
> L1 through L4 elements from libinfo elements are owned by the
> corresponding user. When you retrieve risx data, you'll get back both
> types, i.e. the "global" pubinfo links and the personal libinfo
> links.
Are pubinfo and libinfo inextricably intertwined or perfectly
separated?
An example which confuses me: I send the following to RefDB with the
updateref command:
<entry citekey="Bld2006" id="1" type="JOUR">
<part>
<title>Electron Spin Resonance in thin film silicon after low
temperature electron irradiation</title>
<author>
<lastname>Blöd</lastname>
<firstname>H.</firstname>
<middlename />
</author>
</part>
<publication>
<title type="full">Thin Solid Films</title>
<pubinfo>
<link type="pdf">PUBLIC</link>
</pubinfo>
</publication>
<libinfo user="drefdbuser1">
<reprint status="INFILE" />
<link type="pdf">PRIVATE</link>
</libinfo>
</entry>
With getref, I get RISX data which contains this:
<publication>
<title type="full">Thin Solid Films</title>
<pubinfo>
<link type="pdf">PRIVATE</link>
<link type="pdf">PUBLIC</link>
</pubinfo>
</publication>
<libinfo user="drefdbuser1">
<reprint status="INFILE"/>
<link type="pdf">PRIVATE</link>
<link type="pdf">PUBLIC</link>
</libinfo>
Actually, although the DTD allows that, I'm quite suprised that two
"pdf" links are possible. Additionally, why do I find both links in
pubinfo as well as in libinfo? Can one avoid this?
Tschö,
Torsten.
--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: tor...@ja...
|
|
From: Markus H. <mar...@mh...> - 2009-04-17 20:24:21
|
Torsten Bronger writes: > Are pubinfo and libinfo inextricably intertwined or perfectly > separated? > They are supposed to be treated separately. Your example helped to fix two unrelated bugs which caused the behaviour you saw. First, a bug prevented public links to be added to the returned string if pubinfo does not contain anything else but link elements. That is, the data were correctly added to the database and correctly retrieved, but they were simply not added to the result string. Second, a SQL query bug requested both public and private links when retrieving the libinfo link elements. This is now fixed in svn. However, there is one thing to keep in mind. The current implementation uses a simple check for "file://" at the start of each link to make sure a libinfo link is an URL pointing to a file resource owned by the user, and not a public URL accessible via http or ftp. That is, libinfo links using any protocol other than "file://" or none at all end up being added as public links. This code has been added too long ago to exactly remember why it was added. It now looks a little strange to me, and I'm open to suggestions whether or not to remove this restriction. regards, Markus -- Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de |
|
From: Torsten B. <br...@ph...> - 2009-04-19 20:21:25
|
Hallöchen!
Markus Hoenicka writes:
> Torsten Bronger writes:
>
>> Are pubinfo and libinfo inextricably intertwined or perfectly
>> separated?
>
> They are supposed to be treated separately. Your example helped to
> fix two unrelated bugs which caused the behaviour you saw.
Thank you!
> [...]
>
> [...] However, there is one thing to keep in mind. The current
> implementation uses a simple check for "file://" at the start of
> each link to make sure a libinfo link is an URL pointing to a file
> resource owned by the user, and not a public URL accessible via
> http or ftp. That is, libinfo links using any protocol other than
> "file://" or none at all end up being added as public links. This
> code has been added too long ago to exactly remember why it was
> added. It now looks a little strange to me, and I'm open to
> suggestions whether or not to remove this restriction.
In my opinion, it should be removed. If a private link is turned
into a public one implicitly, this is a source of irritation.
Tschö,
Torsten.
--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: tor...@ja...
|
|
From: Torsten B. <br...@ph...> - 2009-04-19 20:31:32
|
Hallöchen!
Markus Hoenicka writes:
> [...]
>
> [...] However, there is one thing to keep in mind. The current
> implementation uses a simple check for "file://" at the start of
> each link to make sure a libinfo link is an URL pointing to a file
> resource owned by the user, and not a public URL accessible via
> http or ftp. That is, libinfo links using any protocol other than
> "file://" or none at all end up being added as public links. This
> code has been added too long ago to exactly remember why it was
> added. It now looks a little strange to me, and I'm open to
> suggestions whether or not to remove this restriction.
This reminds me that I wanted to ask about the privacy policy in
RefDB. From my tests it seems that I can see all <libinfo> datasets
of all other users. Is this correct, or how can I change this?
Tschö,
Torsten.
--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: tor...@ja...
|
|
From: Markus H. <mar...@mh...> - 2009-04-19 22:04:53
|
Zitat von Torsten Bronger <br...@ph...>: > This reminds me that I wanted to ask about the privacy policy in > RefDB. From my tests it seems that I can see all <libinfo> datasets > of all other users. Is this correct, or how can I change this? > I think this is correct. The idea was to make the location of other copies of an article available if you don't have a copy of your own. I have no idea whether this works in a real-world setting. I was also under the impression that there would be no demand to hide offprints from co-workers, so in contrast to extended notes (which can be kept private) links are supposed to be public. Would you prefer to treat link as private data, maybe optionally? regards, Markus -- Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de |
|
From: Torsten B. <br...@ph...> - 2009-04-19 23:46:35
|
Hallöchen!
Markus Hoenicka writes:
> Zitat von Torsten Bronger <br...@ph...>:
>
>> This reminds me that I wanted to ask about the privacy policy in
>> RefDB. From my tests it seems that I can see all <libinfo>
>> datasets of all other users. Is this correct, or how can I
>> change this?
>
> I think this is correct. The idea was to make the location of
> other copies of an article available if you don't have a copy of
> your own. I have no idea whether this works in a real-world
> setting. I was also under the impression that there would be no
> demand to hide offprints from co-workers, so in contrast to
> extended notes (which can be kept private) links are supposed to
> be public.
But it is not only <link>, it is also <notes>. Is <notes> realised
with extended notes?
> Would you prefer to treat link as private data, maybe optionally?
Actually I like liberal settings. Especially because I think RefDB
is used in rather small groups < 100 people without anonymity where
excessive permission management is not vitally important.
Refbase plans to add fine-grained permission control, but I think
this is overkill. It would be nice however if RefDB's log facility
enabled the admin to detect vandalism.
In Django-RefDB, I will install only one permission, namely the
permission to edit entries other than yours. Django-RefDB keeps
track who created an entry, and you can always edit your entries,
but not those of others, unless you have that permission.
Tschö,
Torsten.
--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: tor...@ja...
|
|
From: Markus H. <mar...@mh...> - 2009-04-20 10:46:28
|
Quoting Torsten Bronger <br...@ph...>: > But it is not only <link>, it is also <notes>. Is <notes> realised > with extended notes? > No, <notes> are stored in a simple text field, together with the reprint status (i.e. separately for each user). Extended notes are entirely separate. regards, Markus -- Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X