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]
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]
[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: 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
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: [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
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 needed) '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
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
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.
