Re: [dev-biblio] My Introduction
Welcome Jatin, It is nice to welcome you onboard. I have sorted today the wiki-categories, see: http://wiki.services.openoffice.org/wiki/Category:Bibliographic 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: http://www.openoffice.org/issues/show_bug.cgi?id=91561 However, you may want to contact: Svante Schubert, see http://lists.oasis-open.org/archives/office/200809/msg00084.html and Oliver-Rainer Wittmann (od), od at openoffice dot org A useful list is also the developer's discussion list: http://www.openoffice.org/servlets/BrowseList?listName=dev Sincerely, Leonard dnw wrote: Jatin, 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 http://wiki.services.openoffice.org/wiki/Bibliographic/Developer_Page We would be pleased to discuss you possible involvement. regards David Wilson --- David N. Wilson Co-Project Lead for the Bibliographic OpenOffice.org Project http://bibliographic.openoffice.org 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 project. 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. cheers! -- Regards, Jatin Linux user #464404 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev-biblio] Hierarchical wiki
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: http://wiki.services.openoffice.org/wiki/Bibliographic_Project/Plugins/ Zotero instead of creating such orphaned pages. Leonard, 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 (http://wiki.services.openoffice.org/wiki/Writer and http://wiki.services.openoffice.org/wiki/Calc), while Tony Galmiche (and others) did an excellent job for the Chart2 wiki (see http://wiki.services.openoffice.org/wiki/Chart2). 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. ;-) ] Sincerely, Leonard regards David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev-biblio] Re: [users-biblio] JabRef - OpenOffice integration
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. Bruce 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. http://wiki.services.openoffice.org/wiki/Zotero_Plugin I strongly suggest moving this page to a new location, something like: http://wiki.services.openoffice.org/wiki/Bibliographic_Project/Plugins/Zotero 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 (http://wiki.services.openoffice.org/wiki/Bib-Keywords), and this makes sense. It becomes much easier to navigate such sites, see e.g. http://wiki.services.openoffice.org/wiki/Writer/ToDo/Layout/Multi_Page_Layout where one easily can navigate back to the top-level Writer page. [http://wiki.services.openoffice.org/wiki/Writer] 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. Sincerely, Leonard regards David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev-biblio] Re: document/collection types
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 http://wiki.services.openoffice.org/wiki/Bib-Keywords (though I largely abandoned that issue due to limited time.) Sincerely, Leonard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: Re: [dev-biblio] document/collection types]
Matthias Steffens wrote: On 30-Jul-07 at 15:37 -0400 Frederick Giasson wrote: Document InternetDocument # I'm [not] convinced we need this as a full type I agree, especially when one considers that in the future a thesis or a report (or whatever) may be published online exclusively. So I think that I'd prefer to have a universal property such as "OnlinePublication" or the like. As I already said on the biblio and zotero mailing list: I think that this should be inferred by the identifier. So, if the identifier is bibo:uri, then we know that its an online resource and that it can be accessible on the Web. So, such a document, is what you would refers to an OnlinePublication. if the identifier is bibo:isbn10, then you know that it is a published document. I may not getting it here, but how would a software then process an item that has both an ISBN identifier as well as an URI identifer that points to an online representation of that document? Generally, what regards inferring any kind of information implicitly (instead of stating it explicitly via a property or the like), it's important to think of real-world scenarios where some information (such as an ISBN number or an URI) may be missing from the user's own metadata for a particular item. Processing logic may fail too easily if too much has to be inferred. ... One small question: many articles are published ahead of print. Do they have an ISBN? Or is the ISBN available only after publishing in written format? Does anyone know more exactly how this EPUB works? Sincerely, Leonard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev-biblio] Re: document/collection types
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 entirely. 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 extenso. 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? Sincerely, Leonard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev-biblio] Re: document/collection types
Hi, 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 on. Maybe if this is stated clearly (I may have missed it, forgive me my ignorance), the solution will look more straightforward. Sincerely, Leonard -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kanns mit allen: http://www.gmx.net/de/go/multimessenger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev-biblio] Re: document/collection types
Hi, without having understood all the comments, let me emphasize some little points which have been probably overlooked. Basically, as pointed in another post, the collections seem to admix medium with document type. 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: A. Peer-Reviewed = This is basically the article and many more standard documents. B. NON-Peer-Reviewed = [Some structure is still needed as I mix medium with document type, too.] 1. Book 2. Periodicals 2.1.Newspaper article (else like an article) 2.2. Non-peer reviewed journal article (else like an article) or Magazine 2.2'. Exclusively Online Journal (non-peer reviewed) 3. Internet page (NOT really like an article) [some peer-reviewed articles are published exclusively on the net, BUT those do NOT fit in this category] 4. Letter (true letter) 5. Personal communication [includes phone/ whatever communication] 6. many other types 6.1 Manuscript 7. Specialized Types 7.1 Court / Law 7.2 Patents QUESTION = Should 'Book'also be split into more categories: a.) non-peer reviewed book (e.g. a novel, single author, whatever else) b.) speciality book with an editor => therefore peer-reviewed c.) anything else NOT easily fitting in the previous 2 categories I will think more thoroughly about the problem tomorrow. Though, recognising the 2 main categories, aka *peer-reviewed* vs *non peer-reviewed*, is critical because every scientist will put so much different weight into these different types of evidence. Sincerely, Leonard Bruce D'Arcus wrote: Frederick Giasson wrote: Hi Bruce, Also, I think we probably need a literal property that allows people to give a little more information when the type itself can't convey it. So this is the hierarchy, with my comments: Collection InternetSite Series Periodical Journal Magazine # we might drop this, or add Newspaper CourtReporter Would drop InternetSite as we dropper WebPage. Am fine with that. So how would we represent a weblog post? Would drop Magazine and not adding Newspaper. In fact, the question is: is there a difference (in terms of descriptiveness) between a newspaper and a journal? or a magazine and a periodical (some type of restrictions applied only to that type of collection). Not really. But the differences are otherwise important (for search, formatting perhaps, etc.). Also, the CourtReporter thing (and all Law documentations related classes and properties) should be re-thinked, extended and possibly put in a specialized (Law) extension module to bibo. What you think? I think we need to provide the basics but provide room for extension. It's just a question of how best to provide those basics. # How to deal with multi-volume books? # I guess could just use generic Collection? Document InternetDocument # I'm convinced we need this as a full type What convinced you? (related to our recent discussion on the bibo mailing list). Oops, typo. I meant to add "not." Article LegalCase # need input from lawyers here; not happy with this Brief Decision As I said above, I would create a module of its own for Law related Things. Manuscript # I suggest dropping Why? It's just an unpublished document, which may be held in an archive. In general, I think people who work with manuscripts would agree with me. Elena, you there? Book # do we need a separate class for edited books? Well, since bibo is rooted at the Manifestation (frbr) level, a Book is not an edited book by definition? I was thinking EditedBook as subclass of Book, though I have no strong opinion if this is a good idea. Am just asking. Proceeding Booklet # I HATE this vestige from BibTeX; let's cut it Let it go then. Manual Legislation # need help here too Patent Report TechnicalReport # is this important? Don't think so. Thesis Dissertation Transcript Interview Note # maybe it shouldn't be a subclass of Document? Well, good question. What it would be? I think that a Note is a document by considering that it is a writing of information. And I think that it should have its own class since it is restricted to a single author. But from the application angle, a note is really different; something like a tag in the sense of user-defined annotation of bibliographic source (documents). So obvious stuff we're missing beyond comments above? No way to indicate letters, memos, phone conversations, etc. Transcript might be problematic. Letters is more problematic. Memos are sort of notes; are they? Phone conversati
Re: [dev-biblio] Re: [sw-discussion] Re: zotero and OOo
Gannon Dick wrote: My favorite: http://dtd.nlm.nih.gov/publishing/coding/citationtags.htm I missed this one, too. There is even more interesting information, e.g. the Journal Tag Library explained, see: http://dtd.nlm.nih.gov/publishing/tag-library/2.2/index.html for the details and also http://dtd.nlm.nih.gov/publishing/index.html 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 (http://wiki.services.openoffice.org/wiki/Bib-Keywords), 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
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' else '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. Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev-biblio] important question
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 Year] (<> means only when needed) 'style 1': [Author ] 'style 2': [Year] 'style 3': [Author , ], 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
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 scheme; -- 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. Regards, Leonard Mada - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev-biblio] important question
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
> 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 results. 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 exclusively): -- 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 endocarditis) --- 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 nightmare. 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.
[dev-biblio] Hierarchical Keyword Tree
Hi, I made some progress regarding the keywords. Unfortunately, I believe that a plain keyword list won't solve much of the current problems; see http://wiki.services.openoffice.org/wiki/Bib-Keywords paragraph 2.2 "Limitations of Current Keyword Strategies" for some reasons why basic keywords are far from adequate. I believe that a solution to this problem could lie in a hierarchical keyword tree. Users would be allowed to create dynamically such a keyword tree (using existing keywords) to enhance the capabilities of the search strategies. See the paragraph 3.1.2 "Hierarchical Keyword Tree" on the same page for a more extended discussion. Because all this is virtually new land, I would like to open a brainstorming session. I would appreciate any comments and suggestions. I come up with another idea regarding the standardisation of keywords. I believe that the ultimate goal is to have standard keywords, too. However, as this will be difficult, a possible solution is to let users specify their own keywords. Have a talk-back feature. Collect used keywords over a period of 1-2 years. And build a list with the most frequently used keywords. These are likely to be used more widely and therefore could be bundled with future versions of OOo. Of course, users could change this list and adapt it further to their specific needs, but it would be a starting point for their own list. Kind regards, Leonard Mada [aka discoleo] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]