refbase-talk — This list is intended for general discussion of the web reference database

Re: [refbase-talk] refbase in different directory

[Matthias S. <mst...@re...>]

Hi Hugh,

I may be misunderstanding you but couldn't you simply use the
"-Indexes" option in the directory options directive (placed inside
your .htaccess file of your files directory)?

 <http://httpd.apache.org/docs/2.2/mod/core.html#options>

Wouldn't this prevent users from seeing file listings inside your files
directory?

W.r.t. your other issue (i.e., keeping refbase script URLs at the
subdomain's root level, although the scripts are really stored within
a "refbase" subdir): I guess this would require some URL rewriting
using mod_rewrite.

 <http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html>
 <http://httpd.apache.org/docs/2.2/rewrite/rewrite_guide.html>

I'm by no means a mod_rewrite expert (and I haven't tested it), but
wouldn't the following mod_rewrite rule work (inside your main
.htaccess file):

 RewriteEngine on
 RewriteCond %{REQUEST_URI} ^/refbase/
 RewriteRule ^/refbase/(.*)$ /$1 [L]

As I said, this example could be completely wrong, but something along
these lines should work.

HTH, Matthias


On Sat, 15-Aug-2009 09:09 -0500, Hugh Paterson III wrote:

> I am trying to install refbase in subdirectory of a sub-domain.  
> straight forward. that would normally look like this:  sub.domain.org/ 
> refbase
> 
> however I want to keep the refbase files in the directory /refbase but  
> I want the users to have complete access to the application at just  
> the sub.domain.org address. And I want URLs created by refbase to have  
> the following syntax.
> 
> sub.domain.org/what-ever-refbase-creates.php
> 
> If I use .httaccess to redirect traffic from sub.domain.org to  
> sub.domain.org/refbase then I get URLs with the following syntax
> 
> sub.domain.org/refbase/what-ever-refbase-creates.php
> 
> This is not what I want because it shows that there is a directory  
> where all the refbase files are located.
> 
> 1. Is what I want to do possible?
> 2. If it is how do I do it?

[refbase-talk] install with utf-8 instead of latin1.

[Hugh P. I. <sil...@gm...>]

another question on the install process.
When I am running the install.php script and want to install the utf-8  
SQL file so I need to replace the default file name "./install.sql"  
with "./install_utf8.sql" or will selecting utf8 in the drop down menu  
suffice?
[Screenshot in the included .jpg]

[refbase-talk] refbase in different directory

[Hugh P. I. <sil...@gm...>]

I am trying to set up refbase and need a bit of help. If someone can  
help me answer the 2 questions a the bottom of this email that would  
be great.

I am trying to install refbase in subdirectory of a sub-domain.  
straight forward. that would normally look like this:  sub.domain.org/ 
refbase

however I want to keep the refbase files in the directory /refbase but  
I want the users to have complete access to the application at just  
the sub.domain.org address. And I want URLs created by refbase to have  
the following syntax.

sub.domain.org/what-ever-refbase-creates.php

If I use .httaccess to redirect traffic from sub.domain.org to  
sub.domain.org/refbase then I get URLs with the following syntax

sub.domain.org/refbase/what-ever-refbase-creates.php

This is not what I want because it shows that there is a directory  
where all the refbase files are located.

1. Is what I want to do possible?
2. If it is how do I do it?

Thanks,
Hugh

Re: [refbase-talk] simple search in external website

[Matthias S. <mst...@re...>]

Hi Daniel,

thanks for the feedback and glad that it's working for you now.

I can confirm that the autocompletion feature on your website works as
expected.

Best regards,

Matthias


On Thu, 6-Aug-2009 14:11 +0200, Daniel Becker wrote:

> > Hallo - with your help, it was not very difficult to include the
> > QuickSearchForm into the other website. Thanks for your help.
> >
> > But - just to report it back - the autocompletion does not work -
> > neither at
> > http://beta.refbase.net/quick_search_test.html
> > nor on
> > http://www.deabib.org/deabib.html
> > The scripts are included in the header part, but still....
> 
> Sorry for the noise - autocompletion works with your example. And
> also with mine, after I corrected my errors. Great!

Re: [refbase-talk] simple search in external website

[Daniel B. <dan...@un...>]

Am 06.08.2009 um 13:27 schrieb Daniel Becker:

