Re: [dev-biblio] My Introduction

2008-09-27 Thread Leonard Mada

Welcome Jatin,

It is nice to welcome you onboard.

I have sorted today the wiki-categories, see:

So, there are some interesting pages out there, although the project was 
quiet in the last month. [I was quiet a little bit longer, but hopefully 
things will start to move again.]

One requirement is the new metadata, and it seems the implementation is 
progressing, too, see:

However, you may want to contact:
Svante Schubert, see

Oliver-Rainer Wittmann (od), od at openoffice dot org

A useful list is also the developer's discussion list:



dnw wrote:


The bibliographic project has been stalled for some months because 
we have not had any volunteer programmers to work on the project. We 
would be delighted if you could make a contribution.

The most useful activity you could do at this time would be to work 
with the Zotero team to fix the Zotero plugin/ extension for 
OpenOffice version 3. And to modify the extension to support the new 
bibliographic metadata being built into OOo 3.
Other possible tasks are explained at

We would be pleased to discuss you possible involvement.


David Wilson

David N. Wilson
Co-Project Lead for the Bibliographic Project

Jatin Vij wrote:

Hi all ,

This project seems to be an excellent way forward for OOo !
As an MS student , I have grappled constantly with the problems caused
by a lack of well designed bibliographic tool in OOo. Having
familiarized myself with the project vision and outline , I feel no
reservation in offering my support and programming skill to this

About me : I have a Bachelors degree in Computer Science and Engineering
and about to finish my MS in CS with Software Engineering as my
concentration. I love good design and make liberal use of whiteboards. I
follow a very by-the-book orthodox programming style and believe in
clear concise comments. Amongst other things , I consider myself a
competent programmer in C++ and Java.
I look forward to making a meaningful contribution to this work.


Linux user #464404

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev-biblio] Re: [users-biblio] JabRef - OpenOffice integration

2007-12-08 Thread Leonard Mada

Hi all,

David Wilson wrote:

On Thu, 6 Dec 2007, Bruce D'Arcus wrote:

So I'd like to see if we can work with developers from Zotero, JabRef,
etc. to enhance that baseline support. If out that some other
developer start to build the integrated tool we originally envisioned,
that's great. But I don't think we can depend on that panning out. And
in any case, as I say, it's not an either/or choice; just a question
of immediate priorities.


As a start, I have set up a wiki page to assist in the managing of Zotero 
plugin issues. There is not much there yet and I invite interested people to 
add to it.

I strongly suggest moving this page to a new location, something like:

instead of creating such orphaned pages.

All bibliographic wiki-pages should be ultimately moved below the 
top-level page 'Bibliographic_Project'.

I hope nobody gets annoyed by this quibbling about the wiki-structure. 
As you know, I am rather focused on the hierarchical organisation of 
data  (, and this 
makes sense. It becomes much easier to navigate such sites, see e.g. 
where one easily can navigate back to the top-level Writer page. 

I hope therefore, that all project leads will enforce this style and 
improve existing wikis by moving orphaned pages below the top-level 
project's wiki-page.





To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[dev-biblio] Hierarchical wiki

2007-12-08 Thread Leonard Mada

Hi David,

David Wilson wrote:

On Sun, 9 Dec 2007, Leonard Mada wrote:

I strongly suggest moving this page to a new location, something like:
Zotero instead of creating such orphaned pages.


	Thanks for the suggestion. When I started the wiki pages I just copied 
what most other people were doing - which was a flat file structure with any 
hierarchy built using category links.

I can see there advantages in moving to a hierarchical directory organisation. 
Are there any objections to my restructuring the wiki pages in this way ?

No objections from me. Actually, I strongly encourage it. I already did 
some work on the Writer and Calc pages 
( and, while Tony Galmiche (and 
others) did an excellent job for the Chart2 wiki (see

There is still a lot to do, but if every project lead enforces this 
style for his project, then things will only improve. I remember when I 
first come to OOo: it was genuine luck to find any useful information. 
So I hope these were past times and newbies will fare nowadays better. 
[My biggest problem is the very limited time, otherwise I would have 
moved much more pages around. ;-) ]




To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev-biblio] Re: document/collection types

2007-07-31 Thread Leonard Mada

on another note, I have some questions regarding the following scenario:

Lets consider someone wants to review some movies (or some other AV-material). 
[e.g. Roger Ebert wants to write a new movie guide ;-) ]

How does he cite the movies?

Should a special Audio-Video category exist? As more content moves to the 
internet, as there are many shifts in existing technologies (mobile devices), 
shouldn't we look a little bit more open-minded to these changes.

Is it worth trying to unify everything, or does is make sense to split things 
into the classical published media (virtually most bibliographies up to 2007 
fits here), and newer technologies (well, probably most will fit someday in 
this category)?

