Re: [dev-biblio] Re: Re: Re: Re: Draft document - Wordprocessor Enhancements for Bibliographic Support.

[Bruce D'Arcus]

On Jan 15, 2005, at 9:30 PM, Mat~{('~}j Cepl wrote:
I have no idea. If "see also" is the only possible extension (and I am
afraid it is not), then somewhere to the area "Text before", "Text 
after",
add another box "See also", which would be equivalent (albeit possibly
smaller) of "Selected" and it would allow pushing some keys into it 
from
the main "Available" listbox. What about that?
I'm not sure it's best to start with a GUI frontend to BibTeX as a 
model, since we're not bound to follow BibTeX.  As a simple example, my 
XSLT stylesheets currently group and sort author/year combinations and 
handle the shortening of, for example (Doe, 1999a; Doe, 1999b) to (Doe, 
1999a, b).  So, I imagine a user being able to drag-and-drop multiple 
citations onto the document, and for them to be properly formatted 
without intervention.

2) Doe argues X, Y, Z (1999a, b; 2000)
Just push particular citation keys (with "left arrow" icon) from
"Available"
listbox into the "Selected" one. Particular formatting is matter of
BibTeX .bst (and/or LaTeX) styles.
How does the system know to leave off the author name(s) on the
reference?
Sorry, I am not with you?
I missed that you had originally attached a screen shot.
What's the question? Possibly if you use some real
example with real books, it may be more obvious?
I'm a publishing scholar, and the example above comes from my own 
experience.  It is a sentence in which the author name is printed 
in-text, and is separated from the citation markers by a string of 
text.

There are two options I can envision:
1)  user drops citations where they want them.  They then bring up a 
dialog box that presents the citations.  User selects each one in turn 
and clicks an option to render as "year only."

2)  rendering is all automatic; if author name precedes a citation 
within the sentence, it gets shortened.

1 is tedious for the user, but 2 is complex to code, and potentially 
error-prone.

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

Re: [dev-biblio] Re: Re: Re: Re: Draft document - Wordprocessor Enhancements for Bibliographic Support.