>> Let me know if you need further help with this.
>
> Hallo - with your help, it was not very difficult to include the
> QuickSearchForm into the other website. Thanks for your help.
>
> But - just to report it back - the autocompletion does not work -
> neither at
> http://beta.refbase.net/quick_search_test.html
> nor on
> http://www.deabib.org/deabib.html
> The scripts are included in the header part, but still....

Sorry for the noise - autocompletion works with your example. And also  
with mine, after I corrected my errors. Great!

Daniel

Re: [refbase-talk] simple search in external website

[Daniel B. <dan...@un...>]

> Let me know if you need further help with this.

Hallo - with your help, it was not very difficult to include the  
QuickSearchForm into the other website. Thanks for your help.

But - just to report it back - the autocompletion does not work -  
neither at
http://beta.refbase.net/quick_search_test.html
nor on
http://www.deabib.org/deabib.html
The scripts are included in the header part, but still....

It is not a big deal, however...

Best,
Daniel

Re: [refbase-talk] simple search in external website

[Matthias S. <mst...@re...>]

Hi Daniel,

On Sat, 1-Aug-2009 12:14 +0200, Daniel Becker wrote:

> how do I include a simple search form into another website? I tried
> to look into the docs, but without success.

I think you can usually just copy the relevant HTML bits from the
refbase HTML source displayed in your browser.

> What I want is that the small form in the top right of
> http://beta.refbase.net/ (below the small text "login")

We call this form the "Quick Search" form.

> is shown on another site, and when the user enters something there,
> the results are shown as usual by refbase...

I've made a simple HTML example page which just contains the Quick
Search form. You can try it out here:

 <http://beta.refbase.net/quick_search_test.html>

The HTML source of that page shows you the required bits of HTML to
make the form work.

The four <script>...</script> tags are only needed to make the
auto-completion feature work.

You might also want to look at the '#queryrefs ...' style definitions
given in the linked CSS file (in 'css/style.css').

Let me know if you need further help with this.

Best regards,

Matthias

[refbase-talk] simple search in external website

[Daniel B. <dan...@un...>]

Hallo -

how do I include a simple search form into another website? I tried to  
look into the docs, but without success.

What I want is that the small form in the top right of http://beta.refbase.net/ 
  (below the small text "login") is shown on another site, and when  
the user enters something there, the results are shown as usual by  
refbase...

Thanks -

Daniel

Re: [refbase-talk] Abstracts in RIS

[Torsten B. <br...@ph...>]

Hallöchen!

Matthias Steffens writes:

> [...]
>
>> Chris Putnam wrote:
>>
>>> [...]  The second question is: Is the other opinion important
>>> enough to offer a command-line option to change the default
>>> behavior of Bibutils?  I'm certainly happy to do so for those
>>> users who do care about using AB vs. N2....

If too much would break if Bibutils adopted the specification
strictly, I suggest to apply Postel's Law ("be conservative in what
you do, be liberal in what you accept from others"):