I still haven't read all the comments, so I need some time to think more 
thoroughly about the proposals.

Maybe a last question (though I apologise if it sounds dumb): what is the 
primary purpose of this category? Because for citing purposes, I really need 
details like edited book vs one-author book, web-page vs other document, and so 

Maybe if this is stated clearly (I may have missed it, forgive me my 
ignorance), the solution will look more straightforward.


Pt! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen:

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev-biblio] Re: document/collection types

2007-07-31 Thread Leonard Mada

Bruce D'Arcus wrote:

Leonard Mada wrote:


Regarding document type, there are broadly 2 large categories of 
documents, and therefore I am strongly against some of the droppibngs:

A. Peer-Reviewed Documents
B. NON-Peer-Reviewed Documents

So, you cannot mix everything in the article category, there are 
really different things:

This is an interesting argument, though I'm not sure I agree with you 

A. Peer-Reviewed
This is basically the article and many more standard documents.

Books are often peer-reviewed also, as are conference presentations 
(you submit an abstract and can only present if approved by a 
committee). This suggests it's a property rather than a type.


Well, an editor sees the book, but a peer-reviewed article is definitely 
on a different level of scrutiny. Conference presentations are probably 
still another step lower, thats why high impact meta-analysis don't use 
abstracts from conferences. They wait for the article to be published in 

In general, I consider an article peer-reviewed, if it is  in a journal 
I know to publish peer-reviewed articles (this definition might be not 
always correct, but it is practical). And even here, Nature and Science 
will fare better than some lower-impact journal.

Indeed, if peer-review is a property, it could be probably inferred from 
the journal (in most cases). If there is a site with the journals impact 
points, we could even infer something about the quality (and impact of 
the article, although  only on average, and not necessarily for the 
specific article).

My real concern is, that, if the category 'document' is set too large, 
so that everything fits in it, than what is the purpose of this category?



To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev-biblio] Re: document/collection types

2007-07-31 Thread Leonard Mada

Gannon Dick wrote:

Had to put my 2 cents here ...

Leonard, very good point but might it be better to use Evidence Basis
(ala' Evidence Based Medicine, Evidence Based Health Care, Evidence
Based Librarianship, etc.) as a Property of the resource no matter what
form or source the resource takes ?

Well, it actually boils down to a peer-reviewed article. If it was 
peer-reviewed, it is likely to be evidence based. If not, most likely it 
isn't solid evidence.

A meta-analysis (of properly conducted studies) is the  highest level of 
evidence. Then follows a properly conducted randomized trial and so on 
(see the Cohrane database). I have posted such a category tree on the 
OOo site some time ago, see (though I largely 
abandoned that issue due to limited time.)



To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev-biblio] Re: [sw-discussion] Re: zotero and OOo

2007-02-16 Thread Leonard Mada

Gannon Dick wrote:

My favorite:

I missed this one, too. There is even more interesting information, e.g. 
the Journal Tag Library explained, see: for the 
details and also for further informations.

It seems that there is even a category *article-type*, one of the things 
that I have advocated on the wiki page 
(, though some 
types are NOT as much expanded as in my version; especially the *trials* 
subtypes are lacking:

   * randomized controlled trial
   * Meta-analysis
   * other trial

This is interesting information, surely very useful for the Bib project.

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev-biblio] important question

2007-01-30 Thread Leonard Mada
In my previous post, I have suggested a different approach to the 
current problem. What do you think of it?

Instead of having flags for every citation field, I suggested:
- have styles for citations
- AND allow more than one citation styles in the same document
  -- styles are set globally (therefore, IF one decides to change a 
style, he changes all citations at once; with flags he would have had to 
change every one singly)
  -- it would be difficult to construct wildly different styles 
(something NOT easily done with flags)
  -- and the formatting code would be more simple, because there are 
NOT plenty of flags and exceptions to deal with; a new style is simply a 
new style, created by the same formatting engine;

for example:
'default style' for citation: [Author et al. Year] ( means only when 

'style 1': [Author et al.]
'style 2': [Year]
'style 3': [Author et al., number], IF author has more than one 
papers in the same year


We would set for every citation a style. IF NO style set, OOo should 
assume default.

What do you think of it?

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev-biblio] important question

2007-01-30 Thread Leonard Mada

Bruce D'Arcus wrote:

But this all can get very tricky to deal with, particularly when you
consider things like substitution logic (what happens when there's no
author?), first/subsequent citations, and so forth. I worry how adding
this flexibility would impact implementations.

1. first/ subsequent citations - internal index variable
Lifescience citations are often of the form [number], but I believe it 
is intelligent to have always an internal index, storing the citation 
number. This could be accessed to detect IF citation is first, is last, 
or there are more citations following.