[Bruce D'Arcus]

Oh, the other possibility is that captions for citations get inserted 
inline in the document, instead of via dialog.

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

Re: [dev-biblio] Re: Re: Re: Draft document - Wordprocessor Enhancements for Bibliographic Support.

[Bruce D'Arcus]

On Jan 15, 2005, at 8:28 PM, Florian Schlichting wrote:
No, I think we should stick to a "Text before" and "Text after" field
PER SELECTED CITATION KEY (in the GUI) and not standardize the (myriad)
ways in which to refer to and comment on citations (or who is
misunderstanding whom now?)
I don't have a really strong opinion as yet.  However, "see" and "see 
also" references are really common not just in citations, but in all 
manner of reference linking.  TEI actually has structures for this.  
Just because BibTeX and Endnote don't do it doesn't mean we shouldn't 
at least consider it.

One of the problems with the free text approach is that it actually 
becomes more complicated in some ways.  For example, if we explicitly 
support "see" and "see also" linking, it means that grouping takes it 
into account.  So, you automatically get (Doe, 1999, 2000; see also 
Jones 1998; Smith 2000).

The last two references are "see also" references.  If you say all 
captioning is free text, then you're left with the problem of how to 
handle text associated with groups.

I don't really like the way endnote does this, that you have to do two
separate steps (first insert, then edit the citation) to perform this
very basic formatting - it should all be in the same initial window.
Perhaps it would still be feasible, however, to dispense with the 
window altogether, and just use direct editing and contextual menus?  I 
think it's worth considering at least.

Also, endnote does apparently not offer the possibility to leave off
brackets entirely (for example if you're already inside brackets,
writing more extensive text)
Am not quite following here.  What do you have in mind?
Bruce
PS - Yes, the list stuff is flakey.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev-biblio] Free Text in citations & cross-references

[Bruce D'Arcus]

On Jan 16, 2005, at 6:45 PM, David N. Wilson wrote:
1) According to Doe, "X, Y, Z" (1999:23; see also 2000).
This situation also applies to to footnote citations which I have used.
Right.
This form has several issues to consider. I take it that "X, Y, Z" is 
any
free text describing Doe's argument. If it is 'free text' that is 
normal
text, it can be any length, any number of pages.
In this case, I am assuming it's a few words.  In my experience, a 
citation generally only leaves off the author name if the author is 
listed within the same sentence.

In the case of "According to Doe, "X, Y, Z" (1999:23; see also 2000)." 
When
the cursor is over the first part of the citation 'Doe' you we could 
have a
context menu option 'Jump to end of Citation" which would place you at 
the
"(1999:23; see also 2000)" part.
First point is that it's not clear that "Doe" here must be coded as a 
citation per se.  It could just be free text without explicit coding.  
This is sort of design decisions that we need to carefully consider 
though.

But how are you thinking about the details above?  "X, Y, Z" becomes an 
inline caption?

Another issue: when you select "Doe" and press the delete key does "X, 
Y, Z"
get deleted as well as the  "(1999:23; see also 2000)" bit?
That depends on above.
Perhaps an option would be to treat the displaced "Doe" as a 
cross-reference
field representing the Author of citation  Doe,1999:23. Thus changing 
the
citation will change the name. The cross-reference would have to 
protected in
some way as if it was deleted you would left with a citation (1999:23) 
with
no author name shown in the text. Or fix it auto-magically if the
cross-reference name is deleted the citation reverts to (Doe,1999:23).

Thinking about this -  cross-references to the fields in citations 
could be
useful. The User could have full access to all the data in the 
citations,
including abstracts etc. to insert in the text.
I guess I'd vote for keeping things as simple as possible.  If we can 
keep it simple and add useful new functionality, then great.

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

Re: [dev-biblio] Re: [xbiblio-devel] multibib design question

[Bruce D'Arcus]

On Jan 21, 2005, at 4:41 PM, David N. Wilson wrote:
Would this be for cases like this - I have a journal article which has
considerable detail about a legal case including the full text of the 
law and
trail transcript etc.
It would be normally formated in the citation (footnote or intext) and
bibliography as a journal article. But because of its special nature I 
would
like it treated as if it was a direct reference to a 'Legal Case'  ?
I'm talking about a situation where you having something like this in 
the reference list, with grouping indicated via indenting for clarity:

References
Archival Documents
Doe v. Smith (1978) ...
Jones v. Abel (1967) ...
Secondary Sources
Doe, J (1999) ...
This may well be something to worry about implementing later, but I'd 
like to at least think about it now.

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

[dev-biblio] more on XML DBs, SRW/U and CQL

[Bruce D'Arcus]

Forward from Rob Sanderson.  He tried to post it, but it's not gone 
through.

(Rob Sanderson, member of Biblio project, main editor for SRW, 
University of Liverpool, Computer Science Dept)

The main issue, in my opinion, is one of abstraction (isn't it always?)
We do not want the end user to have to understand the incredibly 
complex table structure required to implement MODS in SQL.  We do not 
even want the -developers- to have to understand this.  Instead we want 
to be able to use off the shelf, easy to understand technology to get 
records in XML, save them and later perform operations on them.

This is easiest to accomplish using an XML record store system rather 
than constantly shredding the document into SQL tables and rebuilding 
it.

In the information retrieval world, the current standard protocol for 
remote search and retrieve of any XML documents is SRW.  The query 
language for SRW is abstract (called CQL) -- for example you use an 
abstract 'title' search rather than XQuery's syntax specific approach.
For the purposes of the Bibliographic project, the entire Library of 
Congress database is available in MODS format for free via SRW/CQL.

If we download and store those records in a relational table of any 
complexity, then every time there is a change to the schema, the tables 
need to be rebuilt. This would consume a lot of time and effort, rather 
than possibly having to change an XPath value.
The only thing that is certain in this world is change.

To use an OOo centric example, if documents were stored in a relational 
database and an element's content model in the schema changed, we would 
have a nightmare situation. In an XML database with appropriate schema 
version metadata, this is almost trivial.

Hope this makes sense,
-- Rob Sanderson
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev-biblio] more on XML DBs, SRW/U and CQL

[Bruce D'Arcus]

On Jan 25, 2005, at 11:36 AM, Bruce D'Arcus wrote:
Forward from Rob Sanderson.  He tried to post it, but it's not gone 
through.
Nevermind.  Went to the wrong address, and it got where it needed to go 
finally anyway.

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

Re: [dev-biblio] Re: [Issue 42029] New - Superscripts and subscripts in the bibliography

[Bruce D'Arcus]

On Feb 4, 2005, at 1:04 AM, David N. Wilson wrote:
It raises some interesting problems on how to implement all possible 
font
formating options into titles and other fields.
Yeah, and it's a huge PITA :-)
I'm going to continue lobbying the LoC to allow some kind of additional 
markup in title fields, but it may be difficult because it can be a 
can-of-worms (e.g. why not just allow MathML?).

If/when we do this, I want to do it right (using semantic tagging; not 
crap like bold and italic).

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

[dev-biblio] [Fwd: Bibutils version 3.14]

[Bruce D'Arcus]

FYI. Perhaps someone with some more technical background than I (in 
C/C++) might take a look at Chris' ideas on making Bibutils into a 
library?  This could be quite important to the both OOoBib, and the 
evolution of free bib software.

Bruce
--- Begin Message ---

A new 3.14 release of bibutils is available:

http://www.scripps.edu/~cdputnam/software/bibutils


New from 3.12  (see 
http://www.scripps.edu/~cdputnam/software/bibutils/v3hist.html)

1.  The programs have a change in their default behavior.  I had, at
Bruce D'Arcus's request, added a default mangling of id based on which
reference it was.  However, many people, including myself, didn't
like the change.  This is now optional and needs to be turned on with
"-a" or "--add-refcount" command line option.  Additionally, with this
option on, files written by "-s" or "--single-refperfile" are properly named.

1.  copac2xml was written to convert copac format references.

2.  isi2xml has bug fixes to handle multi-author references and multi-keyword
references.

3.  end2xml has various bug fixes, including an important one where the 
reference type information was being lost (this was occuring at least from 
3.12 and possibly earlier).

4.  bib2xml now handles url entries 

5.  Some internal code reorganization that reduced code duplication
will aid in my library development (see below) and adding new formats 
for input/output.


Future:

The big change that's coming (and 3.14 is a small step towards it) is
reorganizing the code into libraries to help people plug this code into
their programs.  And as this always seems to happen, this code was
never written with this in mind, so I have a little bit of work to get there.

The core functions people will use will be like:

The bibliography being passed around is essentially a list of all references
broken down into tag/data/level triplets appropriate for my output services.
(The level bit allows for the recursive nesting of MODS XML.)  This
C struct needs to be initialized (as I'm not programming in C++ and can't
use a constructor):

void bibl_init( bibl *bin );

There will be a single function to call to read in the references.  This
function will handle which functions to use for reading/processing the
raw data.  (Internally done with function pointers--this is one of the major
steps done in 3.14 in preparation for the library generation.  There are
a couple of twists/optimizations to add to 3.14 that are clear now that
I've converted things this far.)  The mode will be one of BIBL_MODSIN,
BIBL_BIBTEXIN, BIBL_COPACIN, BIBL_ENDNOTEIN, BIBL_ISIIN, 
BIBL_RISIN, BIBL_MEDIN (for the moment).  The bibliography that
is outputted will always be in UTF8-encoded Unicode with all 
appropriate cleanups (e.g. LaTeX stuff in BibTeX) performed. 
Passed parameters are essentially giving command line information
regarding character sets and the like.  Setting to NULL will let
everything be returned in a default mode.  (I'm also considering a
flag to allow the raw tag/data from the file to be returned...the 3.14
code actually builds these things, and someone could use this
library to directly read BibTeX or RIS or the like if they wanted...they
just won't be able to nicely output it using my writing code, however...)

int bibl_read( bibl *b, FILE *fp, int mode, bibl_param *p ); 

The output will be just as simple, with modes of BIBL_MODSOUT,
BIBL_BIBTEXOUT, BIBL_ENDNOTEOUT, BIBL_RISOUT (currently).

int bibl_write( bibl *b, FILE *fp, int mode, bibl_param *p );

And of course, the C-version of a destructor to clean up memory
usage:

void bibl_free( bibl *b );

So bib2xml will look something like:

int
main( int argc, char *argv[] )
{
 bibl_param p;
 bibl b;
 int err;
 bibl_init( &b );
 bibl_initparams( &p, &argc, &argv );
 for ( i=1; i--- End Message ---
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev-biblio] CSL mockup

[Bruce D'Arcus]

James Howison wrote:
This is a start.  I think what we need (and I don't know how to do it), 
especially for the punctuation part, is a "live" update using a citation 
entered by the user (or populated by the interface), showing what 
difference a change would make.
It's possible to do that in html using the xml-httprequest stuff. Some 
high-profile examples that use the technology are gmail, flickr, and the 
new ta-da list.

Any ideas how one might implement that (it could have "try it" button 
that feeds the style sheet and the citation (MODSXML?) to a web-service 
and returns an xhtml formatted citation?  
Sure. CiteProc is a web service (the XSLT processor communicates with 
the database over HTTP), so it would be fairly simple to allow previewing.

Probably in a (dreaded) pop up window?
I don't think that's necessary with xml-httprequest. See here for an 
example:

http://developer.apple.com/internet/webcontent/XMLHttpRequestExample/example.html
Bruce
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev-biblio] MODS as RDF?

[Bruce D'Arcus]

Hi James:
James Howison wrote:
Is there a representation of MODS (the xml) thing as RDF? 
No.
And is there a way to do that that also includes Bruce's addition of 
annotation to MODS records 
()
Probably.  I've chatted with Alf Eaton about that.
However, there is no ready-made RDF equivalent to MODS.  I'd say the 
closest would be PRISM, but it's handling of names is problematic. 
Perhaps a combination of that, but substituting FOAF for the 
representation of agents?

Am cc-ing a few people who know much more about RDF than I, and might 
have some thoughts.

I'm asking because I've made some progress in my often postponed quest  
to get metadata inside academic papers

thanks to a hacky combination of the latex commands
\includexmp
\includepdf
and bib2xml (to create the xml file to include) I can get MODS xml  
inside a PDF document.

and then use the perl regex:
m/id='W5M0MpCehiHzreSzNTczkc9d'.*\?>(.*?)<\?xpacket/sg
to pull it back out again.
(Before I broke the install I used to babble about this here: which I  
babbled on about here .  The  
point is to make managing academic papers like managing MP3, download a  
PDF, drop it on your citation management software and have the metadata  
automatically entered for you.)

But since XMP is meant to be RDF it would be better to store it in  
there as RDF, right?  My assumption is that if it is in RDF then the  
Adobe etc tools can display the metadata (but since I don't have those  
tools I don't really know!)  So how?

Is my thinking at all correct?
My sense is yes.  But I also think that more than just Adobe needs to 
make use of XMP for it to be really useful.

Obviously once this works with old PDFs we should be able to do it with  
PDFs created within open office :)

--James
US Cell: +1 315 395 4056
Full Contact Details on VCard:
http://freelancepropaganda.com/jameshowison.vcf
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

Re: [dev-biblio] OO bibtex import filter

[Bruce D'Arcus]

On Feb 16, 2005, at 3:56 AM, Pierre Martineau wrote:
to transform Bibtex to RIS, PubMed or Refer then import it in Bibus
(which uses the OOo database format - enhanced of course -).
One thing to keep in mind, though:
RIS and Refer are both richer data formats than either BibTeX or the 
BibTeX-based OpenOffice (and yes, Bibus).

Depending on what type of records you have, you may lose data.  If you 
have any legal sources, for example, they'll just end up as 
"miscellaneous" types.

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

Re: [dev-biblio] Re: [Issue 42029] New - Superscripts and subscripts in the bibliogr

[Bruce D'Arcus]

Pierre Girard wrote:
I'm going to continue lobbying the LoC to allow some kind of 
additional markup in title fields, but it may be difficult because it 
can be a can-of-worms (e.g. why not just allow MathML?).
My question is why not support mathml instead of just hand selecting 
some of the features?  I understand that it will be harder for you to 
implement but at least that's a well known standard albeit not widely 
spread.

You see, my problem is that where i work professors write papers that 
sometimes contains some mathematics in the title.  Usually nothing too 
fancy, for instance (in latex) $H_\infty$. However in the abstracts we 
have some more complicated math in there.

Could you please take that into consideration?
Yes, I understand that. It's just that it's hard to convince, for 
example, the Library of Congress to support MathML markup in their 
schema, and I'm not interested in writing a new one except as a very 
last resort.

I have some ideas about how to address this, but I'm just emphasizing that:
a)  it's not an easy problem to solve, particularly if you care about 
interoperability

b)  I care a lot about interoperability
Bruce
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev-biblio] Re: [Issue 42029] New - Superscripts and subscripts in the bibliogr

[Bruce D'Arcus]

Also, does OO.o have support for MathML?
Bruce
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev-biblio] Re: [Issue 42029] New - Superscripts and subscripts in the bibliogr

[Bruce D'Arcus]

On Feb 17, 2005, at 9:16 AM, Pierre Girard wrote:
b)  I care a lot about interoperability
What is interoperability?  The ability to interchange data between 
different bibliography applications?
Yes, and legacy data, including that which comes from the world of 
online catalogs and such.  Notwithstanding BibTeX, most available 
bibliographic data is stored in MARC, and a fair bit in RIS and Refer.

I'm all for interroperability but not necessarely at the price of 
evolution.
Absolutely agreed.  But evolution -- it is my argument -- is 
necessarily tied to interoperability.  We live in a networked 
distributed world, and anything we do needs to take that into account.

I argued to the LoC they ought to allow any content in certain MODS 
fields, which would include MathML.  However, as soon as you allow 
that, it means that software has to be able to process that content or 
the data is meaningless.

What i'm asking is not even evolution, bibtex has been doing math in 
titles for a very long time although it has other flaws.
I constantly complain about BibTeX, but if you do math, I think it's 
going to be the best solution until MathML is widely used.

I realize that i'm probably the only person that asked for this 
feature so far and i understand that it most likely won't be a 
priority but i didn't have much to lose by asking for it especially at 
an early development stage.
And it's appreciated.  What you want is similar to what others have 
asked for.  It's just going to take some time to figure it out and get 
it implemented.

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

Re: [dev-biblio] OpenDocument, MODS and Remaining Issues

[Bruce D'Arcus]

On Feb 17, 2005, at 9:59 AM, Bruce D'Arcus wrote:
I'm not sure I've ever given a larger perspective on a lot of the 
issues I raise on this list, so let me do that now.
Just to be clear, I sent this to the MODS list, and cc-ed here.
Bruce
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev-biblio] funding development

[Bruce D'Arcus]

On Feb 17, 2005, at 10:37 AM, Matthew Yates wrote:
I cannot write the grant myself (I am not a developer
and do not know a lot about the openoffice.org
organization).  However, I do have experience writing
grants and would be willing to give advice and/or edit
a proposal if anyone is interested.  It is a lot of
work to write a good one, but I think there is a
strong possibility of getting funding.  The proposal
can be submitted by virtually anyone in the U.S. I
think.  It is open to universities, non-profit
institutions, government organizations, for-profit
institutions, and individuals.
This is not a bad idea.  I'm in the U.S.  When's the deadline?  My 
time's really short for the next couple months.

If I did do it, I'd need a lot of help.
Bruce
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[dev-biblio] API (ZOOM)

[Bruce D'Arcus]

I've been having some off-list conversation that I thought I'd move 
here. Rob Sanderson, Mike Taylor (of Index Data) and I have been 
chatting about the details of the interface we want to propose for OOo. 
Here's an initial stab (subtly edited based on comments from Mike) that 
Rob wrote. I still don't quite understand the details of how we'd get 
XSLT-based formatting integrated here, but have the sense this will work.

=
In order to support a common interface to databases, both local and
remote, for the purposes of the bibliographic utilities in OpenOffice,
a single API implemented within OO and exposed as UNO objects would
allow for various front ends to be put in place as well as
automatically switching between different back ends without changing
functions.
As bibliographic records are not similar to SQL query results, even if
the data is stored in a relational database, we need to look for
existing standardised and supported APIs to integrate. The primary API
in the bibliographic domain that fits this is 'ZOOM': Z39.50 Object
Orientation Model (http://zoom.z3950.org) It is abstract, but has both
C++ and Java bindings and implementations available under open source
licenses.
It has a simple model, but one that is flexible enough to be
appropriate for many different database engines. It was designed in
particular for Z39.50 (and more recently applied to SRW) but would also
work for local datastores such as eXist with only a very simple layer
to act as an interface.
ZOOM defines four primary object classes:
Connection:   A connection to a database manager
Query:A query to be sent to the database manager
ResultSet:The results of a search query (an ordered list of
Records)
Record:   An item within a ResultSet
A sample usage: [Which should probably be translated to C++]
conn = Connection('z3950.loc.gov', 7090)
conn.databaseName = 'voyager'
q = Query('PQF', '@attr 1=4 @attr 2=3 "computer"')
results = conn.search(q)
for rec in results:
 print rec.get_data()
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev-biblio] www resources - citation

[Bruce D'Arcus]

On Feb 18, 2005, at 5:29 PM, Jozef Riha wrote:
i tried different approaches but was not successful. any ideas, hints?
Maybe a wiki language?
Bruce
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev-biblio] Request for comments on GUI architectural design

[Bruce D'Arcus]

Hi Martha,
Nice job!
Let me just address your listed questions for now:
• What types of item metadata and content can be stored in a BibDB? 
Pretty much anything I suppose. I think the initial focus ought to be 
bibliographic entries and annotations related to them.

• What are the types of searchable sources? 
I think this and the next two are for Rob and Matthew, but in general I 
think there are two kinds of connections:

1) those to explicit OOoBib compatible servers, where those server are 
the source of formatting-ready metadata

In the traditional Endnote sort of application, this is just your local 
bibliographic database, but because of our focus on a unified 
local/remote query approach, it would easily be a remote connection to a 
multi-user setup (say for a workgroup or department)

2) those which are more about finding and retrieving records for use in 
1; accessing your library catalog for example

• What are the acceptable query parameters?
From a user experience POV, there should be a brain-dead simpl 
google-mode. I should have easy and instant access to my entire 
database, without need to switch to another screen or mode.

• How will result sets will be handled (e.g., stored as file or 
searched with a refined search)? 

• What styles are to be implemented in OOoBib Version 1? 
If we support CSL, then as many styles as people are able to write. If 
we can manage to integrate this stuff, which styles and how many is a 
trivial manner to address.

The core styles that are essential are stuff like APA, MLA, Chicago, etc.
• Which of the five types of insertions will be implemented in Version 1? 
First, let me clarify something: why the distinction between "reference" 
and "list of references"?

From my perspective, the latter would always be automatically 
generated, so why would I want to insert a single reference? It seems 
like it would make the GUI more complicated.

Anyway, in order or priority, I'd say:
citaton and reference list
text (you mean stuff like quotes here?)
graphics
Bruce
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev-biblio] Request for comments on GUI architectural design

[Bruce D'Arcus]

Matthias Basler wrote:
What types of item metadata and content can be stored in a BibDB?
 

Bruce wrote:
 

Pretty much anything I suppose.
   

In my personal opinion I see a some issues when things like abstracts or other
rather large "content" is stored in the BibDB. This will make the database
voluminous, which is especially a topic when parts of the database are to be
stored in (and shared with) the document.
 

Let me explain how I'm tending to think of this:
Annotations should be stored separately from the records per se, for 
three reasons:

1)  they can be really lengthy in some cases (for me, pages)
2)  they can often contain sensitive information (research notes) that 
one may not want to distribute

3)  it offers more flexibility (say you want to link a note to multiple 
records)

I see no such problems for abstracts, and so believe they can and should 
be stored as part of the main record.

BTW, the above structure could lead to some interesting possiblities 
around syndicating bibliographic data.  See, for example, this blog post 
of mine:

http://netapps.muohio.edu/blogs/darcusb/darcusb/archives/2005/01/27/atom-and-mods
The "public" data to which Martha refers would basically be the data 
that you'd be willing to let the world see in this context.

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

[dev-biblio] Re: [users-biblio] Re: [dev-biblio] Request for comments on GUI architectural design

[Bruce D'Arcus]

On Feb 23, 2005, at 4:21 PM, Bruce D'Arcus wrote:
BTW, the above structure could lead to some interesting possiblities 
around syndicating bibliographic data.
For those that may not know anything about Atom or syndicating:
You know RSS?  You subscribe to weblogs and news sites and such, and 
new content just shows up in your newsreader?  Firefox and Thunderbird 
both support it.

Well, the same thing could happen with bib records.  Atom is a new 
alternative to RSS.  So, say you know ten colleagues.  You subscribe to 
their feeds to see what they're reading, and what they have to say 
about it.  You can then import those records into your bib database 
(assuming some sort of simple scripting).

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

Re: [dev-biblio] Formula's in titles ?

[Bruce D'Arcus]

On Feb 24, 2005, at 12:32 AM, David Wilson wrote:
We would actually like to be able to use all the text formating 
options, bold, italic, underlining, super and subscripts, as well as 
formulas.
I'd like to just add something an aside that I'll continue to harp on 
to the OOo community:

We need to stop trying to recreate bad ideas from 20 years ago, and 
really exploit the power of XML and semantic markup.

To wit, bold and italic and superscripts ought to be deprecated across 
the board in OOo, and character (and paragraph) styles much more 
strongly promoted.

The practical issue for bibliographies and titles is the difference 
between this:

	Some Title Within a 
Title

... and this:
Some Title Within a Title
The second is information poor and completely inflexible.  When you 
generalize that approach to an entire GUI, you encourage users to 
create documents that are similarly limited.

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

[dev-biblio] Re: [users-biblio] Re: [dev-biblio] Request for comments on GUI architectural design

[Bruce D'Arcus]

On Feb 24, 2005, at 12:44 AM, Julian Blanc wrote:
For an implementation of an approximation to Bruce's syndication idea, 
see
Connotea, new online web reference sharing system developed by Nature 
(the
scientific journal): http://www.connotea.org/
Cool; I'd not seen that.
Ingenta also is making it's article metadata available via the same bib 
standard the Nature people are using (PRISM), and are looking at MODS 
too (the guy that wrote the stuff for Ingenta reads my blog).

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

[dev-biblio] Re: [users-biblio] Initial comments on OOoBib UI Architectural Design 2.0

[Bruce D'Arcus]

On Feb 24, 2005, at 5:15 AM, Van-Couvering,EJ (pgr) wrote:
First, I take it from the design docs that we propose, in phase one, 
to only allow access to OoBib from within OoWriter.  I would like to 
urge that we rethink that decision and somehow allow the database GUI 
to be opened standalone.  I have two main reasons for this: 
     1) I personally very often work with the database of my thesis 
notes without any reference document in mind, and it wouldn't make 
sense to me to have to open a document (which I won't use) to get 
access to those notes.  Also because I'm paranoid about my notes, I'd 
like to be SURE they will be there for me if I have to use another 
word-processor.  I really don't like the feeling of lock-in this 
proposal gives me. 
     2) EndNote and the other bibliographic programs are rather 
expensive - about £70 now ($135) student prices at my institution.  
One of my reasons for wanting to help out on this project is to 
provide an alternative in terms of price - but many people can't 
switch word processors because of institutional reasons (like, we are 
barred from installing programs), so it would be nice to be able to 
give them something they can use.  I bet the IS people would consider 
an alternate bib program before they would switch from Word.  
Especially if we can add an IMPORT function, which I didn't see 
anywhere.
This is a tricky issue.  We are planning that the database itself be 
independent of OOo, and to use a standard interface that would allow it 
to be used elsewhere.

In principle, I prefer the idea that GUI for managing references (as 
opposed to the citations in the document).  In practice, we may have 
some technical challenges (how to code the GUI to be independent).

In the document GUI "style" element (p9), we say "A style must be 
selected before the first insertion is made."  I think we should have 
a default style, and the user should then be able to change the style 
in the document -- in other words, styles shouldn't be fixed for a 
particular document. 
Right.
I think the BibDB should contain ALL the information, and that there 
should be a default setting about what subset is included as the 
"travelling library" (to borrow an EndNote term) with the document.  
The travelling library contents should be able to be changed by the 
author of the document, and the travelling library ought to be able to 
be exported into a proper BibDB by the reader of the document. 
All fine, except the part about "be able to be changed."  I think 
that'd be difficult to manage.

BibDB (p14) - "a major issues is whether a document can contain 
insertions from more than one BibDB" Yes, please  I have a range 
of databases more or less categorised by subject (sort of ), and I 
would like to be able to access them all, not to have to go through 
some cumbersome cut-and-paste process to be able to insert a reference 
I already have.
I'm going to throw out a strong contrary opinion, in the interest of 
debate.

If you have more than one database for different subjects, then this is 
because your application is not a very good database application.  If 
searching is easy and efficient, and storage robust, why should you 
need more than one database?

I have 1,500 records (that used to be in Endnote) in an XML database.  
I often accidentally find stuff I didn't know I needed because the 
searching functionality is simply much better than in Endnote.

And if you allow more than one database, how are you and your 
formatting processor going to know where the bibliographic records are?

Regarding indexes (p15) "Will OOoBib queries allow the use of any type 
of controlled vocabular(ies?), such as LCSH or MeSH?" 
I say this is v2 stuff, because it adds another layer of complexity.
Can we arrange it so that we have a default type of search, but that 
we can make some type of configurable search interface so that 
particular sources can have different types of controlled or 
uncontrolled searches?  For example, we could define a generic 
"bibliographic database" search which included author, title, date, 
and subject, but eliminate subject from databases that don't work that 
way?
I'm personally of the opinion that we need to learn not from library 
databases here, but from Google.  The basic search field should work 
exactly like Google.  I should just be able to type:

"political theory" Foucault
... and get the documents I need.  The same logic ought to work for 
inserting citations.

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

Re: [dev-biblio] Request for comments on GUI architectural design

[Bruce D'Arcus]

On Feb 23, 2005, at 4:07 PM, Matthias Basler wrote:
Bruce wrote:
[...] Why the distinction between "reference" and "list of 
references"?
As far as I interpret it, reference for her means a sort of 
footnote/endnote
citation in contrast to her "inline citation" (see page 12). But I may 
be
wrong.
I'm not sure, but I see no need for this distinction.  A footnote 
citation is just a citation.  Indeed, the new internal citation coding 
understands a footnoted citation as a footnote *within* a citation, 
rather than vice versa.

And I don't think we should think in terms of allowing users to insert 
individual references; rather, they should (at least at some point) be 
able to insert citation that do not display in the text.  In BibTeX, 
it's the nocite command.

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

Re: [dev-biblio] Re: [users-biblio] Initial comments on OOoBib UI Architectural Design 2.0

[Bruce D'Arcus]

On Feb 24, 2005, at 8:55 AM, Dr Robert Sanderson wrote:
Web searches are looking for data that you do not know.  One presumes 
that the opposite is true when you are searching within your own 
database of citations.
I don't think this is necessarily the case.  Often I do know generally 
what I need (mid-1990s article by author x and y), but equally 
commonly, I'm looking for "anything related to topics a and b", where 
"anything" could include annotation content.

Have you read Tim Bray's discussions on search interfaces?  Research 
and everyday anecdote shows that when presented a choice between using 
a simple query interface, and a complex one, users overwhelmingly 
choose the former.  The reason is because it's a PITA to have to switch 
to another interface and work across multiple fields.  I certainly 
don't want to do that when I'm writing just to find some references.

In my eXist-based database, I can easily and quickly find whatever I 
need (including as I said, stuff that I actually do need but completely 
forgot about) simply by using a google query syntax.

The underlying technology is not just dumb, though; it using some sort 
of proximity matching a la Lucienne to rank results.

Demo here, though I'm not sure how many records are loaded (it's 
bundled with eXist anyway, so you can always try for yourself):

http://demo.exist-db.org/exist/mods/
Bruce
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev-biblio] Re: [users-biblio] Initial comments on OOoBib UI Architectural Design 2.0

[Bruce D'Arcus]

On Feb 24, 2005, at 9:29 AM, Dr Robert Sanderson wrote:
Certainly.  But as you say, you often know what you're looking for.  
So you need a more advanced search interface than just a google like 
single query box.
We need both.
Sure.  There's plenty of relevance ranking algorithms available for 
these sorts of things.  But this precludes the use of any sort of 
stupid database (such as a relational database).  Unless you can 
ensure that every database backend will have some clever relevance 
ranking system, you need to have multiple fields to allow for precise 
searches.
That's fine, so long as we have both options.  In the eXist demo, the 
simple field is in the sidebar, but there's a link to an "advanced" 
search interface.  That's as it should be.  Do you not agree?

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

Re: [dev-biblio] Re: [users-biblio] Initial comments on OOoBib UI Architectural Design 2.0

[Bruce D'Arcus]

sorry, some messages aren't going to both lists; Rob and I were 
discussing simple (google like) vs. complex (library GUI like) search 
interfaces.

On Feb 24, 2005, at 9:54 AM, Dr Robert Sanderson wrote:
That's fine, so long as we have both options.
Sure, that's all I'm arguing for :)
Nice to see we can argue about something we agree on ;-)
But the issue is important for GUI design.  I think often people start 
with the complex search interface with the other being an afterthought. 
 I believe the simple query is essential, because it's the most common 
method by which a user finds stuff.

In Endnote, BTW, you have a table view, with different columns.  
Clicking a column sorts on that field.  If you type on the keyboard, it 
filters based on that.  It's slow and awkward.  I want something like 
that, only much better; my google field at the top of the table 
display.

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

[dev-biblio] Re: [users-biblio] Comments & clarifications for dev & users list msgs

[Bruce D'Arcus]

On Feb 25, 2005, at 9:04 AM, [EMAIL PROTECTED] wrote:
Any chance we can somehow consolidate the GUI discussion in a single 
list?
Perhaps, but in the meantime, the easiest solution is to do a 
reply-all.  We should try to maintain attribution in the quotes, though 
(because sometimes hard to reconstruct).

Comments and clarifications based on the comments so far:
First, let me clarify something: why the distinction between 
"reference" and "list of references"?

From my perspective, the latter would always be automatically 
generated, so why would I want to insert a single reference? It seems 
like it would make the GUI more complicated.
Some documents have two or more 'lists of references':  (1) a general 
bibliography, such as "Recommended Readings," containing information 
items that are simply inserted in that list and not cited in the 
document, and (2) a 'works cited' (MLA term) list.  By differentiating 
reference and list of references, OOoBib could handle multiple lists 
without additional work for the user because citations would 
automatically go into the 'works cited' list. A user would need to 
position the cursor in the Bibliography list and insert the references 
to be included there.  Using a 'no cite' option would not work for the 
(1) type of list as the reference would still go into list (2).
I see what you mean now.  There are two separate issues here:
1)  reference grouping
Another example to the above is that I often see articles where you 
have a few different subdivisions in the reference list: for example, 
"newspaper articles," "legal documents" and then the references per se.

2)  "no cite"
Could not they be consolidated?  A "recommended reading" would thus be 
a citation with a local style of "no cite" which is grouped together 
under the heading of "Recommended Readings."

A reference list subsection for archival documents would just consist 
of standard citation referents, but grouped by genre/resource type.

??
c) If the doc contained only very selected fields or, in the extreme 
case, only
the formatted citations and no "raw" metadata at all, the receiver 
would not be
able to get any bibliographic data out of the document and wouldn't 
be able to
apply a new style either (since this might require some other data 
fields).

What is your opinion about c)? Should this be possible at all? Are 
there maybe
users that might not want their complete used metadata to be shared 
with the
document receivers? Are there alternatives?
These are exactly the kinds of issues that MUST be resolved for me to 
do the GUI design. I do not know all the possible alternatives, and it 
is not appropriate for me to make the functionality decisions.  So 
what shall OOoBib do for Version 1?
The easiest solution if we go all XML is to have a complete MODS record 
that includes all the metadata.  Annotations are then stored in 
separate files that are linked to their MODS referent(s).

A user may choose, when saving their document, something like the 
following checkbox options (let's be concrete):

Bibliography save options
include bibliographic source metadata __
include annotations:
public   __
private __
Now, if you don't include the metadata, then you risk the person on the 
other end not being able to reformat the document.  That's a choice we 
can leave to the user, I think (or not, it's not really a big deal to 
just always embed).

Notes would have to be explicitly marked as public to be consider as 
such.  Default would be private.

I still think abstracts should be considered part of the core metadata. 
 If you download a reference from pretty much any online journal 
database, they include the abstracts.  Why shouldn't we?

re: equations and such
But the GUI designer is one of those who does need this to seriously 
use OpenOffice. ;-)
Martha -- given your background in the library world, perhaps you ought 
to help me lobby the LoC on this :-)

I think the BibDB should contain ALL the information, and that there 
should be a default setting about what subset is included as the 
"travelling library" (to borrow an EndNote term) with the document.  
The travelling library contents should be able to be changed by the 
author of the document, and the travelling library ought to be able 
to be exported into a proper BibDB by the reader of the document.
All fine, except the part about "be able to be changed."  I think 
that'd be difficult to manage.
So what shall OOoBib do for Version 1?
As above.  When I express resistance to the notion of editing the 
embedded metadata, it's because I see this as unnecessary, and 
complicated.  If we design the embedding options properly (including 
the option not to embed), then there shouldn't be any problems.

This is why I originally thought that there would be only one BibDB 
with subsets ("Collections") that could be searched and managed 
separately.  If I could import my 'book collector' list of the books I 
o

[dev-biblio] Fwd: [unalog-general] dumb implementations of smart metadata

[Bruce D'Arcus]

Hmm ...
Begin forwarded message:
From: Daniel Chudnov <[EMAIL PROTECTED]>
Date: February 25, 2005 5:56:01 PM EST
To: [EMAIL PROTECTED]
Subject: [unalog-general] dumb implementations of smart metadata
It might seem like unalog development has ground to a halt... in a 
way, it has, with o significant checkins in weeks.

But, we've been making various kinds of progress.  I've tested a few 
different approaches to adding search, and today's winner (and 
probably a lock for the long-term choice) is PyLucene.  It's lucene, 
it's fast, it's working, and there are some nice little UI tricks I 
think we can layer in to make it even more user friendly.  Expect to 
see that checked in in at least rudimentary form sometime in the next 
7-10 days.

Longer-term, the Yale Gang of Three (heretofore YGoT) has been meeting 
regularly to discuss The Metadata Problem.  That being, "how do we 
expand our notion of what an entry is so we can save citations and 
route openurls and the like?"  We're rather enchanted with LoC's MODS, 
and think we can upgrade the current model of unalog entries directly 
to MODS records and add features as we go.  This will also allow us to 
wrap around things like bibutils to allow import/export in a few 
well-known formats, among other things.

The other thing we'd like to try to do with MODS is to find a way to 
track the "site-wide" "bibliographic" version of an entry (whereas 
users have a "holdings" record).  The YGoT is thinking that we could 
store a MODS record wrapped inside METS, with changes over time noted 
as METS amdsecs.  And we were also just thinking how much fun it would 
be to track tags, keywords, names, and subjects using MADS, too.

That's all a little ambitious.  And the YGoT might be ambitious, but 
we're also project-laden and resource-cramped.  Cranking out full and 
reliable implementations of each of these specs is no small task, 
especially as each is changing fairly rapidly, and none of us has a 
lot of experience with any of them.  Also, there's the 
do-we-store-xml-natively-or-not conundrum, and we don't wish to fan 
the flames of the Hacker Culture Wars just now.

So the YGoT is probably going to spend the next few weeks producing 
some dumb implementations of these very smart metadata specs.  It 
should be fairly simple to convert the current unalog "UserEntry" into 
a more MODS-like internal model.  It should be fairly simple to save a 
site-wide "bibrecord" for each entry, and define a couple of workflows 
for whether users who add similar items a second and third time add to 
the bibrecord that's there, or replace, or just modify optionally.  It 
should also be easy to keep a METSish model of changes over time, and 
a MADSish model of how tags relate to each other, and simple UIs for 
working with both of those.  It would be particularly easy too if we 
just avoided the whole XML question for a while and just worked "in 
the spirit of M[A|E|D][D|T]S" without perfecting all those messy angle 
brackets just now.

Thus we might not go from 0-to-SchemaValid anytime soon, but I think 
we can crank out some stuff that will be More Useful and Not 
Irreversable and Something To Improve Upon if it goes well.

It's awkward to have these lengthy, insight-inducing YGoT meetings 
without having some or all of you in the room, and I know these 
occasional missives come off as long-winded and hard to follow.  
Suffice it to say, then, that we'll be cranking it up in the next few 
weeks, and anywhere and everywhere any of you want to pitch in, we'll 
try to find a way to make it easy.  Even if I have to write 
succinctly.

  -dc
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real 
users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
___
unalog-general mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/unalog-general

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

Re: [dev-biblio] Initial comments on OOoBib UI Architectural Design 2.0

[Bruce D'Arcus]

I wrote this before David responded, but will send nonetheless.
On Feb 26, 2005, at 4:23 PM, Matthias Basler wrote:
I simply want to avaoid that Martha builds a nice GUI concept with us 
... and at
the end the actual coders tell us they cannot do this or that in a 
reasonable
time frame or cannot do other things at all.

So, is the feedback from the potential coders ensured?
We still can't tell you who is going to code the GUI, nor how.
I think if we don't show people how it ought to be done, however, it 
won't ever happen.  It's easier to scale back based on the realities of 
context -- and be explicit about the compromises you are making -- than 
to start with a compromised design.

Also, OOo is itself a bit of moving target.  2.0 adds XForms support, 
for example.  It's currently aimed more at end users, but I happen to 
believe it could be expanded to make things easier for developers as 
well.

So, I'm not too worried about this issue.
Bruce
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev-biblio] Initial comments on OOoBib UI Architectural Design 2.0

[Bruce D'Arcus]

On Feb 25, 2005, at 3:36 AM, Peter Tandler wrote:
If I copy entries to my laptop it would be cool if the copied 
references would be synchronized automatically so that I get all 
(public) updates automatically (as soon as I have the network 
connection) -- and vice versa.

What do you think?
It would be a detail of the portable references idea.  So, when you 
save the document, the bib records are saved along with it.  When the 
document is transferred to another machine, if that database doesn't 
include relevant records, you can choose to add them.

For your example, it would mean allowing existing records to be 
overwritten by the embedded ones.  I'm not sure *I* would want to do 
that myself.  And what would be the user experience that would allow a 
user to choose whether or not to overwrite specific records?

Also, it's not like a bib record is likely to change much at all, so 
why is it important to synchronize the records themselves?

(And this implies the need for supporting multiple databases.)
Why?  All it implies is the ability to switch connections from one 
database to another.  It doesn't imply more-than-one active connections 
at a single time (which is what I dislike).

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

Re: [dev-biblio] RE: [users-biblio] Comments & clarifications for dev & users list msgs

[Bruce D'Arcus]

On Feb 28, 2005, at 3:41 AM, Vincent Thornley wrote:
I have a slightly different requirement, that may be covered by what 
you
write above. In writing a large document (e.g. a thesis or book) I 
would
like to list references at the end of each chapter, and then 
consolidate all
those references at the end of the work.
I'd like this too.
There are some complications to this. If an Author-Year citation 
system is
employed it must be ensured that consistent postscripts (e.g. Thornley,
2005a; Thornley, 2005b) are used throughout. If a numbered citation 
system
is employed the numbering would have to be consistent throughout
If the formatting system is designed correctly this isn't a problem. 
The XSLT system I am currently working on was started for a quite 
pragmatic purpose: to format my book.  That book is just a bunch of 
separate chapter files assembled exactly like a master document system 
would be.

The only possible wrinkle is that I don't know how OOo deals with 
master documents internally.

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

[dev-biblio] design and possibilities (was something else)

[Bruce D'Arcus]

On Feb 28, 2005, at 2:43 PM, [EMAIL PROTECTED] wrote:
Bruce wrote:
I think if we don't show people how it ought to be done, however, it 
won't ever happen.  It's easier to scale back based on the realities 
of context -- and be explicit about the compromises you are making -- 
than to start with a compromised design.
I understand, Bruce -- but I have little interest in spending time 
doing rework. ;-)  Thus it is critically important that we have a 
strong sense of what is supportable in the GUI before doing the 
lower-levels of GUI design.
So then perhaps we should present the higher-level design to Andreas 
and team before going further.

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

[dev-biblio] grouping

[Bruce D'Arcus]

On Feb 28, 2005, at 2:19 PM, [EMAIL PROTECTED] wrote:
Bruce wrote:
I see what you mean now.  There are two separate issues here:
1)  reference grouping
Another example to the above is that I often see articles where you 
have a few different subdivisions in the reference list: for example, 
"newspaper articles," "legal documents" and then the references per 
se.

2)  "no cite"
Could not they be consolidated?  A "recommended reading" would thus 
be a citation with a local style of "no cite" which is grouped 
together under the heading of "Recommended Readings."

A reference list subsection for archival documents would just consist 
of standard citation referents, but grouped by genre/resource type.

I think that would work as long as the user can position a cursor into 
a list of references and insert at that point.
I'm not following.
There just needs to be some way to group references as separate 
"lists" that might even be separate appendices of a book.
Yes.
I like "private" being the default, but I think there are fields other 
than annotations that have 'private' enabled (e.g., filenames of 
inserted graphics).
OK.
But the GUI designer is one of those who does need this to seriously 
use OpenOffice. ;-)
Martha -- given your background in the library world, perhaps you 
ought to help me lobby the LoC on this :-)
OK, what do you want me to do?
I'm not sure.  It's just a delicate lobbying effort involved in getting 
the LoC to do this.  I've been trying for the past year off-and-on, and 
I've not been successful yet.

I need some clarification -- (1) The metadata could travel with the 
doc, and then after the receiver revises the metadata and sends it 
back, OOoBib could ask if to overwrite when the original author opens 
the returned (and edited) document.  Or (2) the  original author can 
only change the 'traveling library contents' by changing the OOoBib 
info and then reinserting, and the receiver cannot change the metadata 
at all?
I vote for 2.
Can't the "collections" just be virtual; e.g. a named query?
Could be, as long as there is a unique database key that identifies 
each collection.  I have not had time to sort all of my books into 
genres in 'book collector', so I literally some a few genres such as 
"oak bookcase in the basement".
But that's a location; not a genre.
Bruce
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev-biblio] New developer

[Bruce D'Arcus]

On Mar 1, 2005, at 8:57 PM, Michael Bowman wrote:
My name is Michael Bowman. I'm a fairly experienced (2 yrs 
professionally) Java developer, though I do have experience with 
Python, Perl, and C++ (from my college days) as well. Linux w/Gnome is 
my primary OS.
Hi Michael -- welcome aboard.
I see *tons* of potential in this project and would really like to get 
involved.
Excellent!
I'm going to hope someone else can jump in and answer your other 
questions.  I thought I'd just instead tell you where we're at these 
days, and load you up with some urls:

Most of us (well, really all of us) believe the current bibliographic 
support is so limited that it needs to be radically recoded.  There are 
a number of steps in this process:

1)  Rework the way citations are handled in the OpenDocument file 
format. I co-authored a small standalone schema with an engineer at Sun 
which has been approved by the OASIS TC. It will be formally integrated 
into the spec sometime in the next few months.  So that critical step 
is done.

The purpose of the changes is to make it really easy to regenerate 
formatting in radically different styles without having to change the 
document source.

2)  OOo itself needs to be enhanced to support the new citation coding. 
This needs to be done by Sun engineers, and we have some promise from 
Sun that they will dedicate resources for this after they release 2.0.

3)  We are also going to ask them to implement a plug-in API based on 
ZOOM:

http://zoom.z3950.org/
So, we'd build the architecture around a unified local/remote query 
API.  There are open source implementations in a variety of languages 
we could borrow.

The precise details are still to be determined, but one possibility is 
then to say that any database project that communicates via SRU (REST) 
and/or SRW (SOAP) and serves MODS XML records can be a plug-in for 
OpenOffice.

http://www.loc.gov/z3950/agency/zing/srw/sru.html
http://www.loc.gov/z3950/agency/zing/srw/
http://www.loc.gov/standards/mods/
4)  I've been working on a side project that I'd like to see make it 
into here; it consists of an XML formatting language for citations, and 
an XSLT-based formatting engine:

http://xbiblio.sourceforge.net/citeproc.html
There are a number of cool things about this, but one of them is that 
the XSLT communicates with a database over HTTP.  It would thus be 
trivial to add SRU support.

5)  We have a GUI design guru working on a design documents
Still to be determined:
a.  integration details
b.  what persistence mechanism to use as default (I sort of like the 
idea of using an XML DB like BDB XML; there may be licensing issues 
there though)
c.  who's going to code the GUI??

You mentioned your language background.  I still haven't worked out the 
language issue in OOo.  It seems C++ has the most mature support from 
what I've gathered.  I've heard various complaints about the Java and 
Python support, but they may have been resolved.

What sort of stuff are you interested in contributing to?  And what's 
your comfort level with XML?

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

Re: [dev-biblio] New developer

[Bruce D'Arcus]

On Mar 2, 2005, at 4:32 AM, Dr Robert Sanderson wrote:
I'm not sure if that's what Bruce had in mind, but it sounds like a 
good approach to me! :)
There are a couple of options ...
Here's my view of a simple workflow:
Creation1:
* Search remote repository for documents [ZOOM API, SRW/U (Z39.50)]
* Select required documents
* Download documents to local database [MODS]
Creation2:
* Create new document locally in a form [MODS]
* Save to local database
While editing a document:
* Search local database [ZOOM, SRW/U]
* Select required MODS documents
* Import citation information into document
While styling a document:
* Select bibliographic style
* Format citations in document with style information
This makes sense.  There will just be some details to work out on this.
1)  The bib data would be embedded as a separate file in the file 
wrapper; but the file wrapper itself is zipped.  Also, the OOo XML 
doesn't exist in memory, but on save.  So how to tweak things to get it 
work for an XSLT processor?  (this is for Sun to help with!)

2)  Do you want to require bib data to be embedded?  If yes, what 
happens when you have a document with 300 citations?

