refdb-users — List for RefDB users

Re: [Refdb-users] Not reinventing the wheel ...

[Bruce D'A. <bda...@gm...>]

On 11/14/06, Markus Hoenicka <mar...@mh...> wrote:

> The OO bib project (Bruce, correct me if I'm wrong) tries to implement a
> mechanism that allows OO to retrieve cited data through the SRU/SRW
> (http://www.loc.gov/standards/sru/) interface from any database that provides
> such an interface.

Correct.

> This would result in n+m interfaces and is the better
> approach as soon as you're looking at more than two word processors and more
> than two data sources.

Exactly.

Bruce

Re: [Refdb-users] Not reinventing the wheel ...

[<ste...@jo...>]

Markus Hoenicka a =E9crit :
> St=E9phane T=E9letch=E9a <ste...@jo...> was heard to say:
>=20
>> Not sure about the future, but actually it already works with Bibus
>> (that's the reason i've looked towards it).
>>
>> You can get a rather complete description for OpenOffice.org connectio=
n:
>> http://bibus-biblio.sourceforge.net/bibus_doc/html/en/usingOOo.html
>>
>=20
>=20
> As far as I understand the document there are two ways to interact with
> OpenOffice:
>=20
> 1) ODBC
> This simply pulls the data out of a SQL table via ODBC. This requires t=
hat there
> is a 1:1 mapping of the fields that OO expects and the fields in the da=
tabase
> table. RefDB reference databases are relational, that is this simple ma=
pping is
> not going to work.

Right.

> 2) External control of OO through the UNO interface
> Sure you can program OO (and Word, fwiw) using their APIs, but this req=
uires
> each bibliography tool to write one interface per supported word proces=
sor (n
> tools times m word processors makes n*m interfaces).

Right, but that also means you can take advantage of the existing work=20
done in bibus, this is my major argument, in the end.

> The OO bib project (Bruce, correct me if I'm wrong) tries to implement =
a
> mechanism that allows OO to retrieve cited data through the SRU/SRW
> (http://www.loc.gov/standards/sru/) interface from any database that pr=
ovides
> such an interface. This would result in n+m interfaces and is the bette=
r
> approach as soon as you're looking at more than two word processors and=
 more
> than two data sources.

Sorry to not follow you argument but i've been on their mailing list=20
long time ago (around 2002 IIRC) and this feature is *far* from being=20
the priority. We're now close to 2007 and this is still a work in=20
progress. What we need is somthing working for the moment, and may be=20
another implementation later if they provide a better way.

Second that does not solve the Word problem, bibus does.

> regards,
> Markus

I'm not against any idea here, this is just i'm looking for solutions=20
since 2000/2001 and so far, only little pieces are available, nothing=20
integrated.

My suggestions are :

- Take refdb as the backend system (for data manipulation, import,=20
export and mangament),
- use exising code (from refbase) for the php interface since it seems=20
more advanced that what we have in refdb for now, at least this will=20
help both sides i presume
- take the bibus connectors for Word/OpenOffice.org

The problem lies in the compaction of it. Do we need to integrate all in=20
refdb (that would be a must) or let them work flawlessly together (i was=20
thinking of getting a correspondance between tables and/or renaming some)=
 ?

I hope i'm clearer now.

Cheers,

St=E9phane


--=20
St=E9phane T=E9letch=E9a, PhD.                  http://www.steletch.org
Unit=E9 Math=E9matique Informatique et G=E9nome http://migale.jouy.inra.f=
r/mig
INRA, Domaine de Vilvert                  T=E9l : (33) 134 652 891
78352 Jouy-en-Josas cedex, France         Fax : (33) 134 652 901

Re: [Refdb-users] Not reinventing the wheel ...

[Markus H. <mar...@mh...>]

St=E9phane T=E9letch=E9a <ste...@jo...> was heard to say:

> Not sure about the future, but actually it already works with Bibus
> (that's the reason i've looked towards it).
>
> You can get a rather complete description for OpenOffice.org connection=
:
> http://bibus-biblio.sourceforge.net/bibus_doc/html/en/usingOOo.html
>


As far as I understand the document there are two ways to interact with
OpenOffice:

1) ODBC
This simply pulls the data out of a SQL table via ODBC. This requires tha=
t there
is a 1:1 mapping of the fields that OO expects and the fields in the data=
base
table. RefDB reference databases are relational, that is this simple mapp=
ing is
not going to work.

2) External control of OO through the UNO interface
Sure you can program OO (and Word, fwiw) using their APIs, but this requi=
res
each bibliography tool to write one interface per supported word processo=
r (n
tools times m word processors makes n*m interfaces).

The OO bib project (Bruce, correct me if I'm wrong) tries to implement a
mechanism that allows OO to retrieve cited data through the SRU/SRW
(http://www.loc.gov/standards/sru/) interface from any database that prov=
ides
such an interface. This would result in n+m interfaces and is the better
approach as soon as you're looking at more than two word processors and m=
ore
than two data sources.

regards,
Markus

--=20
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

Re: [Refdb-users] Not reinventing the wheel ...

[<ste...@jo...>]

Markus Hoenicka a =E9crit :
> Bruce D'Arcus <bda...@gm...> was heard to say:
>=20
>>> If they indeed settle on CiteProc as a bibliography formatting tool, =
RefDB
>> could
>>> serve as a data source via a SRW interface. This could be written and=
 glued
>> on
>>> in a reasonable amount of time.
>> That's the hope.
>>
>=20
> Is there a list of SRW/SRU features that a data source has to support i=
n order
> to work as a future OpenOffice bib data source? I'd like to focus on th=
at at
> first. It will also help me to decide whether I should make the code pa=
rt of
> refdbd (in C) or use an external server written in Perl which rewrites =
the
> queries.
>=20
> regards,
> Markus
>=20

Not sure about the future, but actually it already works with Bibus=20
(that's the reason i've looked towards it).

You can get a rather complete description for OpenOffice.org connection:
http://bibus-biblio.sourceforge.net/bibus_doc/html/en/usingOOo.html

For Microsoft Word:
http://merrami.com/bibus/BibusGarnerSite.htm#_Toc125789713

Cheers,

St=E9phane

--=20
St=E9phane T=E9letch=E9a, PhD.                  http://www.steletch.org
Unit=E9 Math=E9matique Informatique et G=E9nome http://migale.jouy.inra.f=
r/mig
INRA, Domaine de Vilvert                  T=E9l : (33) 134 652 891
78352 Jouy-en-Josas cedex, France         Fax : (33) 134 652 901

Re: [Refdb-users] Not reinventing the wheel ...

[Markus H. <mar...@mh...>]

Bruce D'Arcus <bda...@gm...> was heard to say:

> > If they indeed settle on CiteProc as a bibliography formatting tool, RefDB
> could
> > serve as a data source via a SRW interface. This could be written and glued
> on
> > in a reasonable amount of time.
>
> That's the hope.
>

Is there a list of SRW/SRU features that a data source has to support in order
to work as a future OpenOffice bib data source? I'd like to focus on that at
first. It will also help me to decide whether I should make the code part of
refdbd (in C) or use an external server written in Perl which rewrites the
queries.

regards,
Markus

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

Re: [Refdb-users] Not reinventing the wheel ...

[Markus H. <mar...@mh...>]

Bruce D'Arcus <bda...@gm...> was heard to say:

> They're mostly focused on sharing PHP code. OSBIB is just that: it
> reads their style files and outputs formatted citations, etc. I agree
> that it's not likely to be very appropriate for RefDB.
>

Sure, but what is the output format? Plain text, HTML, XML, RTF, word processor
documents? I couldn't find anything about that.

regards,
Markus

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

Re: [Refdb-users] Not reinventing the wheel ...

[Bruce D'A. <bda...@gm...>]

On 11/13/06, Markus Hoenicka <mar...@mh...> wrote:

> I'm also unable to find out what their bibliography formatting tool OSBiB
> actually does. Maybe someone can fill me in here. The usual problem is that
> they apparently started yet another bibliographic style language, just like any
> other comparable project (including RefDB) did.

They're mostly focused on sharing PHP code. OSBIB is just that: it
reads their style files and outputs formatted citations, etc. I agree
that it's not likely to be very appropriate for RefDB.

Bruce

Re: [Refdb-users] Not reinventing the wheel ...

[Bruce D'A. <bda...@gm...>]

On 11/13/06, Markus Hoenicka <mar...@mh...> wrote:

> Might be doable, but OpenOffice has a fairly active subproject trying to improve
> bibliography support:
>
> http://bibliographic.openoffice.org/index.html
>
> If they indeed settle on CiteProc as a bibliography formatting tool, RefDB could
> serve as a data source via a SRW interface. This could be written and glued on
> in a reasonable amount of time.

That's the hope.

The Zotero project is planning to add Word (and other) integration,
and I'm trying to get them to do it by adding a standard API within
the word processor. Index Data's Yaz client tool recently added SRU
support, so that would make it pretty easy for different applications
to plug-in to a variety of word-processors (the KWord guys are
thinking about this too).

Microsoft is already adding citation support to Word 2007 (complete
with an API), so it wouldn't make sense to add output support through
the raw XML.

Bruce

Re: [Refdb-users] Not reinventing the wheel ...

[<ste...@jo...>]

St=C3=A9phane T=C3=A9letch=C3=A9a a =C3=A9crit :

> After, bibus can be sued to insert citations into Word, OpenOffice.org.

Please please, read 'used' instead of 'sued' ... (going to the market=20
buying new fingers ...)

--=20
St=C3=A9phane T=C3=A9letch=C3=A9a, PhD.                  http://www.stele=
tch.org
Unit=C3=A9 Math=C3=A9matique Informatique et G=C3=A9nome http://migale.jo=
uy.inra.fr/mig
INRA, Domaine de Vilvert                  T=C3=A9l : (33) 134 652 891
78352 Jouy-en-Josas cedex, France         Fax : (33) 134 652 901

Re: [Refdb-users] Not reinventing the wheel ...

[<ste...@jo...>]

Daniel O'Donnell a =C3=A9crit :
> On Mon, 2006-11-13 at 14:47 +0100, Markus Hoenicka wrote:
>> RefDB is targeted straigth at
>> markup languages, making it vulnerable to criticism pointing out lack =
of support
>> for word processors. I don't know if OSBiB could play a role there, bu=
t I
>> imagine other solutions for that problem (think SRW server).
>=20
> Or, since wordprocessors are becoming more XML based, if it couldn't be
> extended to include them. An idea I had while working on the coding of
> the php this summer--about to be revived--was extending it to cover ope=
n
> office: read the file in, unzip, change, and close back up. I don't kno=
w
> enough about the newer Word formats to say how it might work there.
>=20
> -dan
>=20

Actually, i know a program that does the job '=C3=A0 la endnote', multi=20
platform, multi word processor, bibus.

http://bibus-biblio.sourceforge.net/wiki/index.php/Main_Page

I've not checked extensively, but in coordination with refdb, the goal=20
was to set up a working refdb repository and allow bibus to use it=20
(instead of its own mysql db).

After, bibus can be sued to insert citations into Word, OpenOffice.org.

But some coding is needing, and i'm lacking two major ressources:
- good coding skills
- time ...

Cheers,

St=C3=A9phane


--=20
St=C3=A9phane T=C3=A9letch=C3=A9a, PhD.                  http://www.stele=
tch.org
Unit=C3=A9 Math=C3=A9matique Informatique et G=C3=A9nome http://migale.jo=
uy.inra.fr/mig
INRA, Domaine de Vilvert                  T=C3=A9l : (33) 134 652 891
78352 Jouy-en-Josas cedex, France         Fax : (33) 134 652 901

Re: [Refdb-users] Not reinventing the wheel ...

[Markus H. <mar...@mh...>]

Daniel O'Donnell <dan...@ul...> was heard to say:

> Or, since wordprocessors are becoming more XML based, if it couldn't be
> extended to include them. An idea I had while working on the coding of
> the php this summer--about to be revived--was extending it to cover open

                       ^^^^^^^^^^^^^^^^^^^^ oh yes please

> office: read the file in, unzip, change, and close back up. I don't know
> enough about the newer Word formats to say how it might work there.
>

Might be doable, but OpenOffice has a fairly active subproject trying to improve
bibliography support:

http://bibliographic.openoffice.org/index.html

If they indeed settle on CiteProc as a bibliography formatting tool, RefDB could
serve as a data source via a SRW interface. This could be written and glued on
in a reasonable amount of time.

As far as Word XML is concerned, the stuff must be awful - see a comparison
here:

http://www.groklaw.net/article.php?story=20051125144611543

I've seen in another story that M$ is proud of being able to encode all approx.
400 possibilities to render a frame border in Word, but this comes at a price -
MSXML is not readable for humans, and accordingly hard to program for.

regards,
Markus

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

Re: [Refdb-users] Not reinventing the wheel ...

[Daniel O'D. <dan...@ul...>]

On Mon, 2006-11-13 at 14:47 +0100, Markus Hoenicka wrote:
> RefDB is targeted straigth at
> markup languages, making it vulnerable to criticism pointing out lack of support
> for word processors. I don't know if OSBiB could play a role there, but I
> imagine other solutions for that problem (think SRW server).

Or, since wordprocessors are becoming more XML based, if it couldn't be
extended to include them. An idea I had while working on the coding of
the php this summer--about to be revived--was extending it to cover open
office: read the file in, unzip, change, and close back up. I don't know
enough about the newer Word formats to say how it might work there.

-dan

> 
> regards,
> Markus
> 
> 
> Stéphane Téletchéa <ste...@jo...> was heard to say:
> 
> > During my packaging work, i did also a package for refdb, a web-based
> > bibliographic project based on a mysql engine.
> >
> > They developped a common interface in php for formatting and
> > transforming data, Bibliophiile: http://bibliophile.sourceforge.net/
> >
> > I was wondering if by chance, this could help refdb project.
> >
> 
> 

Re: [Refdb-users] Not reinventing the wheel ...

[Markus H. <mar...@mh...>]

Hi,

not reinventing the wheel was one of the goals of RefDB, so I tried to re=
use
whatever was available out there. E.g. RefDB only includes bibliographic =
data
conversion utilities that I either need myself :-) or that were requested=
,
usually because nothing else was available for a particular task. refdb-m=
ode
integrates bibutils
(http://www.scripps.edu/~cdputnam/software/bibutils/bibutils.html) to con=
vert
to and from a variety of formats not supported directly by RefDB. The
documentation of bibliophile on the web is a little sparse, so I can't te=
ll if
they offer something which is not covered by these tools yet.

I'm also unable to find out what their bibliography formatting tool OSBiB
actually does. Maybe someone can fill me in here. The usual problem is th=
at
they apparently started yet another bibliographic style language, just li=
ke any
other comparable project (including RefDB) did. Integrating OSBiB support=
 into
RefDB means having two incompatible style languages around. I'd like to k=
now
what output document types their engine supports. RefDB is targeted strai=
gth at
markup languages, making it vulnerable to criticism pointing out lack of =
support
for word processors. I don't know if OSBiB could play a role there, but I
imagine other solutions for that problem (think SRW server).

regards,
Markus


St=E9phane T=E9letch=E9a <ste...@jo...> was heard to say:

> During my packaging work, i did also a package for refdb, a web-based
> bibliographic project based on a mysql engine.
>
> They developped a common interface in php for formatting and
> transforming data, Bibliophiile: http://bibliophile.sourceforge.net/
>
> I was wondering if by chance, this could help refdb project.
>


--=20
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

Re: [Refdb-users] Not reinventing the wheel ...

[<ste...@jo...>]

David Nebauer a =E9crit :
> Hi St=E9phane,
>> During my packaging work, i did also a package for refdb, a web-based=20
>> bibliographic project based on a mysql engine.
>>
>> They developped a common interface in php for formatting and=20
>> transforming data, Bibliophiile: http://bibliophile.sourceforge.net/
>>
>> I was wondering if by chance, this could help refdb project.
>=20
>=20
> I'm not sure I understand your post.  Are you sure you meant to type=20
> "refdb" in the first sentence?  Is refdb a web-based bibliographic=20
> project based on a mysql engine?  While refdb has a distributed=20
> architecture, is it really web-based?  And mysql is just one of three=20
> available engines.  I also wasn't aware Markus developed a common=20
> interface in php for formatting and transforming data called=20
> "Bibliophile".  According to bibliophile's website that project was=20
> founded by Mark Grimshaw, Matthias Steffens and Daniel Pozzi.
>=20
> Regards,
> David.

Argh, i meant refbase, of course, stupid fingers ...

Of course, refdb is more robust to me, but i thought some=20
programes/ideas could be taken by Markus (and others).

i'll try to pay more attention next time and to furnish some more example=
s.

Cheers,
St=E9phane

--=20
St=E9phane T=E9letch=E9a, PhD.                  http://www.steletch.org
Unit=E9 Math=E9matique Informatique et G=E9nome http://migale.jouy.inra.f=
r/mig
INRA, Domaine de Vilvert                  T=E9l : (33) 134 652 891
78352 Jouy-en-Josas cedex, France         Fax : (33) 134 652 901

Re: [Refdb-users] Not reinventing the wheel ...

[David N. <dav...@sw...>]

Hi St=E9phane,
> During my packaging work, i did also a package for refdb, a web-based=20
> bibliographic project based on a mysql engine.
>
> They developped a common interface in php for formatting and=20
> transforming data, Bibliophiile: http://bibliophile.sourceforge.net/
>
> I was wondering if by chance, this could help refdb project.


I'm not sure I understand your post.  Are you sure you meant to type=20
"refdb" in the first sentence?  Is refdb a web-based bibliographic=20
project based on a mysql engine?  While refdb has a distributed=20
architecture, is it really web-based?  And mysql is just one of three=20
available engines.  I also wasn't aware Markus developed a common=20
interface in php for formatting and transforming data called=20
"Bibliophile".  According to bibliophile's website that project was=20
founded by Mark Grimshaw, Matthias Steffens and Daniel Pozzi.

Regards,
David.

[Refdb-users] Not reinventing the wheel ...

[<ste...@jo...>]

During my packaging work, i did also a package for refdb, a web-based=20
bibliographic project based on a mysql engine.

They developped a common interface in php for formatting and=20
transforming data, Bibliophiile: http://bibliophile.sourceforge.net/

I was wondering if by chance, this could help refdb project.

Cheers,

St=E9phane
--=20
St=E9phane T=E9letch=E9a, PhD.                  http://www.steletch.org
Unit=E9 Math=E9matique Informatique et G=E9nome http://migale.jouy.inra.f=
r/mig
INRA, Domaine de Vilvert                  T=E9l : (33) 134 652 891
78352 Jouy-en-Josas cedex, France         Fax : (33) 134 652 901

Re: [Refdb-users] ANN: Debian (pre-)release refdb packages at version 0.9.8-pre8

[<ste...@jo...>]

David Nebauer a =E9crit :
> The debian (pre-)release refdb repository has been updated with package=
s=20
> based on version 0.9.8-pre8.
>=20
> Regards,
> David.
>=20

RPM for Mandriva can be found on the cooker devel branch in your usual=20
repository. If there's a need, i'll do some backports for 2007 and 2006.

For instance you can find refdb at:
http://distrib-coffee.ipsl.jussieu.fr/pub/linux/MandrivaLinux/devel/cooke=
r/cooker/media/contrib/release/

Cheers,

St=E9phane

--=20
St=E9phane T=E9letch=E9a, PhD.                  http://www.steletch.org
Unit=E9 Math=E9matique Informatique et G=E9nome http://migale.jouy.inra.f=
r/mig
INRA, Domaine de Vilvert                  T=E9l : (33) 134 652 891
78352 Jouy-en-Josas cedex, France         Fax : (33) 134 652 901

[Refdb-users] ANN: Debian (pre-)release refdb packages at version 0.9.8-pre8

[David N. <dav...@sw...>]

The debian (pre-)release refdb repository has been updated with packages 
based on version 0.9.8-pre8.

Regards,
David.

[Refdb-users] ANN: Debian svn refdb packages at revision 224

[David N. <dav...@sw...>]

The Debian svn refdb repository has been updated with packages based on 
revision 224.

Regards,
David.

[Refdb-users] ANN: refdb-0.9.8-pre8 available

[Markus H. <mar...@mh...>]

Hi all,

it is almost too embarrassing to mention, but pre7 also caused a build error on
other boxes than mine. I've fixed this problem, built a package, transferred it
to a Cygwin box, and built it successfully. I can't build the docs on Cygwin
though, so I keep my fingers crossed that I didn't screw up anything in the
docs.

I'm sorry for the constant confusion. I need a build manager.

regards,
Markus

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

[Refdb-users] ANN: refdb-0.9.8-pre7 available

[Markus H. <mar...@mh...>]

Hi all,

a small but annoying build problem on non-BSD systems (see bug report
#1593311) made a quick bugfix prerelease necessary. Please forget
about pre6 and download pre7 at:

http://refdb.sourceforge.net/pre/refdb-latest.tar.gz

Besides the new features mentioned in the announcement of pre6, the
following issues were fixed:

- bug #1593394: the new archive now contains a non-empty Changelog

- bug #1584361: the refdb-init script was rewritten to make use of refdbd's
  new maintenance capabilities. This obsoletes the dump file check
  which was the cause of the problem in this bug report.

regards,
Markus

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

[Refdb-users] ANN: refdb-0.9.8-pre6 available

[Markus H. <mar...@mh...>]

Hi all,

I've finished the work on the dupcheck branch and merged the result
back into the main line of refdb development. The result is a new
prerelease (built from svn revision 216) which you can grab right here
as usual:

http://refdb.sourceforge.net/pre/refdb-latest.tar.gz

There are two new features that make this prerelease worth a try:

1) Duplicate checks

refdbc received an additional command called checkref. The syntax is
very similar to the addref and updateref commands. In contrast to
these commands, checkref will add the reference data to temporary
tables. You can safely throw data at your database and see what
happens without running the risk of altering your existing data. In
addition to the output of addref which tells you whether or not the
data were added successfully, checkref will create a report of a
variety of duplicate checks. The format of the report can be selected
with the -A switch. "scrn" will return a text-only report, whereas
"xhtml" creates a more elaborate report viewable with your favourite
web browser. Moving around your mouse will pop up tooltips that try to
explain what to do with the match data. An example output can be
viewed here:

http://refdb.sourceforge.net/checkref.html

checkref tries to find duplicates of references by comparing the
titles, the location (journal name, volume, issue, start page for
journal, newspaper, and magazine articles), and the citation key.

checkref also tries to find similar author names, journal names, and
keywords. These matches are not primarily targeted at detecting
reference duplicates, but to give you a chance to keep your database
tidy and consistent. Typical cases are author names which are spelled
out in one reference but use abbreviated first and middle names in
another reference. If you can verify that the authors are identical,
you can expand the abbreviated name to the more useful spelled-out
name. Along the same lines, you can make sure that an abbreviated and
a full journal name are mapped to the same journal in the
database. Likewise, the keyword lists will help you to identify
similar existing keywords which may or may not be more appropriate
than the ones in the new reference.


2) Frequency data

RefDB can now help you to get a different view of your reference
databases. The getau, geted, getas, getjo, getjf, getj1, getj2, and
getkw commands of refdbc now support a "-s format" switch that lets
you request additional frequency information. "-s freq" will list the
absolute number of references that use the given authors, journals, or
keywords requested with the command. "-s relfreq" displays a relative
frequency indicator as an integer between 0 and 10 along with the
listed values. The formula used to calculate the relative frequency is
likely to require some more thought, and I'll be happy to receive
advice from people more apt in math than me.

The frequency data are even more fun with the (x)html output of the
getref command (this even works with the xhtml output of the new
checkref command). The relative frequency data are translated into
font size and color used to display the values, similar to the tag
clouds of del.icio.us and the like. Large author names or journal
names indicate that these authors or journals are represented above
average in your database. Likewise, a reference containing large and
red keywords is a "mainstream" article, dealing with the most
frequently listed issues in your database. A reference containing only
small and blue keywords would be considered less important in terms of
your average interests. Try this example output:

http://refdb.sourceforge.net/getref-frequency.html

To get the frequency display in the xhtml output, use the "-s KW"
switch of the getref command to add the keyword list to the output,
and the "-G /usr/local/share/refdb/css/refdb-frequency.css" switch to
select the new stylesheet that takes the frequency information into
account (you can make both settings permanent in your
~/.refdbcrc). The refdb.css stylesheet displays the references as in
the previous versions.

Both new features are likely to require some further polish. Please do
not hesitate to send your ideas and rants to the list.

regards,
Markus

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

Re: [Refdb-users] iconv-error with encoding of mysql-database

[Markus H. <mar...@mh...>]

Dominik Reusser writes:
 > Hi Markus,
 > here is the input data. I ended up converting the database encoding to UTF-8 
 > and got the data imported that way. 
 > I hope you can reproduce the error.
 > 

I suspect there is a configuration problem on your end. file says
about your input data:

ISO-8859 English text, with very long lines

The file contains a couple of characters outside the ASCII range. Now
if your RefDB installation is set up to expect the input RIS data
being UTF-8 (this has been the default for a while), then it is quite
possible that libiconv complains about unexpected character sequences.

Your options:

- set up RefDB to use ISO-8859-1 for incoming RIS data by setting the
  fromencoding variable in refdbcrc appropriately

- use the -E ISO-8859-1 option with addref to specify the encoding on
  the command line

- convert your input data to UTF-8 using iconv before adding them to
  RefDB

- if you insist on having a ISO-8859-1 database, you need to configure
  refdbd as well. You need to set both db_encoding and in_encoding in
  refdbdrc to ISO-8859-1

I've noticed another problem with your input data which is entirely
unrelated. The author names use a format which RefDB cannot digest,
and quite a few authors lack the first names. As you enquired about
bib2ris in the past, I suspect the bad quality of the input data has a
lot to do with that tool. If this is the case, I'd like to have a look
at your bibtex input data too in order to improve bib2ris.

regards,
Markus

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

Re: [Refdb-users] bib2ris INPROCEEDINGS

[Dominik R. <dre...@un...>]

Am Monday, 30. October 2006 22:22 schrieb Markus Hoenicka:
> Hi,
>
> there is no such reason except my ignorance. I've been struggling
> quite a bit with the bibtex to RIS mapping, and it is very well
> possible that I didn't get some things right yet.
>
> bibtex uses both PROCEEDINGS and INPROCEEDINGS. I figured the former
> describes a whole tome of papers presented at some meeting, similar to
> a book.

I agree on this

> The latter would then be a chapter (or an article?) that=20
> appeared in such a tome.=20

To me it is more an article than a chapter. But maybe, others have a differ=
ent=20
opinion? So I will change the settings in bib2risrc.=20

> I'm still not sure what the RIS type CONF is=20
> supposed to cover. If it is meant to describe the "book", then the
> current mapping is ok. If CONF is meant to describe a chapter, then
> INPROCEEDINGS should rather map to CONF, and PROCEEDINGS maybe to
> BOOK.

As I'm not really familiar with the RIS types, maybe somebody could clarify=
=20
this point.

Regeards
Dominik
>
> As I'm not an active bibtex user, I'm open to suggestions how to
> improve the default mapping. In any case, if you don't like the
> default mapping, you can customize it in
> /usr/local/etc/refdb/bib2risrc.
>
> regards
> Markus
>
> Dominik Reusser writes:
>  > If converting conference proceeding entries from bibtex (INPROCEEDINGS)
>  > to ris, the type is set to
>  > TY  - CHAP
>  > is there a reason for not setting it to
>  > TY - CONF

=2D-=20
Dominik Reusser
Universit=E4t Potsdam

Re: [Refdb-users] Using user-defined "numbering"/abbrevs in citations for docbook

[Markus H. <mar...@mh...>]

Hi,

Olivier Berger writes:
 > Hi.
 > 
 > FYI, I've updated my webpages using the new CITEKEY citation format :
 > http://www-inf.int-evry.fr/~olberger/publications/publications.html
 > 

Cool.

 > It seems to work quite well, unless I can't get bold font for the
 > citation keys... but maybe because I'm using refdb mixed with docbook
 > xml and qui a number of dirty hacks to get everything together...
 > 

I'll see whether there is a fundamental problem with formatting the
citation keys. If not, I'd also suspect some unexpected interaction
between the various stylesheets.

 > Now, what's missing is documentation, for instance on :
 > http://refdb.sourceforge.net/citestylex/index.html ;)
 > 

Will do.

Markus

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