2. implement simple conditional formatting in the styling engine, like
if('some condition')
  'write this IF true'
   'write this IF condition FLASE')

[could be written as a shorthand IF('condition', 'do-this-IF-TRUE', 
'do-this-IF-FALSE') ]

= therefore:
if(!'AuthorVar') Anonymous else 'AuthorVar'

These should be defined by the styles and NOT dealt automatically as 
very complex formatting logic.

Similarly, we could see if an author name has already been used, using a 
conditional logic, and output ibid. IF that is the case.

Of course, everything should be done transparently by OOo Writer. There 
is NO need for flags AND also NO need for any major changes in ODF. 
(Actually I do not see the need for any change in ODF.)

The only changes would be in Writer: to accept styles for citations AND 
to have a very flexible and powerful formatting engine. Yes, this last 
issue will need some intelligent design, but I am sure it is doable.

Requirements for the style formatter:
1. variables
 - index: %ii (internal index, in the order of appearance of the 
citation), %ri (reference index, in order of appearance in the reference 
list; this list could be sorted alphabetically, so %ii != %ri)
 - various entries: %a (Author Name), %ae (Author et al.), %ia 
(Initials + Name), %ai (Name, Initials)
   %y (year), %id (number, IF author has more than one paper 
published during the same year, else %id is not set)

   ... others (e.g. %c - citation as a whole)
2. conditional logic:
 - if('condition', 'TRUE-statement', 'FALSE-statement')
 - ifexist('condition', 'TRUE-condition', 'FALSE-condition'): e.g., IF 
citation already defined previously
 - if( (%ii-1)-'Author' == 'Author', ibidem., 'Author'): have access 
to previous entries

Well, I will be thinking more thoroughly during the next days, but I 
believe this is the way to go.


To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev-biblio] important question

2007-01-29 Thread Leonard Mada
I took a brainstorming session today on this issue and I would like to 
add some of my thinking to this discussion:

- I now believe that flags are a less than optimal idea
 -- they add to much complexity (many flags necessary to do something 
more complex)
 -- they limit the things that could be done only to those for which 
flags do exist, and only in a pre-specified way
 -- every reference has to be set individually, and, most important, 
wishing to change the formatting has to be done on all those references 
(there is NO mechanism to do it globally)

e.g. in the medical literature, references are often cited as a 
superscript number (as [2], or simply 2, but superscript).
Now consider the following sentence: Further details can be found in 
reference 2. We need another flag to specify that 2 is NOT superscript, 
and another that it is NOT enclosed in brackets (IF the initial format 
would have been [2]).

The problem gets more complex if more than one reference are cited. e.g. 
Further details can be found in references 2, 3 and 4. This could have 
been represented as (superscript) 2, 3, 4 or 2-4 (of course with/ w/o 
brackets and various other combinations).

What I think is necessary is a *more flexible way* to cover various 
coding possibilities. Flags just don't seem the right solution.

*My Vision of a flexible Solution*
Instead of coding flags, I would propose to have one byte (or a global 
flag) that stores the class name (or number) of the *formatting scheme*. 
In other words:

- allow the text to contain more than one formatting schemes
- NO formatting scheme flag set (or class set to 0): use the default, 
the master formatting

- allow user to define additional formatting schemes, like:
  -- scheme 1: drop author:: [year]
  -- scheme 2: drop year, allow chapter: (Author in chapter)
  -- these schemes should be fully customizable, exactly as the default 

  -- so these schemes are much more powerful than the flag-options
  -- they are stored globally, too, so the user does NOT need to view 
every reference IF he decides to change later the formatting BUT can do 
it globally, in a very flexible way

I also believe, this is more easy to implement. NO extra flags, just 
additional styles. The style engine becomes more simple.

Just my thoughts. And of course provide a field 'caption', IF the user 
wants to manually change the text to be displayed. This field will store 
that text, and, as long there is text in this field, this text will be 
displayed inside the document. Automatic updating is NO longer possible, 
BUT OOo Writer could identify any entries that have changed, so the user 
can manually change them again.


Leonard Mada

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev-biblio] important question

2007-01-28 Thread Leonard Mada

Bruce D'Arcus wrote:
Ahem, just to be clear, I mean *locally.* E.g. I don't see why the 
global configuration of a style says the citation should be (Doe, 
1999), and we have to allow users to be able to have some citations be 
(Doe:1999), *and* to remain live and updateable.

However, IF a user wants some very fancy formatting (like 1999; Doe), 
here is a nice way to allow this without breaking to much everything else:
have a field 'caption' where the *full text is stored*, the way it 
should be displayed;
- if the user wants to update this entry, he should be able to select to 
overwrite it with the default new entry, and then manually perform the 
customization; the modified text gets stored as a caption, again