Am just asking.  This approach is probably the simplest/most elegant.
Bruce

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

Re: [dev-biblio] New developer

[Bruce D'Arcus]

On Mar 1, 2005, at 11:08 PM, James Howison wrote:
That is slightly different from the docbook workflow in that the 
records would also be in the XML file already but understandable.
The primary difference is that the input and output documents are the 
same in a GUI context.

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

Re: [dev-biblio] New developer

[Bruce D'Arcus]

On Mar 2, 2005, at 7:25 AM, Dr Robert Sanderson wrote:
On the other hand, just because the =current= bib style doesn't need 
the information doesn't mean that the document won't be edited later 
by someone without all of the references who might then change the 
style, requiring data that isn't present.
All formatting-related metadata should always be included if we're 
going to do it this way.  A lot of the style-specific stuff is just 
generated by citeproc anyway, so I don't think there's any difference 
in what metadata different style require.

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

Re: [dev-biblio] New developer

[Bruce D'Arcus]

James Howison wrote:
In addition to people wanting to change the style of the document we 
should consider people wanting to extract references from the document. 
Yes, we all want this.
So I'd love to see a format that carries all the information of the 
citations by default, even if it doesn't display them.  And, IMO, that 
should include the abstracts.  Bruce asked what happens when there are 
300 entries?  Answer: larger file.  Not really a big deal, we're talking 
K of data, not Gigs.  Abstracts are never longer than a page.  It's a 
trivial amount of data, even for a bibliography of thousands.
I tend to lean towards this argument myself.  There's the possibility to 
split the difference, though, by allowing the user to configure whether 
the embedded data is "full" (to be extracted) or "light" (perhaps not).

In any case, I don't think this will be hard to resolve.
Bruce
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[dev-biblio] 2.0 beta and xforms

[Bruce D'Arcus]

Since my platform is officially unsupported (um, Sun, how about getting 
a clue on Mac support?), I've not had a chance to try it, but a public 
beta was released last week for v2 of the suite.  It includes xforms 
support.  Anyone played with it?

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

Re: [dev-biblio] 2.0 beta and xforms

[Bruce D'Arcus]

On Mar 6, 2005, at 9:37 AM, Matthias Basler wrote:
Not yet, but now that you mention the 2.0beta ...
I've been testing the latest versions and checkung Issuezilla. From  
what I have
seen so far(!) I am not really glad with OOo2.0 yet - and I am not the  
only
one. See f.e. the article and the user comments to it:
http://software.newsforge.com/software/05/02/25/209222.shtml? 
tid=93&tid=130
It seems there a number of issues with OOo development:
1)  it's a huge code-based that's quite old, so difficult to work with
2)  project priorities
I personally think:
-	it's a big mistake to prioritize Java in OOo, when the existing  
Python support is so lacking that people like Rob basically consider it  
worthless (like, there's no use trying to use Python in OOo); OOo's  
future success will depend on its support for Python, etc.

-	it's a somewhat lesser mistake to focus so much on copying Office.   
OOo needs to be BETTER than Office, or people won't bother with it

The funny thing is, in trying to copy Office so closely, OOo developers  
are trying hit a moving target.  MS understands they need to evolve  
Office and exploit XML, and yet OOo is recreating last-year's model.

A case in point is the fact that the UI is still heavily-oriented  
around word-processing as practiced way back in the 1980s!  Get rid of  
the damned b and i toolbar buttons, and get serious about character  
styles and mapping them to XML!  Think of how to integrate auto-text  
support into that.

I asked about xforms support because I think this could be a really  
good thing.  I also still wonder if it makes sense to extend it beyond  
its current document focus.

Also, I think this emphasizes why we ought to rip out the current bib  
support and make it fully plug-in based.  It seems one of the reasons  
the bib module has languished so much is precisely because it's so  
closely coupled with SW.

Bruce

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

Re: [dev-biblio] 2.0 beta and xforms

[Bruce D'Arcus]

On Mar 6, 2005, at 12:43 PM, Matthias Basler wrote:
I'd be intersted to know why you think that, particularly, Python is so
important for "OOo's future success".
Not Python per se, but "dynamic languages widely used in the free 
software world."  Python is the most obvious example.  Gotta make it 
easy for people to extend.

Has Rob already looked into the new SDK to check if Python support has 
improved?
Not sure.
Get rid of the damned b and i toolbar buttons, and get serious
about character styles and mapping them to XML!
Sorry to disagree here. Imagine a 70 year old grandma writing a letter 
to her
son. Using "bold" and "italice" and selecting a font+size does the 
thing. I
wonder how you would manage to tell that grandma to create a style for 
each
formatting first - which takes at least twice the time. You get the 
picture?
Yes, but I disagree this a problem.  Have a toolbar button and 
customizable keyboard mapping that indicates the semantic meaning: 
emphasis, for example.  It could be just as easy as the existing 
brain-dead presentational stuff if designed right.

Have you looked at Apple's new word-processing/DTP application?  It's 
designed for novice users (including presumably grandma), and they've 
made the noble jump of removing this old UI cruft and reorganizing 
around styles.

The future is semantic, and OOo better get with the program.  The UI 
challenge -- which can be solved -- is simply how to make this easy and 
intuitive for the user.

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

Re: [dev-biblio] I'd like to help, but how ?

[Bruce D'Arcus]

Hi Julien,
On Mar 7, 2005, at 3:01 AM, TEXTORIS Julien wrote:
I wanted first to test the different components cited in mails (zoom,
citeproc, PyOobib, etc ...) but i never managed to get anything work !
(And usually, i'm not to bad to install everything)
Oops.  Contact me off-list about the citeproc problems.  It could be 
its bad documentation ;-)

On ZOOM, I've found this to be easy to compile:
http://www.indexdata.dk/yaz/
So what i can offer you is maybe a translation help, to put some
documents you would think important to be translate into french ? And
then hopefully getting more people involved in the project ?
David?
sorry for my english
No worries; it's much better than my French!
Bruce
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev-biblio] I'd like to help, but how ?

[Bruce D'Arcus]

On Mar 7, 2005, at 6:05 PM, Daniel Carrera wrote:
It provides a Python library that lets Python read BibTeX, ISI, 
Medline,
Ovid and Refer. You could use this library to read those files. Then 
all
you have to worry about is writing those files to the OOo bibliographic
database.

As for entering a data into the Bib database, I am writing a sample
program to show you how to do it (to the extent that I now). I'll post 
it
somewhere when I'm done.
There are a few wrinkles here:
1)  From what Rob says, the Python support in OOo sucks.
2)  The above approach I guess could add import to the existing bib 
support.  But most of us think the existing support is so bad it needs 
to be completely redone.

We're still working on the precise details of how it all would fit 
together, but it seems to me these C-based tools (which are currently 
being reworked into a library) would be more forward-looking, since 
their core XML format is MODS:

http://www.scripps.edu/~cdputnam/software/bibutils/
Someone is already looking at writing a Python binding or wrapper for 
it.

So we've got the following possible codebase we can draw on, all 
C-based:

1)  Bibutils (import/export filters)
2)  Yaz (ZOOM-based query)
3)  a bunch of storage options, but an XML DB like BDB XML is seeming 
like the way to go

1 & 3 are GPL, but am hoping so long as OOoBib is a plug-in, that would 
be fine.  It could also have the advantage of being useable outside OOo 
(which is a goal of mine).

Bruce, how would you feel about uploading this file to the Bib website?
Check with David on this Daniel.  He's the doc man :-)
Bruce
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[dev-biblio] math in bib metadata

[Bruce D'Arcus]

FYI, an excerpt of a conversation with David Carlisle; an expert in XML 
and XSLT (and unicode, actually), as well as a person with a math 
background (he's been involved with MathML):

For many titles, even mathematical titles, unicode plain text is
sufficient, you have greek and all the operators. mathematicians have a
long history of having to get their article titles into search engines
and printed book catalogues that don't have mathematical capability so
it is exceptionally rare to require really fancy 2 dimensional 
formating
in a title. The main problem is not titles, it's abstracts or other
paragraph sized texts that your biblio format might allow, there you
really do need full mathematical layout possibilities so mathml is your
friend.
Am trying to figure out what we really need in MODS to support this 
stuff.

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

[dev-biblio] Re: [users-biblio] Can OO be made to more easity work with commercial/opensource bibliographic programs??

[Bruce D'Arcus]

On Mon, 14 Mar 2005 02:33:51 -0500, "Sweet Coffee"
<[EMAIL PROTECTED]> said:

> Is there some way to make commercial/opensource bibliographic programs
> plug into OO more easily?

Our proposal is to move to a plug-in based system, so yes.

> I am also looking forward to the updated bibliographic program in OO. 
> BTW, will it be ready for the v2.0 OO release??

No. Sorry.

Bruce

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

Re: [dev-biblio] sorting question

[Bruce D'Arcus]

On Mar 29, 2005, at 1:25 AM, [EMAIL PROTECTED] wrote:
Are you talking about a short reference list already inserted in a 
paper as a reference list or about a reference list that is being 
created from the entire database?
The former.
The choices I make here will affect the GUI for it, BTW.  Just think of 
how you'd configure the formatting for two different types of 
references:

1)  A book, where primary sort key and first field is the creator name, 
and secondary would be "Anonymous"
2)  A legal case, where primary sort key and first field is that record 
title (Doe v. Smith)

Currently my formatter has internal rules for handling this stuff, so 
that it's mostly handled implicitly (which makes things simpler).  
However, I got tripped up on example 2, so need to rework things.

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

Re: [dev-biblio] sorting question

[Bruce D'Arcus]

On Mar 29, 2005, at 5:14 AM, Matthias Basler wrote:
So my rules are easy to implement,
Yes.  But are you sure you don't have more complex rules for 
periodicals?

except that the author(s) must be sorted
correctly, that is, in my case by their family names.
Actually, it's more complicated than this, but I have it covered.  I 
have a function that constructs a creator-names string that includes 
all creator names, both family and given.  IIRC, it would result in 
something (internally of course) like:

DoeJohn:SmithSteven
DoeJane:JonesSandra
The tricky part is these more complex sorting examples; constructing 
the XML in a way that will be GUI-friendly.

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

Re: [dev-biblio] sorting question

[Bruce D'Arcus]

On Mar 30, 2005, at 1:05 AM, David Wilson wrote:
I imagine some other style guides have different rules ?
That's not question :-)
The question is how to design configuration of sorting.
Bruce
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev-biblio] sorting question

[Bruce D'Arcus]

On Mar 31, 2005, at 2:58 AM, Vincent Thornley wrote:
I assume that the examples given above would also cover the case where 
the
"author" is an organisation, e.g. a government or company report.
Yes, config file just says "creator name" (not author; not personal 
name).  Internally the code knows what to do.

I think
there are two possibilities for handling this and I am not sure which 
route
you have chosen to follow:
1. Use the organisation (or an abbreviation) as the creator name and 
sort as
normal.
That's how it works.
2. Leave the creator name blank in which case the sort algorithm will 
have
to recognise the material type and if necessary use the organisation 
as the
primary sort key (and of course for display in the citation).
I think you're "preferable" option is more complicated than it needs to 
be.

One of the ways I decoupled name handling from reference type details 
is to use the generic creator and to separately handle role (author, 
editor, etc.).  It simplifies things a fair bit, while making them more 
flexible too.

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

Re: [dev-biblio] sorting question

[Bruce D'Arcus]

On Apr 4, 2005, at 3:43 AM, Vincent Thornley wrote:
OK, great. So that means that within the database if the creator is a 
person
it (he/she!) would appear in an author (or editor) field, and if it 
was an
organisation it would appear in, for example, an organisation field. 
Are you
handling this during the insert citation process or expecting it to be
handled within the database?
The latter. We want to use SRU/W, which uses CQL, which is based on 
abstract indices. In other words, the details are up the database; it 
just needs to understand "creator."

Obviously this has an impact if the
bibliography plug-in is to handle multiple database sources.
The details are really determined by MODS, which provides the metadata 
structure.  In MODS you have:


  Jane
  Doe


  Organization Name

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

Re: [dev-biblio] modified bibliographic entries - update

[Bruce D'Arcus]

On Apr 5, 2005, at 8:38 AM, Jozef Riha wrote:
 if anyone knows a workaround - except for writing w/ no mistakes
- please let me know.
The ugly solution is to keep track of the mistakes and when you're 
done, open up the XML document file and do a search-and-replace to fix 
those that need fixing.

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

Re: [dev-biblio] What we can learn from Eclipse

[Bruce D'Arcus]

On Apr 10, 2005, at 5:37 AM, Matthias Basler wrote:
The point I want to make here is, that this Eclipse platform and IDE 
are a just
perfect examples of a flexible and extensible open source programs - 
something I
would like to see in OpenOffice as well.
jEdit's plug-in system is another nice example I've mentioned before.
David -- it's worth asking the Sun people if they plan to offer a 
general plug-in infrastructure.

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

Re: [dev-biblio] sorting question

[Bruce D'Arcus]

On Mar 30, 2005, at 5:42 PM, David Wilson wrote:
I understand that different language may need different sorting 
routines.
I think I'm not being clear.  Here's what I originally posted:
I'm working on sorting configuration, but am running into a fundamental 
design question:

When dealing with reference lists, is the first field always the sort 
key?

For example, in a typical reference list, the creator name will be the 
sort key.  If there is no creator, there needs to be rules to specify 
substitutes.  For a book, it might be to substitute the phrase 
"Anonymous."  For an article, it might be to substitute the periodical 
title.

In a cite key style citation class, likewise, it seems the sort key is 
the citation key; e.g.:

[doe99] Doe, J. ...
Is this a reliable general rule then?  Or should instead the layout and 
the sorting be seen as completely separate?

I'm leaning towards a structure like:


It's possible for me to do some RELAX NG magic and condition the layout 
of the following elements based on the sort-key value, but I'm not sure 
I should do that or not.

The other issue I've not resolved is how to handle CDATA, though one 
solution is to have:


  
creator
container-title

  


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

Re: [dev-biblio] sorting question

[Bruce D'Arcus]

On Mar 30, 2005, at 6:17 PM, [EMAIL PROTECTED] wrote:
alphabetize entries with numerals as if the numerals were spelled 
out
Yeah, right.  What a PITA.
Bruce
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev-biblio] Document type lists and document options

[Bruce D'Arcus]

On May 21, 2005, at 9:23 PM, David Wilson wrote:

The point I am trying to get to is that the bibliography format should 
be
generated from the information that the user has provided about the 
work,
rather than from the user first have to make a selection from a 
document type
list that is difficulty to fully understand and does not satisfy all 
the

variation found.


I've not read through the details of your proposal, but I think you're 
right on this.


I've been experimenting with a "MODS Strict" schema, and on eof things 
I enforce is genre elements on every level.  So, one woud start with an 
"article" and then choose whether the container is a magazine, 
newspaper, etc.  The logic is motivated by the same observation that 
types are awkward for entry too.


Bruce


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

Re: [dev-biblio] Re: A new approach to bibliographic style content analysis

[Bruce D'Arcus]

I really like the premise that there's room to start fresh here.  FWIW, 
in my formatting system, the logic is based on similar thinking.  In 
terms of classifying records, there two levels:


	refclass: structural, with values like part-inSerial, monograph, 
part-inMonograph


The core of the formatting is really based on this.

reftype: more familiar genre-based classification, with a wrinkle

Reftypes are not necessarily singular ("journal article") but can 
rather be concatenated across levels.  So you could have:


article-academic journal
review-magazine
editorial-newspaper

I'm building a similar logic into a "mods strict" schema I'm working on.

Bruce


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

Re: [dev-biblio] summer of code

[Bruce D'Arcus]

On Jun 6, 2005, at 2:51 AM, Daniel Lees 08 wrote:


Hi, I apologize if this is going to the wrong email address. 


You got it right Daniel.  Hi.

 I'm interested in the working on the bibliographic project for 
Google's Summer of Code program.  I'd be willing to work on whatever 
is considered important at the moment.


What kind of coding skills do you have?

Bruce


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

Re: [dev-biblio] OpenOffice Bibliography

[Bruce D'Arcus]

On Jun 6, 2005, at 3:27 PM, Matt Wiggins wrote:


What knowledge would be required for someone
to take part in this project?


Hi Matt.  What knowledge do you have?

I think we're in most need of people with C++ expertise, but there's 
room for other contributions.


Bruce


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

[dev-biblio] Fwd: [project leads] Announcement Uno Runtime Environment (URE)

[Bruce D'Arcus]

Seems might this might be interesting ... (?)

Begin forwarded message:


From: Kay Ramme - Sun Germany - Hamburg <[EMAIL PROTECTED]>
Date: June 9, 2005 9:21:18 AM EDT
To: [EMAIL PROTECTED], [EMAIL PROTECTED], 
announce@openoffice.org, dev@openoffice.org

Subject: [project leads] Announcement Uno Runtime Environment (URE)
Reply-To: [EMAIL PROTECTED]

Dear OpenOffice.org and UNO friends,

I am pleased to announce that a sponsor, who is preferring to stay 
anonymous, is supporting us to do the next step in modulizing the 
OpenOffice.org office suite and to make its component model available 
independently. That means, that we are going to factor out the highly 
requested


 Universal Network Objects (UNO)

into its own

  Uno Runtime Environment  (URE)

The URE allows the usage of UNO independently of the OpenOffice.org 
productivity suite. UNO is OpenOffice.orgs underlying component model, 
allowing language agnostic and remote transparent development of 
add-ins, components and applications.


As UNO has already been designed with independence in mind, the URE is 
mainly about bundling the appropriate libraries, executables etc. into 
their own package. Please have a look at the URE proposal at


 http://udk.openoffice.org/common/man/draft/standalone_uno_1_0.html
respectively the UNO homepage at

 http://udk.openoffice.org

for details. The URE is planned to be released with OOo 2.0. As OOo 
2.0 is already advanced in its development, the plan is to adapt OOo 
to the URE with its next major (see 
http://www.openoffice.org/issues/show_bug.cgi?id=50467) release.


XPCom, Bonobo and Mono fans might want to give UNO a try and see if we 
can/want to bridge from one component model to another, to reach 
higher overall interoperability.


Distro packagers might want to provide the URE (and the OOo SDK) with 
their distro, not only as a prerequisite for past OOo 2.0 releases but 
to enable people to develop UNO components.


Porters might want to port the URE, which is mainly a packaging task, 
to their favorite platform.


Please send feedback to dev@udk.openoffice.org, respectively to 
Stephan Bergmann ([EMAIL PROTECTED], UDK co-lead) or Kay Ramme 
([EMAIL PROTECTED], UDK lead).



Kay


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




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

[dev-biblio] [ANN] XBib

[Bruce D'Arcus]

Just a head's up that I've finally announced this project I've been  
working on, and which I'd like to see make it into OpenOffice.


http://netapps.muohio.edu/blogs/darcusb/darcusb/archives/2005/06/21/ 
ann-xbib


CiteProc -- the XSLT code -- demonstrates fairly conclusively that the  
approach works.  I used it successfully to format the book manuscript I  
recently finished.


But the important bit is CSL: the XML citation style language.  We  
really need something like this.


Bruce


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

Re: [dev-biblio] Fw: Open office bibliographic project

[Bruce D'Arcus]

On Jul 28, 2005, at 12:05 PM, Howard Noble wrote:

Can we start some dialogue on the best way to explore how we can move 
this forward.


Hi Howard -- yes, thanks for the update!

Just in case people are interested in an update, Howard's group is one 
of the projects I've been collaborating with on citation formatting 
(the other is RefBase), and so it's good to see they're excited about 
bringing what they've done to OOo!


This project is at a critical juncture right now.  Sometime in the next 
month, Sun developers (who are on vacation now) are to start work on 
low-level changes that we hope will make it really easy for projects 
like MDS to plug-in to OOo, and also to significantly improve the 
base-line bibliographic support in the suite.


We'll know more next month exactly what the Sun developers are willing 
to do.  If they do as we are suggesting (update the WP module to 
support the new citation coding already approved for the file format, 
move to a plug-in API based on ZOOM, and integrate advanced citation 
formatting very similar to my citeproc project) then OOo has a bright 
future as a serious competitor to Word in the edu market.


Bruce


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

[dev-biblio] update

[Bruce D'Arcus]

Hi all,

List has been dead for awhile, so just a quick update.

David is away in the Outback for a long vacation. Before he left, he and 
I rattled some cages at Sun out of sheer frustration with the lack of 
communication we were getting about plans going forward. I've gotten a 
tentative response back today which is -- if not entirely reassuring -- 
at least suggests we're headed in the right direction.


In a nutshell, we need Sun to do some low-level changes to make it easy 
to do the things we want to do. Those changes are going to be made in 
the context of a more comprehensive OOo strategy to deal with embedded 
content. As Oliver Specht explained their perspective on this:



The outcome was that the bibliographic text field (the reference) will
be imported into a generic field that provides a DOM tree containing
anything inside of the bib-citation. Other in-paragraph content would
also be loaded into such a field. The Writer doesn't need to know
anything about the semantics of the contained elements.
The data-to-service linkage that is necessary for the Writer to find the
right service to manipulate the data has to be done using some kind of
registry.


I think this is a good direction because it ties the fate of citation 
stuff to a larger effort at OOo.  But that will take some broader 
planning and implementation work that will take time.  It also cannot 
happen (or even be planned) before they finish with the 2.0 release.


I will also be working on a proposal to upgrade the file level support 
some more in OpenDocument.  We already had the citation proposal 
accepted. We now need to figured out the bibliographic metadata picture 
and the styling issue.


More information when I have it, but one issue that we're going to have 
to return to is the format: whether it's MODS, or something else.  I've 
grown a little uncomfortable with standardizing on MODS.


Bruce

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

[dev-biblio] Re: Introduction

[Bruce D'Arcus]

Dane Weber wrote:

Hello David and Bruce,


Hi Dane. cc-ing the dev list as well.


I just wanted to let you know that I'm quite interested in the
bibliography project.  I am currently a graduate student studying
psychology, and thus I would be happy to help define the styles for
APA style.  I also used Kate Turabian style in undergrad, and I was
pretty proficient with it, so I'd be happy to help define styles for
that as well.


Cool.


I have very little programming experience, but I am quite comfortable
with XHTML and CSS, so I'm up for the challenge of learning a similar
XML markup.


OK.  We're still not confirmed that my citeproc work will make it into 
OOo as is, but there's a good chance it will.  I suggest you download 
the latest release from Sourceforge:




... and start getting comfortable with a RELAX NG-validating XML editor 
like emacs nxml mode or (maybe better) oXygen.


The release already has an APA example that I put together.  Here's an 
example of the output:


http://xbiblio.sourceforge.net/examples/apa-en.html

Feel free to take a look and see if you see any need for changes.  The 
more real world styles we can test CSL against, the better, so if you 
could try creating a few styles as well, that'd be great.



I'm browsing through the documents and the user mailing list now.


The dev list may be good to look through too; perhaps more so in fact.

Bruce

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

Re: [dev-biblio] update

[Bruce D'Arcus]

Matthias Steffens wrote:


I would find it rather, uuhm, frustrating to see you (and the OOo
folks) move away from MODS. Especially since it was *you* who
convinced us to support it within our bibliographic applications.
;-)


:-)


However, could there be a solution where both formats go hand in
hand together and where OOo would simply accept both formats -- no
matter how it stores it's stuff internally?


Don't worry Matthias; I won't leave you hanging.

We haven't made any decisions. It's just that we're torn between at 
least two different worlds: the library world that created MODS, and the 
more journal publishing world associated with stuff like PRISM.


If we do decide on something other than MODS, then we will support MODS 
as well in some form.  I will write conversion code between the two if 
necessary, talk to people like Chris Putnam about supporting it too, etc.


As for why I'm changing my mind on this:

It's a combination of a few things.  The most important is that there's 
been some interesting developments in the last few months around RDF bib 
 data:


Ingenta is moving to an RDF backend and will make these huge metadata 
holdings available as RDF (and maybe MODS too, BTW).


CiteULike has become popular, and exports metadata as PRISM/RDF (though 
again could support MODS as well).


There's a lot of interest in the Firefox plug-in Piggy Bank, including 
from bib metadata providers.


Also, Adobe has joined the OpenDocument TC and is proposing that OD 
switch to using its XMP/RDF framework for document metadata. If that 
happens, it would provilege RDF for metadata in the file format.


The other issue is that there are two features I've been asking for in 
MODS for awhile now (embedded content like mathml in titles and 
abstracts and multiple names for a person to support international 
scholars), with no luck.  This leaves me uneasy with trusting our fate 
with a large organization that represents a different community of users 
than us.


Finally, technically speaking, MODS is really rich and expressive, but 
it's also loose.  If I was to prefer an alternative, it would be a much 
tighter one, and so easier for developers to work with.


Remember, I spent a long time writing software dependent on MODS too, so 
I'm not going to be stupid about this!


Bruce

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

Re: [dev-biblio] update

[Bruce D'Arcus]

Matthias Steffens wrote:


If you've got any pointers to introductory material about
PRISM/RDF, I'd appreciate them.


Here's a couple articles Tony Hammond (who I've been chattin with) 
contributed to:


http://www.dlib.org/dlib/december04/hammond/12hammond.html
http://www.xml.com/lpt/a/2003/07/23/rssone.html

I forget if I mentioned, but I've talked to Tony about suggesting 
improvements to PRISM.



Plus, these developers would be all ready to support OOo when its
new bibliographic feature set is out. (at least if I understood you
correctly that communication with OOo will be via HTTP using stuff
like SRU/SRW+CQL, right?)


What we have been asking for is that bib support be moved to a plug-in 
API based on ZOOM, which has out of the box support for z39.50 and 
SRU/W. Other plug-ins can be added.


I have gotten no confirmation from Sun at this level of detail. 
However, the Sun developers agree with the notion that bib support ought 
to be a plug-in, so that's encouraging.


Bruce

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

Re: [dev-biblio] update

[Bruce D'Arcus]

Matthias Steffens wrote:


The same could be said for CQL, btw. At least what concerns PHP
developers. It would be great if we could find someone who'd be
willing to develop (or finance the development) of a good PHP CQL
parser. This would greatly ease the implementation of standards
like SRU/SRW+CQL for PHP developers and would enable them to
actually start with real inter-application communication...


Yes.

Dan Chudnov has a post about his recent addition of SR/W to unalog:



It took him a half-day to implement it with Python, but a) that was with 
an already-written CQL parser, and b) he clearly wasn't thrilled with 
the spec.


Alas, my understanding is that to clean up the spec itself requires 
someone funding it!


Bruce

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

[dev-biblio] Fwd: update on opendocument, rdf

[Bruce D'Arcus]

Oops, sent to wrong address!  Let's try again ...

Don't know if people have been following this, but Massachusetts
finalized the spec calling for using OpenDocument and PDF as the only
acceptable standards for state documents.  I just listened to a
recording of a meeting that discussed this with industry people.
Really interesting stuff (the state very clearly told MS reps to open
their file formats), and great to see MA follow through.  Now we just
need a few more governments to do the same.

Anyway, re: related RDF news, here's the latest minutes from the TC:

> > Meta data:
> > (Gary:) w3c encourages common meta data model across multiple
> > application. Making OpenDocuments meta data model interoperable with RDF
> > would thus be a big step forward.
> >
> > Some review is needed on the current state of our RDF discussion. Duane
> > will try involve engineers at Adobe that have RDF experience.
> >
> > (Lars:) If it is possible to make statements about a document as a
> > whole, it might also be useful to make statements about specific parts
> > of that document. To make that work in RDF, a URL-schema would be needed
> >   to reference those parts.
> >
> > The users mailing list would be a good place to invite people for a
> > public discussion on an extended meta data model for OpenDocument.

This (particularly Lars' comment) is among the reasons I'm thinking an
RDF bib format seems quite sensible.  I'm pushing for them to include
our needs when thinking about how they might do this.

Bruce

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

[dev-biblio] update (reply to Martha)

[Bruce D'Arcus]

Sorry, but it seems I've been unsubscribed from the list for the past 
few days (long story).  Anyway, to reply to Martha's questions (which I 
got from the archive):


Thanks much for the update!  I had been wondering and within a 
heartbeat

of dropping the project,


As were David and I!


but this encouragement is keeping me active.


Ditto.


How do you think RSS will impact the user interface?  For example, a
section in one of the links you provided indicates that RSS could 
impact

the search and retrieval functionality:


A few points:

1)  While the Nature and Ingenta people are making their bib metadata 
available as RSS/RDF, I'm not necessarily saying that's exactly how we 
would do it.  Indeed, while Ingenta itself is moving to an RDF backend, 
I doubt they're actually storing their metadata as RSS.


I will be having a conference call in early October about these issues 
with the Nature group, and with Leigh Dodds at Ingenta and a guy who's 
working with BioMed Central.  I think part of that call will be 
figuring out a way to standardize this stuff more.


2)  It probably would not impact the GUI at all.  It'd really just be a 
slightly different way to transport data.  Whether we're dealing with 
RDF (say something like PRISM + DC) or plain XML (a la MODS) we still 
need to figure out similar issues.


I will say that there is one caveat to the above, which is that I've 
been advising on the recently-released RDF ontology for the FRBR.  If 
we decided on adopting some of that, more complex, structure, then that 
could have GUI consequences.  For example, let's say you want to store 
two things: the 1980 edition of Marx's Capital, Volume 1, and the 
original 1866 (these dates are made up; I don't remember them!).  If 
you were to base a GUI on a more PRISM+DC (or indeed MODS) view of the 
world, you'd have two separate records, with the possibility to link 
them (to say one is the original of the other).  You would duplicate a 
lot of data in that approach.


In an FRBR-inspired view, both the original and the later English 
language edition would be two different expressions of the same work.  
That would suggest a different kind of GUI.


The OCLC has done some protoyping with this, BTW (google for 
FictionFinder).


One barrier to do a more FBRR interface may well be that the vast 
amount of infrastructure -- technical and otherwise -- is built around 
an older (more limited) view of bib metadata. For example, if you 
search the LoC catalog with its web services, you cannot query for 
"works".  You basically query for frbr manifestations (two levels below 
the work!).



Any comments?  And given the issues for implementation, is the intended
functionality stable enough to move ahead with some UI design?


I think there's a lot to do, and that we know enough to do a chunk of 
that.


I think we need to figure out how the basic pieces would fit together.  
For example, if we say we're moving to a plug-in, what GUI details are 
OOoBib specific, and what for third-parties?


In any case we'll need a good (better) interface for citation handling. 
So we need to redesign the mechanism that allows users to insert and 
edit citations.


I think we also ought to rethink the design for the bibliographic 
insertion and formatting in lieu of citeproc and csl.  I will press on 
the OpenDocument TC on my end on this to see if we can get a commitment 
at the file format level that they'll support the CSL style language in 
particular. Once we get that commitment, it becomes easier to be 
confident that that'll in OOo itself.


I'm of the opinion formatting should remain more firmly a part of OOo, 
in other words.  It makes it much easier for third-party developers, 
and ensure openness and consistency in OOo (and indeed beyond, because 
defined as part of  the OD file format!).


One open question is about the record entry and editing GUI.  It needs 
to be completely redone, but the question is, should it be our 
responsibility, or should we leave that to third-parties?  If the 
latter, should we provide a default (at least if we get programmers 
willing to do code it)?


Bruce


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

[dev-biblio] more progress

[Bruce D'Arcus]

FYI, I just heard from one of the Sun OpenDocument TC people.  They
discussed our needs a bit during their meeting today, and he offered
to work with me on a proposal to update the bibliographic metadata
support in the file format.

If past patterns hold, that suggests we'll probably begin work on it
next month, and hopefully wrap it up sometime at the beginning of the
year. This is good because it is happening along with the larger work
on metadata in the file format (the RDF discussion).

More info as it's available.

Bruce

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

Re: [dev-biblio] update (reply to Martha)

[Bruce D'Arcus]

On 9/27/05, Sweet Coffee <[EMAIL PROTECTED]> wrote:

> Does this mean that users would be able to adjust the GUI so that the
> Biblio feature in OOo would be able to collect necessary information
> [determined by the user] based on Citation Style for a document?

What I was talking about there was more basic:  should record entry
and editing functionality be part of OOo (as it is now) or not?

Bruce

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

Re: [dev-biblio] Re: update (reply to Martha)

[Bruce D'Arcus]

On Sep 29, 2005, at 1:51 PM, Dane Weber wrote:


As a user, I will be able to enter footnote, endnote, or inline
citations as I type.  When I enter one of these citations, I can
either select a work from a database I have access to, or I can enter
the work myself.


How would you cite a reference unless it was already in the database?

I suppose I was always assuming you have -- as I think Matthias' GUI 
design study awhile back had -- a panel from which you could drag and 
drop citations onto the document window. You could easily extend that 
model to do useful things like filter your references based on the 
document content.


When I cite from this work again, I can easily select the same work 
and simply change the page (or whatever) cited.


Yes.


Because these citations are dynamic, "Ibid.", first citation, and such
will be handled automatically.  I may also add my own text to the
citations without confounding the system.


Yes, and to most of us this is crucial.  To me the test of how well we 
do is whether it is possible with move between radically different 
styles -- say numeric, author-year, and footnote-based -- with a simple 
change of a style switch, and NO document editing.


If we can do that -- and the design of everything I have worked on 
assumes just that -- then we will have a really excellent system that 
is superior to commercial counterparts.



At the end of the paper, essay, article, dissertation, or whatever, I
can generate a bibliography or "works cited" page that will include
one entry for each unique work that I cited, as well as uncited works
that I wish to have in the bibliography.  This bibliography can be
updated as I continue to revise the document.


Yes.


Is this effectively how the user experience is supposed to work?


Yes again of course.


The rest of what we are trying to do is allow users to grab all of
their bibliographic data from existing databases, right?


Yes.  The plug-in architecture we would like to support would use the 
same mechanism to query, say, the Library of Congress catalog as it 
would to hook up to your bibliographic database, which could be either 
local or remote.


Bruce


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

Re: [dev-biblio] Re: update (reply to Martha)

[Bruce D'Arcus]

To go back to this from Martha:


The key issue for work vs. manifestation is content vs. container --
content always must be in a container to have a physical existence in
the real world!  In addition, the definition of a work is subjective,
esoteric and controversial-- if I do a softcover, a hardcover, and
audiobooks on both tapes and CSs, then I must assign four ISBNs to the
one work-- but another person and I may differ on whether another book 
I

write with almost the same content but targeted to a slightly different
audience (e.g., college vs. corporate) is a different work or a 
derivative.


Yes.


Also, what about an edited book that contains a preface and summary by
the editor and 10 other chapters by different authors?  Is the book the
editor's work that also contains the works of other authors?  The
problem is even more complex when multi-media content is added to the
database -- what is the "work" for a song? -- the lyric, the melody, 
the

arrangement, some combination of them, etc.


Well, it also solves problems because you group records under a common 
work.  You can say, for example, that all of these share the same 
Beethoven Symphony work:


the original score (a textual expression)
	some 1980 performance by some symphony somewhere (a sound/musical 
expression)


You can then go on to say that the latter has a variety of 
manifestations; say:


a live radio broadcast in 1980
a 1981 LP recording
a 1985 digital CD

... etc.

The FRBR helps in circumstances like that.  In more textual stuff, it 
helps to handle stuff like translations.


Still, it's worth noting that the vast majority of the works I store 
have a single expression, and that citation practice happens at the 
manifestation level. So it's an open question whether it's rigor is 
necessary here.


Bruce


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

Re: [dev-biblio] question: in the meantime...

[Bruce D'Arcus]

On Sep 30, 2005, at 3:56 AM, John Norvell wrote:

Thinking of being able to easily convert to the eventually released OO 
bibliography component (which seems to be getting closer -- I've been 
following this list and all your hard work for years now :-), what 
would be the best in-the-meantime way to store my data and exploit...I 
mean employ this student? I was thinking about Bibus and MySQL (on 
Linux).


I wouldn't worry too much. The primary criteria you should look for is 
that it have good import/export support for a standard format like RIS, 
and that the app otherwise works for your needs. It depends what sort 
of material they'll be entering.  If it's just journal articles, you 
could even have then use an online service like CiteUlike or Connotea.


Bruce

PS - Hmm .. I've got a work study student this term; I just got an idea!


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

[dev-biblio] citation examples?

[Bruce D'Arcus]

In an effort to document the metadata needs for this project I've 
started to put together a document that shows examples of some of the 
more difficult real world citation styles.  So far these are from the 
humanities, as I find citation needs there more demanding, and 
generally poorly handled by software.


Current (quite short) example is here:



It'd help if others could track down similar examples -- preferably 
nicely rendered PDFs -- and send them to me.  Basically I want to show 
the sort of improvements we need for the project; not already-covered 
citation needs. So edge cases are valuable.


Incidentally, the document above shows an example of reference grouping 
that I'm still not sure how to tackle from either a GUI or a style 
language perspective.  I suppose one might name groups, which are 
defined in the style, and then configure their order and such in the 
GUI (?).


Bruce


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

[dev-biblio] styling design question

[Bruce D'Arcus]

Hi,

I've been talking to the OpenDocument people about the possibility of 
including the citation style language (CSL) I designed in OpenDocument 
in some form.


http://xbiblio.sourceforge.net/csl.html

One issue they raised is that it doesn't really make use of the OD 
styling infrastructure.  So I've been experimenting a bit with what it 
might mean to bring them closer in line.


Basically, it would primarily mean moving a lot of element content into 
attributes.  This fragment, for example, is about 75% more compact than 
my current schema, and more in line with an OD approach:














OK, so it's a lot more compact (and probably faster to process as a 
result).  What we give up with this approach is any possibility to add 
markup to attribute content.  So for example, current OOo code to 
handle prefixes and suffixes for citations is handled in attributes.  
Hence, they can only ever be strings effectively.


Is that a reasonable tradeoff?  How much of a compromise would it be 
worth it to get this into the OD file format?


And thinking about the document I posted the other day, how would 
people imagine configuring the styling for the example which has:


author name
... citation 1 ...
 citation 2 ...

In other words, how would you see configuring a GUI such that you 
indicate that a) citations should be grouped by author, and b) that the 
group ought to be labeled with the author name, followed by a paragraph 
break? It might have bearing on the above.


Bruce

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

[dev-biblio] Re: styling design question

[Bruce D'Arcus]

On Oct 3, 2005, at 9:48 PM, [EMAIL PROTECTED] wrote:

How does the question you raised for the GUI in this email differ from 
needing to cluster citations for any other reason?


You're right they're the same issue.  I was just trying to give a 
concrete example that people could look at.


But actually, there may be a slight difference with this one because 
one is actually using citation content (author name) in the grouping, 
where in other cases the grouping is different (by genre, for example).


In any case, was just trying to image how one would do a config GUI for 
that.


Bruce


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

Re: [dev-biblio] styling design question

[Bruce D'Arcus]

Hi Peter,

On Oct 6, 2005, at 2:38 AM, pt wrote:


(I'm new here. I work for the University of Southern Queenland on an
Australian government funded project to do with repositories, and on
an open source content management system for courseware, which is
tightly integrated with OpenOffice.org. More about those another
time.)


Excellent!


1. Will there be conditional logic required? Eg if element a exists
then output b,c else output d. This sort of thing makes a CSL GUI very
hard to design.


There is some conditional logic there already, but it's pretty simple.  
For example:


  

  

And a similar approach works for handling stuff like substituting 
"Anonymous" instead.


Likewise, I do some tricks to enable something similar when I have 
something like this:


  


   (
  ).


  

... and then elsewhere do:


  
tran.
trans.
  


That means:

if creator.role = translator then
if single print tran.
else print trans.

That goes a long way and is easy to do in a GUI, and I don't favor 
going much further.



(Do we really need a GUI? for citiation and
bibliography formats most users will be consumers of preset formats,
not creators.)


This is indeed a question. What I think would be the ideal circumstance 
is to have an online repository of CSL files where a user could 
download (either via browser or web service) the styles they needed. 
Those styles would ideally be provided by the institutions that specify 
them.


However, as that's unlikely in all cases, nicer still would be if that 
repository also had a nice -- AJAXified -- CSL creation and editing 
GUI.  For the most part, users would be creating new styles by 
trivially modifying existing ones.  I don't pretend that's easy, but I 
have designed CSL with that in mind.


It's worth noting the Endnote style repository has over a 1000 of them!


2. What are the chances of getting it into OpenDocument in a political
sense? I have no idea about what would be involved but I can imagine
it could be hard work, and difficult to get heard.


We have a pre-existing relationship with them (I wrote a 
citation-coding proposal with one of their engineers awhile back, and 
they accepted it), so it's not hard from the standpoint of being heard. 
 They respect my expertise here.


The problem is more to fit it within their charter and design goals. I 
don't think Michael Brauer (the TC chair) would object to my quoting 
him here:



The situation here is similar as for the bibliographic data schema. The 
OpenDocument TC may include CSL into OpenDocument, but it is in my 
opinion not covered by the TC's charter to standardize CSL itself. 
However, other file format of cause could reuse OpenDocument's citation 
style, and applications may support OpenDocument's citation style 
without supporting OpenDocument itself.


I'm open for a discussion to include CSL into OpenDocument, but the 
concerns that I have with the current CSL schema is that it defines its 
own formatting properties but does not reuse OpenDocument's. This in my 
opinion would break OpenDocument's paradigm to have one schema for one 
concept.

=

So as you can see, there are some challenges here, but it's a 
possibility they're willing to consider. My questions about refactoring 
CSL a bit were with this in mind. They already have bib style config in 
the file format; it's just really limited.



This is only an idea, but both of these considerations made me think
of leveraging XSLT. If there is  a need for conditional elements, then
we could use XSLT's xsl:if and xsl:choose, rather than inventing new
machinery - ie add if and choose to CSL and be guaranteed of easy
implementation using XSLT.


You can think of CSL as a dedicated templating and parameter-setting 
language.  I have had people tell me it's a bad idea to try to create 
this language-independent style, and that I should have just used a 
full language like XSLT.


But I really don't like this idea, as to me language-independence is 
really important here. I really want to see citeproc-py or citeproc-pl, 
and to see people implement it for use with LaTeX or RTF.  I think it's 
a mistake to do the lower-level approach (as in BibTeX, or some of the 
Perl-based approaches; indeed I just talked to a guy who wrote one of 
the latter, and was actually looking for something like CSL to replace 
his Perl-based styling code).


There's also the issue that this stuff is hard to do in XSLT 1.0 in 
particular (though if you guys want to try and prove me wrong that'd be 
great!) ...



And it also occurred to me that maybe it would be possible to ship
XSLT with an OD document. So instead of including a CSL spec, one
could ship an XSLT derived from a CSL spec that would operate on the
content. So OOo would not have to know a

Re: [dev-biblio] styling design question

[Bruce D'Arcus]

BTW, there's a Mac developer that's been experimenting with a CSL GUI.
 I blogged about it here:



Bruce

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

Re: [dev-biblio] styling design question

[Bruce D'Arcus]

Just another quick followup:

The Mac developer that had started with mockups for a CSL 
editing/creation app has since gone further and has a full (if 
incomplete) working application.


So it seems like it is well-suited to a GUI (it only took him a couple 
of days).  I will work with him to see where we can tweak things to 
make it easier still.


One thing I still could use help on from those wanting to contribute 
and comfortable with XML is testing with real-world styles.  I've done 
APA and Chicago (both of which are somewhat complex) and a few others, 
but I only have so much time to test this myself.


BTW, I'll be presenting on the bib project at the Access 2005 
conference in Edmonton in just over a week.


Finally, for those (me included) who have been a little frustrated by 
the slow pace of obvious progress, this note from one of the Sun people 
might be encouraging:


I always believed, that the bib project has the power to investigate 
and introduce new technologies in OOo and OpenDocument and I am very 
happy, that you see it the same way.
Altough your project may slow down a little bit, because the new 
technologies have to be discussed by many people, I believe, that this 
is worth it.


Bruce


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

Re: [dev-biblio] citation examples?

[Bruce D'Arcus]

On Oct 9, 2005, at 2:18 AM, David Wilson wrote:

This seems to  imply the need for allocating reference texts to user 
defined
sorting-groups, and the user specifying  sort-groups and the sorting 
criteria

within the groups.


Yeah, I just don't know the best way to do this.


I could supply short sample from the thesis if  you want.


No, that's fine.  I'm aware of the issue.  I know of others examples 
where people have separate groups for legal cases, for newspaper 
sources, etc.


Bruce


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

[dev-biblio] Fwd: previous discussions with Daniel V. on bib details and moving forward (was Re: namespaces)

[Bruce D'Arcus]

Some background on some of the discussions we've been having recently 
(and a hint of why things are sometimes slow!). Below is a note I sent 
earlier today to some of the Sun developers working on SW, XML and 
OpenDocument. Unfortunately, I learned yesterday that Daniel 
(Vogelheim) recently left Sun, which is a big loss. In any case, this 
gives a sense of the technical direction that we hope to take.  
Daniel's a sharp guy, and we were in complete agreement on all this.


Peter, I presume the glue code that Daniel mentions towards the end 
could also be done in Python ...


Begin forwarded message:

Am still hoping for responses from Sun people to my list posting on 
SW/XML dev. I suppose I'm leaning toward the notion of not worrying 
about adapting CSL to OD, and maybe later thinking about import/export 
support. But whatever the case may be, there needs to be changes 
somewhere in OD to make the functionality we want possible, and we 
need to make some progress on figuring them out.


BTW, am looking through some emails from Daniel earlier.  A few 
relevant excerpts:


First, about OD; on notion of embedding bib metadata in wrapper (this 
when we were earlier thinking of using MODS; RDF changes this, but the 
same idea):


Thinking farther out, how do we imagine including the bib data 
source?  I could see embedding a bibliography.xml file in the 
wrapper optionally.  If yes, does that in any way get controlled?


We're wanting to use MODS, of course, and there would be value in 
standardization.


Full agreement on the bibliography.xml stream in the wrapper. And 
yes, for interoperability this should be standardized as well. Since 
I don't really know about bibliography data, I'm fine with MODS. I'm 
sure the TC would go along as well, since MODS is standardized.


To me is this is the most important issue to tackle now, and this is 
OD territory. WRT to the RDF question, I would say RDF is also 
standardized (as a model).


On details of integration (from last August; Oliver mentioned 
something like this more recently):


To go back to this subject -- how the actual formatting might happen 
-- what's your perspective now?


The same, really. As I've mentioned in another mail, the part that 
reads the bibliography entry and stores it in the document does not 
yet exist.


There's semi-good news on that part, in that I brought the subject up 
with another Writer developer (who's got more say than I do). He 
agreed on the approach, and essentially said we'd need such a 
mechanism anyway for all sorts of extensions. So there's a good 
chance we'll do that eventually. It will likely be in the 
help-to-self-help form, in that we'll provide some kind of mechanism 
for external components to hook into writer and be responsible for 
certain kinds of embedded data. Such components would still need to 
be written by non-Sun people. The bad part is that the chances we do 
this now are close to zero.


I ask because I've decided to start working on my own solution using 
XSLT 2.0.  The stuff could probably be ported back to 1.0, but it 
turns out to be rather complicated problems that need to be solved.  
For example, to get this rendering is deceptively complex, and 
involved create a virtual tree of the entire bibliography:


(Doe, 1999a, 1999c)


Sounds fine. Since right now full runtime integration isn't likely to 
happen, I don't see any problem in using XSLT 2.0. I would hope that 
in the next version (OOo 2.1 or something) XSLT 2.0 would be 
available. But that of course depends on the adoption of XSLT 2.0 by 
other parties. We just hook into other people's XSLT processors.


Note: on above, there's a developer in Australia looking at porting 
citeproc to Python + XSLT 1.0, so that may be a possibility.


Later, on possible glue to integrate citeproc-like XSLT processing:

To provide a straw-man of what I *hope* it would look like: There is 
some OOo glue (C++, Java, StarBasic) which would basically look 
something like this:

xBibs = new com.sun.star.xml.dom.XDocument
xFields = xDoc.getFields.getEnumeration
while( xFields.hasMoreElements )
  xField = xFields.nextElement
  if( xField is bibliographic field )
xBibs.appendNode( xField.content )
' now we have a DOM tree with all bibliographic reference
call XSLT-processor on xBibs
' now write back results
xFields = xDoc.getFields.getEnumeration
while( xFields.hasMoreElements )
  xField = xFields.nextElement
  if( xField is bibliographic field )
xNode = find-proper-node( xBibs )
xField.representation = set representation from xNode

How that makes any sense to you... The acutal work would be in the 
'call XSLT-Processor' line. The remainder would be the OOo-specific 
glue. I don't think we'd get by without it completely. Ideally, with 
some care, the same XSLT could be used for off-line processing, i.e.:

unzip -p bla.sxw content.xml | xsltproc bib.xslt > content.xml


This just gives a hint of what I've been saying: I've gone over and 
over 

Re: [dev-biblio] Fwd: previous discussions with Daniel V. on bib details and moving forward (was Re: namespaces)

[Bruce D'Arcus]

pt wrote:


I thought I had an idea of how it might work with in-text citations
that were essentially tokens referencing a bibliographic data store,
but the psuedo code below seems to imply that the full bibliographic
record would be in the citation. Or am I misreading it?


The plan has been that citations just become pointers to external 
bibliographic records; "external" in relation to content.xml, but still 
in the file wrapper.  So the bibliographic store would be internal to 
the file.  Otherwise the model is the same as the current DocBook 
processing, with the sole difference that the results of the 
transformation need to get inserted back into the citation elements. 
This is what the glue would do; collect the citations, an use them in 
conjunction with the bib data to run the file, and insert the results back.


That doesn't mean there isn't a general bibliographic database too. It's 
just that when one inserts a citation in a document, one is both adding 
the pointer, and the bibliographic record.


In the past, we had thought that would be an optional relationship; that 
a user could choose to embed, or not.  I think that's not a good idea 
for a variety of reasons, and that it should be mandatory.


Bruce

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

Re: [dev-biblio] Fwd: previous discussions with Daniel V. on bib details and moving forward (was Re: namespaces)

[Bruce D'Arcus]

James Howison wrote:

One option would be to keep the database linkage in the record and at 
'styling' time (ie when the record is converted to text) to allow it to 
hit the database if possible and look for changes, then prompt the user 
if they want to have those changes apply to the current citation.


Yes. Or perhaps if one chooses to edit the record from a menu from the 
already-rendered bibliography, it knows to come back and reinsert the 
record.


In any case, it shouldn't be hard to generate that embedded metadata; 
just scan for the citations, extract from data store, and embed them.


Bruce

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

Re: [dev-biblio] Fwd: previous discussions with Daniel V. on bib details and moving forward (was Re: namespaces)

[Bruce D'Arcus]

pt wrote:


2. I think it would be worth setting out in some detail the
relationship between in-text citations, a bibliography and a data
store and CSL showing what these might look like in the OpenDocument
format and associated processing applications.


I've put together a basic diagram here:



So citations belong to content.xml, bibliographic metadata gets its own 
file, and I suppose it'd be sensible to embed CSL into the styles.xml 
file (though this would be the trickier, and more contentious, issue).


As Daniel noted, it should be possible to run the same XSLT on the file 
archive from an outside XSLT process.


Not sure I quite have the style connection right.  It could be that it 
points directly to the XSLT.


Bruce

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

[dev-biblio] python-uno bridge status?

[Bruce D'Arcus]

For those of you doing any work with Python, could you perhaps update 
me on the status of the Python support in OOo, particularly with 
respect to the UNO bridge?  Rob has reported it was basically unusable 
awhile back.  Am just wondering if that has improved with 2.0, or if we 
need to do some work to promote getting that fixed.


Bruce


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

Re: [dev-biblio] python-uno bridge status?

[Bruce D'Arcus]

On 10/15/05, Robert Sanderson <[EMAIL PROTECTED]> wrote:

>  3) Importing binary packages often failed, even if they were
> distributed with the OOo python (eg socket, regular expressions, etc)
> Joerg's response was:  The std library is not my problem.

I've been learning that the "not my problem" response means one needs
to find the person above them that controls the purse strings.

> Not sure if this has been fixed or not.

This would be good to know; what, if anything, has improved with 2.0.

Bruce

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

Re: [dev-biblio] Open Office Bibiliographic idea

[Bruce D'Arcus]

On Oct 15, 2005, at 1:38 PM, Chard Roberts wrote:


Hello OpenOffice Team!


Hi Chard. Thanks for the suggestion!

(please note: I have not used Endnote and Reference Manager so I am 
not too sure if these ideas fringe on copyright.


Very little in Endnote or Reference Manager is unique. Their data 
models and formats are based on open source precedents like Refer, and 
their processing models seems to have been borrowed at least in part 
from BibTeX.  So I've no worries there ;-)


There would be one needed for each style of reference (e.g. books, 
articles, magazines, internet etc.), footnote (e.g. so XYZ with a 
reference to the reference list), secondary tags (e.g. so Smith, 1999 
etc.), the reference table at the end of the document – in 
alphanumeric listing etc. etc.  


Due to the known number of fields, and as to how they should be 
written e.g. italics, bold etc. these can be set as needed.


Am not totally sure what you're proposing, but see if it's something 
like this project I wrote:





We're working to incorporate it in some form in OOo.

Bruce

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

[dev-biblio] conference talk

[Bruce D'Arcus]

FYI, I'm at a library IT conference, where I was invited to speak.  I
talked about this project and how we're trying to shape larger
discussions about metadata in OOo and OpenDocument.



Bruce

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

Re: [dev-biblio] Mandatory embedding

[Bruce D'Arcus]

On Oct 18, 2005, at 9:15 AM, [EMAIL PROTECTED] wrote:

So if the embedding is mandatory, how will the user deal with parts of 
the database record (such as personal or proprietary comments 
regarding a work) that are NOT to go with the document to other 
people?


Just define certain content as either not embedded at all (notes, for 
example, which are not needed for formatting or finding), or optionally 
so.  I think notes should probably be stored with flags about their 
access status in any case.


Bruce


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

[dev-biblio] styling plan

[Bruce D'Arcus]

OK, on the plane-ride back from Edmonton yesterday, I think I've 
figured out a plan to solve the styling problem:


I am going to push the OD TC to take up two proposals:

1)  the details of the bib metadata model and storage (this is 
dependent on current discussions around metadata in OD)

2)  the styling

WRT to the second, I've decided it's a waste of time to worry about CSL 
per se too much.  We can instead provide surgical modifications to the 
OD styling support and get the same functionality (which is what 
matters most).  If we need to do CSL import/export later because it's 
being taken up outside OD/OOo, then that should be easy enough. Indeed, 
I created an XSLT that can convert CSL files to results like this:


  
text:use-first="6">et al.
text:min-authors="6" text:use-first="1">et al.


  
  
  

  

So I think I will propose enhancing an existing element in the 
styles.xml file (text:bibliography-configuration), and adding a 
citation analog (the above example).


There is one possible wrinkle in this, though.  The above collapses 
what is currently handled in two places in OD: in the styles file and 
the content file (in some "index" related code). It just may be a 
problem because it would mean me deviating from current approaches in 
OD.  I do think my approach is better though, so ...


Anyway, below are the bib-related schema fragments from the current 
spec, which I've converted to the RNG Compact version (easier to edit; 
at least for me).


# first the citations; this div is already getting replaced
div {
  element text:bibliography-mark {
attribute text:bibliography-type { text-bibliography-types },
attribute text:identifier
  | text:address
  | text:annote
  | text:author
  | text:booktitle
  | text:chapter
  | text:edition
  | text:editor
  | text:howpublished
  | text:institution
  | text:journal
  | text:month
  | text:note
  | text:number
  | text:organizations
  | text:pages
  | text:publisher
  | text:school
  | text:series
  | text:title
  | text:report-type
  | text:volume
  | text:year
  | text:url
  | text:custom1
  | text:custom2
  | text:custom3
  | text:custom4
  | text:custom5
  | text:isbn
  | text:issn { \string }*,
text
  }

# bib types
text-bibliography-types =
  "article"
  | "book"
  | "booklet"
  | "conference"
  | "custom1"
  | "custom2"
  | "custom3"
  | "custom4"
  | "custom5"
  | "email"
  | "inbook"
  | "incollection"
  | "inproceedings"
  | "journal"
  | "manual"
  | "mastersthesis"
  | "misc"
  | "phdthesis"
  | "proceedings"
  | "techreport"
  | "unpublished"
  | "www"
}

# bibliography content

text-bibliography =
  element text:bibliography {
sectionAttr, text-bibliography-source, text-index-body
  }
text-bibliography-source =
  element text:bibliography-source {
text-index-title-template?, text-bibliography-entry-template*
  }
text-bibliography-entry-template =
  element text:bibliography-entry-template {
text-bibliography-entry-template-attrs,
(text-index-entry-span
 | text-index-entry-tab-stop
 | text-index-entry-bibliography)*
  }
text-bibliography-entry-template-attrs &=
  attribute text:bibliography-type { text-bibliography-types }
text-bibliography-entry-template-attrs &=
  attribute text:style-name { styleNameRef }

# ??

text-index-entry-bibliography =
  element text:index-entry-bibliography {
text-index-entry-bibliography-attrs
  }
text-index-entry-bibliography-attrs &=
  attribute text:style-name { styleNameRef }?
text-index-entry-bibliography-attrs &=
  attribute text:bibliography-data-field {
"address"
| "annote"
| "author"
| "bibliography-type"
| "booktitle"
| "chapter"
| "custom1"
| "custom2"
| "custom3"
| "custom4"
| "custom5"
| "edition"
| "editor"
| "howpublished"
| "identifier"
| "institution"
| "isbn"
| "issn"
| "journal"
| "month"
| "note"
| "number"
| "organizations"
| "pages"
| "publisher"
| "report-type"
| "school"
| "series"
| "title"
| "url"
| "volume"
| "year"
  }

# styling

text-bibliography-configuration =
  element text:bibliography-configuration {
text-bibliography-configuration-attlist, text-sort-key*
  }
text-bibliography-configuration-attlist &=
  attribute text:prefix { \string }?,
  attribute text:suffix { \string }?
text-bibliography-configuration-attlist &=
  [ a:defaultValue = "false" ]
  attribute text:numbered-entries { boolean }?
text-bibliography-configuration-attlist &=
  [ a:defaultValue = "true" ]
  attribute text:sort-by-position { boolean }?,
  attrib

Re: [dev-biblio] Mandatory embedding

[Bruce D'Arcus]

On 10/20/05, James Howison <[EMAIL PROTECTED]> wrote:

> I'm coming around to the view that notes should probably be their own
> publications,

How about just "objects"?

> linked to the publication they are commenting on.  That
> just seems much more flexible to me.  Then you could include the link
> to the note, but even if it travelled only the owner would be able to
> access the database (unless one wanted to make the note public, easy
> to take it private again.)

Yup. From a relational perspective notes in this case should
definitely not just be attributes of a reference.

Bruce

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

Re: [dev-biblio] Workflow for citing

[Bruce D'Arcus]

Just a quick note (am in a hurry) that this is interesting Peter. 
It's similar to my blog post about "distributed citation processing"
from a little while ago. This does get at the issue of thinking
through identifiers.

On 10/27/05, pt <[EMAIL PROTECTED]> wrote:
> I've been working on a technical report in OpenOffice.org which will
> eventually require a proper bibliography but I have no idea how I
> might make that when the time comes.
>
> The following workflow has occurred to me.
>
> As I write, I've been making hyperlinks to various web resources, lots
> of government pages, but a few refereed papers from various sources.
> This is fine while I'm in draft mode and the document is usable and
> sharable.
>
> Later, when I want to publish it more formally it would be great if
> some software could find all my links and for each one look for a
> bibliographic reference in my local store (whatever that might be) and
> if there is none search other places that might have bibliographic
> data linked to that URL. If no data can be found it would add an entry
> to my database with as much data as  it could pre-set (eg title may be
> able to be scraped from an HTML page) so I can fill out the rest. Once
> I have entered the data locally it should be aggregated 'up' to my
> workgroup / institution.
>
> Everything I want to refer to in the report I'm working on now is
> available on the open web, but I could refer to books, say, by
> pointing at the local campus library system on the web (with some
> convention for page references) and that should be enough for smart
> software to automatically grab the details for my bibliography later.
>
> This is like the idea of adding a citation by reference but without
> needing a formal ID. It's like the EndNote 'cite while you write'
> somewhat backwards, with citation coming long before 'proper' data
> capture.
>
> To support this I'm thinking that I want a personal version of an
> Institutional Repository, with a full text copy of as much as possible
> of what I cite, not just a bibliographic database. So the
> bibliographic software would fetch stuff that I refer to an archive it
> for me in case it moves or disappears.
>
>
> --
> Peter (pt) Sefton
> Toowoomba 4350
> Queensland, Australia
> Phone: +61 4 1032 6955
> Web: http://ptsefton.com
> Email: [EMAIL PROTECTED]
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

Re: [dev-biblio] OpenURL - what does it mean for this project?

[Bruce D'Arcus]

On Oct 30, 2005, at 11:02 PM, pt wrote:


I wrote a few days ago about using URLs of some kind of as in-text
citation tokens for drafting documents. Easy enough to write about,
but implementation poses some major challenges. I tried working
through what the workflow would be like if I linked to a paper from
someone's Institutional Repository - what then? Would I be able to
find the bibliographic data for that item. So far the results have not
been encouraging.

Which leads me to OpenURL - what's the feeling about how relevant it
might be to bibliographic software for OpenOffice.org?


Peter, I'm no expert on OpenURL, having only ever looked at it briefly. 
 I'm cc-ing Dan Chudbov, though, who knows a lot more.


My take is this:

OpenURL is trying to solve a different (if related) problem than what 
we're concerned with in citations. OpenURL primarily allows one to find 
specific items. So, given journal article metadata in a specific form, 
OpenURL resolvers will find you physical and/or electronic copies you 
have access to.


Our needs are slightly different (or least broader). We need to be able 
to unambiguously associate in-text content to its source, whose 
metadata we use to precisely format the bibliographic entry to allow a 
reader to achieve something like OpenURL: find a copy.


But linking to metadata rich enough to format those references is 
essential for us.  And we need a solution more general than for 
contemporary journal articles, given we may have users who are medieval 
historians.


I've been talking to some RDF experts from Nature, Ingenta, etc. about 
various issues, including this business of identifying citations, and 
it seems to me that discussion is leaning towards a solution where 
records per se are not identified (in RDF language, they become "blank 
nodes"), but that they may contain various identifiers that can be used 
for association. So perhaps a journal article might contain both a DOI 
and an OpenURL (?).  A citation in the document would then contain a 
single identifier (indeed, the proposal accepted last year only allows 
one) that would allow the citation processor to find the right metadata 
item.


Bruce


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

Re: [dev-biblio] Bibshare

[Bruce D'Arcus]

On Nov 6, 2005, at 10:14 AM, Matej Cepl wrote:

... but later (with support of Microsoft Research!) it developed into 
something much more

resembling current Bruce's thoughts of the remote database driven
references . Unfortunately, I haven't 
used it

(not having Windows here) and copyright status of the thing is unknown
(especially, suspicious if M$ Research was involved; but, originally 
they

provided source code).


I talked to them way back. The code is closed source, and I don't think 
it's very well designed anyway ;-)


But definitely related; thanks!

BTW, my thinking has been changing a bit lately, and I'd like to embed 
the CSL logic directly into ODF.  So in that case you have -- WRT to 
OOo -- distributed metadata, but document-level formatting.


Bruce


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

[dev-biblio] metadata update

[Bruce D'Arcus]

Just a quick update:

Long story here, but the short take-home point is that I'll be leading  
an effort -- hosted by the new OpenDocument Fellowship -- to design a  
proposal to significantly enhance metadata support in OpenDocument.  
That proposal will formalize the ideas I laid out here:





So the idea will be to use an integrated approach to all metadata in  
ODF, including figures, tables, formulas, charts ... and bibliographic  
references.


I've talked to two OD TC members about this, and they're supportive  
(indeed, one of them suggested it).


Interesting times ...

Bruce


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

[dev-biblio] correction

[Bruce D'Arcus]

I meant this:




Bruce


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

Re: [dev-biblio] metadata update

[Bruce D'Arcus]

On Nov 12, 2005, at 4:39 PM, David Wilson wrote:

This is great news - indicative of the growing support for Bruce's 
innovative

approach to  metadata support in OpenDocument - which is central to the
sucesss of our bibliographic project.


FYI, wiki and list info here:

http://opendocumentfellowship.org/Metadata/HomePage


Bridging Worlds: Library IT and Free Software


Actually, I changed the title; I think it was "OpenDocument, OpenOffice 
and Metadata".


Bruce


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