Bibutils should export abstracts into N2 fields and shouldn't
generate AB fields at all.  And it should import AB by default as
abstracts, and by option as N1.  (Rationale: Most people wanting to
write notes will use N1 anyway, and most people using AB will think
it's for abstracts.)

>> I think that such an option is useful, even if it wouldn't help me
>> because Refbase probably won't expose this option to the user.
>
> It wouldn't be too difficult to provide an option for this in
> refbase's 'ini.inc.php' file.

Granted, but in a situation with dozens, maybe hundreds of users,
everyone using different tools, a fixed global configuration is not
that helpful.  Instead, it should be exposed as an option for every
RIS import and export, which is rather ugly, though.

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
                   Jabber ID: tor...@ja...
                                  or http://bronger-jmp.appspot.com

Re: [refbase-talk] Abstracts in RIS

[Torsten B. <br...@ph...>]

Hallöchen!

Torsten Bronger writes:

> [...]
>
> No, there is no consensus.  The RIS specs say that AB is not the
> abstract.  Yes, you read correctly.  AB is *not* the abstract, but
> N2 and only N2.  AB is the same as N1, the global notes.
>
> [...]
>
> I will try to contact Thomson Reuters to see what they think about
> it.  At least, they have a web forum.

The thread can be found at
http://community.thomsonreuters.com/ts/board/message?board.id=rm-general&thread.id=193

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
                   Jabber ID: tor...@ja...
                                  or http://bronger-jmp.appspot.com

Re: [refbase-talk] Abstracts in RIS

[Matthias S. <mst...@re...>]

Hi Torsten & Chris,

thanks to both of you for your input.

On Mon, 27-Jul-2009 20:35 +0200, Torsten Bronger wrote:

> > [...]  The second question is: Is the other opinion important
> > enough to offer a command-line option to change the default
> > behavior of Bibutils?  I'm certainly happy to do so for those
> > users who do care about using AB vs. N2....
> 
> I think that such an option is useful, even if it wouldn't help me
> because Refbase probably won't expose this option to the user.

It wouldn't be too difficult to provide an option for this in
refbase's 'ini.inc.php' file.

Matthias

Re: [refbase-talk] Abstracts in RIS

[Torsten B. <br...@ph...>]

Hallöchen!

Chris Putnam writes:

> On Thursday 23 July 2009 04:14:55 pm Richard Karnesky wrote:
>
>> Torsten Bronger wrote:
>>
>>> In RIS output, abstracts should go into the N2 field rather than
>>> the AB field.
>>
>> [...]
>
> [...]
>
> I currently output it as AB and not N2 (risout.c):
>
>         output_easy( fp, info, refnum, "ABSTRACT", "AB", -1 );
>
>
> So the real question for me is: Is there a consensus on where the
> abstract ought to go by default?

No, there is no consensus.  The RIS specs say that AB is not the
abstract.  Yes, you read correctly.  AB is *not* the abstract, but
N2 and only N2.  AB is the same as N1, the global notes.

This is perfectly potty but the official specs are the primary
source of information.  I'm not an expert in bibliography managers
but apparently, some applications interpret AB as the abstract.  And
some apps stick to the specs and are anwilling to act against them.

I think it could be useful to evaluate how much real-world workflow
would break if bibutils assumed AB==N1!=N2 by default.

I will try to contact Thomson Reuters to see what they think about
it.  At least, they have a web forum.

> [...]  The second question is: Is the other opinion important
> enough to offer a command-line option to change the default
> behavior of Bibutils?  I'm certainly happy to do so for those
> users who do care about using AB vs. N2....

I think that such an option is useful, even if it wouldn't help me
because Refbase probably won't expose this option to the user.

> On Friday 24 July 2009 12:05:16 am Torsten Bronger wrote:
>
>>>> AB is just the same as N1, and since Refbase sets N1 as well,
>>>> we have a collision on the importing side.
>>>
>>> [...]
>
> Note that the Oxford Journals actually hide the DOI in the N1
> field...

They may well do so, unless they also set AB.

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
                   Jabber ID: tor...@ja...
                                  or http://bronger-jmp.appspot.com

Re: [refbase-talk] Abstracts in RIS

[Chris P. <cdp...@uc...>]

On Thursday 23 July 2009 04:14:55 pm Richard Karnesky wrote:
> Torsten Bronger wrote:
> > In RIS output, abstracts should go into the N2 field rather than the
> > AB field.
>
> This is handled by 'bibutils'.  I can't recall if Chris had a rationale
> for disobeying the (stupidly) written RIS specifation
>   http://www.refman.com/support/risformat_tags_03.asp
> It could be that enough programs use 'AB' instead of 'N2' that it has
> become a quasi-de facto standard; I don't know.  Zotero uses N2 correctly.
>
> refbase could potentially post process RIS or offer native RIS output,
> but we've found that 'bibutils' has intelligent implementation choices
> more often than not.
>
> In refbase, we import 'AB' and 'N2' into the abstract field.  Yes, this
> is an intentional corruption of the RIS spec, but there seems to be MUCH
> more data in the wild that (mis-)uses 'AB' as abstract & very little (if
> any) that uses it (per spec) for notes.

I can't claim to have made a particularly intelligent choice here other than
if I had made a decision and someone complained, I'm likely to have changed
it.

I have both AB _and_ N2 being impored as the abstract (likely due to
examination of lots of sample RIS files people have sent me over
the years) with N1 being set as notes (ristypes.c):

        { "AB", "ABSTRACT",     SIMPLE,  LEVEL_MAIN },
        { "N1", "NOTES",        NOTES,   LEVEL_MAIN },
        { "N2", "ABSTRACT",     SIMPLE,  LEVEL_MAIN },

One thing I did notice is that Bibutils won't do the "right" thing for
references with both AB and N2 tags and will only output one of the
two into the MODS format...I should probably fix that.

I currently output it as AB and not N2 (risout.c):

        output_easy( fp, info, refnum, "ABSTRACT", "AB", -1 );


So the real question for me is:  Is there a consensus on where the abstract
ought to go by default?  (The vast majority of users I suspect are like me
in just needing to switch bibliography format for writing papers and the
like and the AB/N2 subtlety isn't so important.)  The second question is:
Is the other opinion important enough to offer a command-line option
to change the default behavior of Bibutils?  I'm certainly happy to do so
for those users who do care about using AB vs. N2....

On Friday 24 July 2009 12:05:16 am Torsten Bronger wrote:
>
>> > AB is just the same as N1, and since Refbase sets N1 as
>> > well, we have a collision on the importing side.
>>
>> Which program has this collision?
>
> RefDB.

Note that the Oxford Journals actually hide the DOI in the N1
field...  Certainly my understanding is that AB==N2, and N2!=N1.
So this latter issue confuses me.

C.

-- 
Christopher Putnam, Ph.D.
Assistant Investigator, Ludwig Institute For Cancer Research
Adjunct Assistant Professor, UCSD School of Medicine
Cellular and Molecular Medicine East, Room 3019
9500 Gilman Drive
La Jolla, CA 92093-0660 USA

Re: [refbase-talk] Abstracts in RIS

[Torsten B. <br...@ph...>]

Hallöchen!

Richard Karnesky writes:

> Torsten Bronger wrote:
>
>> In RIS output, abstracts should go into the N2 field rather than
>> the AB field.
>
> This is handled by 'bibutils'.  I can't recall if Chris had a
> rationale for disobeying the (stupidly) written RIS specifation
>
>   http://www.refman.com/support/risformat_tags_03.asp
>
> It could be that enough programs use 'AB' instead of 'N2' that it
> has become a quasi-de facto standard; I don't know.  Zotero uses
> N2 correctly.
>
> [...]
>
> In refbase, we import 'AB' and 'N2' into the abstract field.  Yes,
> this is an intentional corruption of the RIS spec, but there seems
> to be MUCH more data in the wild that (mis-)uses 'AB' as abstract
> & very little (if any) that uses it (per spec) for notes.

If Zotero uses N2, as does RefDB, and probably also EndNote (at
least, RefDB's en2ris utility doesn't touch N1, N2, or AB), I'm not
so sure whether sticking to the (admittedly flawed) spec is a bad
idea.

>> AB is just the same as N1, and since Refbase sets N1 as
>> well, we have a collision on the importing side.
>
> Which program has this collision?

RefDB.

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
                   Jabber ID: tor...@ja...
                                  or http://bronger-jmp.appspot.com

Re: [refbase-talk] Abstracts in RIS

[Richard K. <kar...@gm...>]

Torsten Bronger wrote:
> In RIS output, abstracts should go into the N2 field rather than the
> AB field.

This is handled by 'bibutils'.  I can't recall if Chris had a rationale
for disobeying the (stupidly) written RIS specifation
  http://www.refman.com/support/risformat_tags_03.asp
It could be that enough programs use 'AB' instead of 'N2' that it has
become a quasi-de facto standard; I don't know.  Zotero uses N2 correctly.

refbase could potentially post process RIS or offer native RIS output,
but we've found that 'bibutils' has intelligent implementation choices
more often than not.

In refbase, we import 'AB' and 'N2' into the abstract field.  Yes, this
is an intentional corruption of the RIS spec, but there seems to be MUCH
more data in the wild that (mis-)uses 'AB' as abstract & very little (if
any) that uses it (per spec) for notes.


> AB is just the same as N1, and since Refbase sets N1 as
> well, we have a collision on the importing side.

Which program has this collision?

Best,

Rick

[refbase-talk] Abstracts in RIS

[Torsten B. <br...@ph...>]

Hallöchen!

In RIS output, abstracts should go into the N2 field rather than the
AB field.  AB is just the same as N1, and since Refbase sets N1 as
well, we have a collision on the importing side.  (This is just
another quirk of the ridiculous RIS format but there we go.)

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
                   Jabber ID: tor...@ja...
                                  or http://bronger-jmp.appspot.com

Re: [refbase-talk] Umlauts / BibTeX doi field

[Matthias S. <mst...@re...>]

Hi Daniel

On Wed, 17-Jun-2009 17:11 +0200, Daniel Becker wrote:

> >> Somehow, the surnames got abbreviated, but that's for later.
> >
> > See this thread:
> > <https://sourceforge.net/forum/forum.php?thread_id=3234564&forum_id=351913>
> 
> ah, thanks. The mailinglist and this forum are different things,
> right?

They both more or less serve the same purpose, and you're free to use
whatever you prefer.

 <http://support.refbase.net/>

While some users prefer the mailinglist (since the forums require
replying via a web form), the forums seem to get used more frequently
these days. Note that you can also subscribe to the forums and receive
new posts via email.

HTH, Matthias

Re: [refbase-talk] Umlauts / BibTeX doi field

[Daniel B. <dan...@un...>]

Hallo -

[sending Daniel's reply back to the list...]

sorry, this time I hit the right button.

> That's great to hear!

yes, I am really pleased about the look and feel and functionality.

>
>> Somehow, the surnames got abbreviated, but that's for later.
>
> See this thread:
>
> <https://sourceforge.net/forum/forum.php?thread_id=3234564&forum_id=351913 
> >

ah, thanks. The mailinglist and this forum are different things, right?

> While it's always a good idea to check the general tipps given in my
> last mail, I suggest trying to downgrade to Bibutils v3.4.

ok, will try that (tomorrow)

Thanks -

daniel

Re: [refbase-talk] Umlauts / BibTeX doi field

[Matthias S. <mst...@re...>]

Hi Daniel,

[sending Daniel's reply back to the list...]

On Wed, 17-Jun-2009 16:14 +0200, Daniel Becker wrote:

> first of all, I found a workaround for the meantime, until I have
> found the real cause why bib->refbase screws up Umlauts.
> I use bibutils locally and convert to RIS and import that. Seems to
> work.

Ok, glad you've found a workaround.

> So we have a database now with 250 entries to play around with and I
> must say, refbase is really useful & fun.

That's great to hear!

> Somehow, the surnames got abbreviated, but that's for later.

See this thread:

 <https://sourceforge.net/forum/forum.php?thread_id=3234564&forum_id=351913>

> >For some reasons, Bibutils v4.x causes problems for refbase (which
> >I haven't been able to track down yet). So if you're using Bibutils
> >v4.x, please try out Bibutils v3.4 instead:
> >
> ><http://bibutils.refbase.org/>
> >
> >Bibutils v.4.x might be the most likely cause for your import
> >character set issue. Speaking of charset issues, more general
> >info/tipps follow below.
> 
> yes, I am using the most recent version of bibutils. Before I
> downgrade, I'll check the other things. Can't do right now (no
> access ...)

While it's always a good idea to check the general tipps given in my
last mail, I suggest trying to downgrade to Bibutils v3.4.

I just tried both versions again, and I see similar charset issues as
you do when using Bibutils v4.1. Using Bibutils v3.41, everyting seems
to work fine though.

> >>PS: A smaller thing is that an BibTeX-entry Doi = {10.1023/A:
> >>1023355202795} doesn't make it into the doi-field.
> >
> >This is because refbase currently doesn't import BibTeX directly
> >but depends on Bibutils conversion (BibTeX -> MODS XML -> RIS) for
> >import. Unfortunately, the RIS format (which is what refbase gets
> >from Bibutils), has no direct support for the DOI field.
> >
> >Would you be willing to write to the Bibutils developer (Chris
> >Putnam: cdputnam -at- ucsd -dot- edu), asking him about this
> >feature addition? This might increase our chance to get it
> >implemented. Thanks!
> 
> Ok, I see. I will find a workaround for that and I will also write
> to Mr Putnam.

Great, thanks!

> Thanks for your help -
> 
> Daniel

Best regards,

Matthias

Re: [refbase-talk] Umlauts / BibTeX doi field

[Matthias S. <mst...@re...>]

Hi Daniel,

On Wed, 17-Jun-2009 10:52 +0200, Daniel Becker wrote:

> [...] I have a problem with umlauts that I don't understand:
> If you search for "Korhonen", you see that the database contains
> Korhonen, P.J.; SyrjÃ?nen, M.J.
> 
> In BibTeX, I tried both with
> Author = {Korhonen, Pekka J. and Syrjänen, Mikko J.}
> and with
> Author = {Korhonen, Pekka J. and Syrj{\"a}nen, Mikko J.}
> but they both do not work.

These character set issues can be quite tricky.

For some reasons, Bibutils v4.x causes problems for refbase (which I
haven't been able to track down yet). So if you're using Bibutils
v4.x, please try out Bibutils v3.4 instead:

 <http://bibutils.refbase.org/>

Bibutils v.4.x might be the most likely cause for your import
character set issue. Speaking of charset issues, more general
info/tipps follow below.

If you haven't done so already, please checkout this section in the
refbase online documentation:

 <http://www.refbase.net/index.php/Installation-Troubleshooting#Problems_with_special_characters>

Also, have a look at:

 <http://www.refbase.net/index.php/Troubleshooting#MySQL_migration_and_character_set_problems>

and report the SQL output for these MySQL commands:

 SHOW VARIABLES LIKE '%character%';
 SHOW VARIABLES LIKE '%collation%';

If the resulting output contains a mixture of utf8 and latin1, you
might want to try to tweak your server's active 'my.cnf' file.

In the past, I got my local refbase installation running correctly by
setting following two variables in my server's active 'my.cnf' file:

[mysqld]
character_set_server = latin1
collation_server = latin1_general_ci

You might also try to use:

[client]
default-character-set=latin1

See also these threads in the refbase forums:

 <https://sourceforge.net/forum/forum.php?thread_id=2192797&forum_id=218758>
 <https://sourceforge.net/forum/forum.php?thread_id=3098699&forum_id=218758>

> I am using latin1 and ISO-8859-1. Should I consider UTF8? Can that be  
> avoided?

If the Apache+PHP+MySQL+refbase stack has been setup correctly (w.r.t.
character set support), then it shouldn't matter whether you're using
latin1 (ISO-8859-1) or utf8. The utf8 character set just allows you to
enter all characters from the Unicode/UTF-8 character set. But, as
with the latin1-based system, it also needs to be setup correctly.

That said, if you can install a *separate* refbase database for
testing purposes on the same server, try the "utf8" option in
install.php and see if that works better for you.


> PS: A smaller thing is that an BibTeX-entry Doi = {10.1023/A:
> 1023355202795} doesn't make it into the doi-field.

This is because refbase currently doesn't import BibTeX directly but
depends on Bibutils conversion (BibTeX -> MODS XML -> RIS) for import.
Unfortunately, the RIS format (which is what refbase gets from
Bibutils), has no direct support for the DOI field.

> I can transform that into url = {http://dx.doi.org/10.1023/A:1023355202795}
> before importing into refbase. Can this also be configured somewhere
> within refbase?

No, this cannot be configured, sorry.

Some time ago, I wrote to the Bibutils developer asking him to add the
DOI numbers as URLs when converting to RIS (or Endnote):

> Subject:  Bibutils handling of MODS 'identifier' tags of type "pubmed" and "doi"
> From:     re...@ex... (Matthias Steffens)
> To:       cdp...@uc... (Chris Putnam)
> Sent:     Dienstag, 22. Juli 2008 17:05:34 Uhr
> 
> [...]
> it would be very nice if:
> 
> 1. the DOI would be also included in RIS and Endnote output; I'd
>    suggest to simply add the DOI within an additional URL tag (i.e.
>    the DOI prefixed with 'http://dx.doi.org/'). So, in case of RIS,
>    'xml2ris' would add:
> 
>    UR  - http://dx.doi.org/10.1016/S0065-2881(06)51004-1
> 
>    or, in case of Endnote, 'xml2end' would add:
> 
>    %U http://dx.doi.org/10.1016/S0065-2881(06)51004-1
> 
>    IMHO, this would be far better than not including the DOI at all.
>    As an example, refbase will detect any URL that is actually a DOI
>    prefixed with the dx.doi.org resolver, extract the DOI and move
>    it to the right database field.
> [...]

Would you be willing to write to the Bibutils developer (Chris Putnam:
cdputnam -at- ucsd -dot- edu), asking him about this feature addition?
This might increase our chance to get it implemented. Thanks!

HTH,

Matthias

[refbase-talk] Umlauts / BibTeX doi field

[Daniel B. <dan...@un...>]

Hallo,

we started to use refbase at http://www.deabib.org/refbase/

Our workflow is to keep a local BibTeX-file that we then import. I  
tried with a 250 entries test-file and all seems to work smoothly,  
thanks a lot for refbase!

But I have a problem with umlauts that I don't understand:

If you search for "Korhonen", you see that the database contains

Korhonen, P.J.; SyrjÃ?nen, M.J.

In BibTeX, I tried both with
Author = {Korhonen, Pekka J. and Syrjänen, Mikko J.}
and with
Author = {Korhonen, Pekka J. and Syrj{\"a}nen, Mikko J.}
but they both do not work.

I am using latin1 and ISO-8859-1. Should I consider UTF8? Can that be  
avoided?

Thanks for your help -

Daniel


PS: A smaller thing is that an BibTeX-entry Doi = {10.1023/A: 
1023355202795} doesn't make it into the doi-field. I can transform  
that into url = {http://dx.doi.org/10.1023/A:1023355202795} before  
importing into refbase. Can this also be configured somewhere within  
refbase? I guess it has to do with the bibutils-conversion?

Re: [refbase-talk] Publication Date

[Richard K. <kar...@gm...>]

> Have you considered adding this field to the database, or am I missing
> something – maybe it is not a standard field or something – forgive, but I
> haven’t looked into it in any real detail yet.

Yes, it has been considered.  Please see
http://sourceforge.net/forum/message.php?msg_id=5437649 and a few
previous conversations linked there.

--Rick

[refbase-talk] Publication Date

[Adrian J. <aj...@um...>]

Hi Matthias,

 

I just went through the process of wanting  to display the most recently
published papers on our homepage and realized that refbase does not store
the publication date (PD). Obviously I can sort by year and then the serial
or created date, but obviously the year doesn't provide much resolution and
the serial and create date can be in a very different order to the
publication date. Even though it seems that the PD is often/always? Just the
month/year, it would at least be a lot more precise than just the year.

 

Have you considered adding this field to the database, or am I missing
something - maybe it is not a standard field or something - forgive, but I
haven't looked into it in any real detail yet.

 

Thanks,

Adrian

Re: [refbase-talk] self-register-mode

[Daniel B. <dan...@un...>]

> I realize that this is not what you asked for, but for a small to
> medium number of users, it might be an ok workaround.
>
> I'd need to check in more detail what would be required to implement
> your suggested feature.

Hallo Matthias,

thanks for your answer. We will manage without the feature and limit  
accounts to just a few people we know.

I found http://www.learnphponline.com/scripts/email-activation-for-php-forms 
  - I am not a PHP-crack, but maybe it would not be too difficult.

Thanks for your work,

Daniel

Re: [refbase-talk] self-register-mode

[Matthias S. <mst...@re...>]

Hi Daniel,

On Thu, 4-Jun-2009 13:43 +0200, Daniel Becker wrote:
> we ae thinking of using refbase for a bibliography with around 4000
> entries that is currently maintained as a BiBTeX-file.

thanks for your post and your interest in refbase.

> We would like to limit the access to registered users, but the
> barrier should not be too high. So we thought of the self-register
> modus of refbase. My reading of the docs is that there is no check
> at all.

> 1. Fill form with email-address
> 2. wait for email with link
> 3. Only then I can login.

Your suggestion makes sense and, no, there isn't such a feature yet.
That said, it would be nice to support something along these lines.

However, I fear it won't be on the top priority list for the
forseeable future.

How many users do you anticipate registering? Will it really be that
many so that it would pose a major burden to register them manually?

Note that if variable '$addNewUsers' in file 'initialize/ini.inc.php'
is set to "admin", submitting the form at 'user_details.php' will
email the form data to the email address given in variable
'$adminLoginEmail'. This allows users to request an account, but will
leave the actual account creation to the database admin.

I realize that this is not what you asked for, but for a small to
medium number of users, it might be an ok workaround.

I'd need to check in more detail what would be required to implement
your suggested feature.

Matthias