- while this needs rewriting the caption, it has 3 main advantages:
 -- it is still linked to the bibliography (so that OOo can show IF any 
change has occured)

 -- it does NOT need dozens of flags and other weird options
 -- virtually every format can be easily coded using this method
- IF the base entry has changed, OOo Writer could mark this caption, so 
the user can check IF he has to manually change the caption (and 
eventually import the changed bibliographic entry as described previously)

Just my thoughts.

Leonard Mada

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[dev-biblio] Hierarchical Keyword Tree

2006-09-29 Thread Leonard Mada

 German Schlagwort vs Stichwort
I do not know if there is an English equivalent for the two terms. I 
believe you have in English only keywords, which are actually 
Stichwoerter. Schlagwoerter would be some kind of keywords, too 
(like used in Indices), but there is no distinction between the two, as 
far as I know.

What I want is an amalgam of both, and even more than that. Simple 
keywords are to primitive and do not offer the wanted advantages when 
you want to search something. e.g. I recently searched for the term 
febrile neutropenia on Pubmed and retrieved 1883 search results. This 
search was not the most sensitive, though. Searching for febrile and 
neutropenia yields 3500 results. Searching for fever and 
neutropenia results in 3283 hits.

As the sensitivity of the search increases, so drops the specificity. 
Most of those documents would have been useless for me. And by the way, 
febrile neutropenia is not such a common term. If you search for 
something common, you would have one-two orders of magnitude more search 

There is definitively the need for something better, and I believe a 
form of hierarchical keywords (or tags) could offer some relief, but 
there is definitely need for a more thorough thought on this subject.

As I described on the wiki page: the endocarditis example (infection of 
heart valves)
- in endocarditis heart valves are most often infected (but not 

 -- so most of the time endocarditis implies heart valves, too
 -- I may want sometime to search more extensively for heart valves; 
the option would be to:

 -- add heart valves as a keyword to every article on endocarditis;
   --- but the keyword list would become very fast a huge list (because 
I would have to enter other terms as well, like cardiology, various 
bacteria and many more)
   --- many terms can be selectively used on some articles, so applying 
them indiscriminately will result in a severe loss of specificity for 
the search:
   --- e.g.: most endocarditis causes bacteremia (bacteria in the 
blood), yet not all
   --- bacteremia can also cause endocarditis (i.e. be the reason for 
   --- however I would add bacteremia as a keyword only when 
specifically studied in the article (to maintain a high specificity)
   --- yet for a more general search on bacteremia, I would include 
endocarditis, too, in my search protocol
   --- of course, the search could often be done without that 
hierarchical tree, by manually including all the search strings in the 
query, but the query would look odd and be difficult to understand (and 
many users wouldn't be able even to write it correctly); you would easy 
forget to include some indirect search term;
- to expand your example: Nonfiction - Guidebooks - Cooking - Asian 
meals: I may want to specifically search for 'Asian meals'; another time 
for Cooking (including Asian meals) and still another time !!only!! for 
'Guidebooks' (excluding books on Cooking or any other specific 
'Guide'-book, i.e. generally on guidebooks). To expand it on 
endocarditis: I may want to search on endocarditis or infection 
(including endocarditis and other infections), or more generally 
articles dealing broadly with infections (but not with specific 
infections, like endocarditis).

 Stichworte are not usually stored hierarchically
- see comment on sensitivity vs specificity: adding every possible 
keyword to the list would make these lists huge,

- reduce the specificity, and
- it would be notoriously cumbersome to physically add all those 
keywords to the list (and not to forget one)

I believe that hierarchical keyword lists/ trees could offer a very 
powerful mechanism for such searches (because one would be able to 
dynamically change the tree structure to be best suited for the 
particular search).

Also, this way you do not have always to remember every keyword (tag) 
that should be included in the tree (the tree is simply there; no user 
would create for every new search a new, very different tree; rather, 
most trees would be used for a number of searches, and a new tree would 
most often be a tweek of a previous tree, not a de novo invention).

I have over 2500 articles on my PC. They are arranged hierarchically in 
subdirectories. The problem is:

- articles may belong to more than one directory (aka category)
 -- I would like to have more than one tree for my articles, but you 
can't do this on a filesystem
- I need sometime searches on more than one subdirectory from different 
directory trees (this is indeed difficult to do on a file system)
- there are many other limitations, but currently its the best method 
to organise so many articles

When you have so many articles, the organization of them becomes a real 

I believe that hierarchical keywords are a good start (!!and I do not 
have any better idea right know!!). Therefore, I believe that a little 
brainstorming would be quite useful.