[dev-biblio] Minimal Target

2006-04-04 Thread Matt Price
Hi Folks,

I've just been going through the list archives  some ofthe wiki
documents  trying to figure out some priorities for all this work that
lies ahead. Seems to me it would be useful to define several targets --
say minimal, intermediate, and polished and lay out what needs to
be done for each.  We have a number of descriptions of ideal-world
functionality, and I'd like to see more discussion of how to get there.
THis would perhaps help in the identification of roadblocks. 

So what follows is an attempt to define a minimal target.  My general
ignorance about e.g. the state of the OASIS file format negotiations and
the level of flexibility within the currently available OASIS framework,
will doubtless be evident.  

SO, tell me if you think it's a useful document.

Minimal Bibliographic Interface 

Target Goals:  Allow expert users to insert useful citations by (a)
creating durable citation infrastructure within sw; (b) designing a new
bibliographic database structure; (c) creating a minimal interface which
uses citeproc to link (a) and (b).  

Obviously missing functionality:  aiblity to create and modify database
directly within OOo.  It is a ssumed that database management per se
will take place through an existing interface (endnote, bibus, or the
like) and be funnelled through some kind of filter to produce a native
bibliography.  

Tasks:

(1) Modify the sw code to enable citation data to be saved and
displayed, to making citations avialable by UNO hooks. (these are CPH's
'1-4' of an earlier post.)  Assigned to CPH.

(2) Complete design of database.  Not assigned

(3) port Citeproc to python. Not assigned.
-
1-3 can be worked on simultaneously and starting from now, I reckon.
-
(4) build filters to generate database records and xml/rdf metadata
records from MODS datasets.  THis might be conceived as an extension to
bibutils?

(5) build a UNO application that provides a graphic user interface to
the bibliographic data, allowing insertion and (per-document) formatting
of citation data).  This involves 

-
4 will probably be tricky in its particulars but it might be possible to
get something basic off the ground quite quickly.  

5 seems to me a good candidate for a Summer Of Code or other ambitious
programming project.  It would be nice to have the supporting framework
in place for any ambitious individuals wanting to make a push.  


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



Re: [dev-biblio] Minimal Target

2006-04-04 Thread Bruce D'Arcus


On Apr 4, 2006, at 3:46 PM, Matt Price wrote:


Seems to me it would be useful to define several targets --
say minimal, intermediate, and polished and lay out what needs to
be done for each.


Sure.


Minimal Bibliographic Interface

Target Goals:  Allow expert users to insert useful citations by (a)
creating durable citation infrastructure within sw; (b) designing a new
bibliographic database structure; (c) creating a minimal interface 
which

uses citeproc to link (a) and (b).

Obviously missing functionality:  aiblity to create and modify database
directly within OOo.  It is a ssumed that database management per se
will take place through an existing interface (endnote, bibus, or the
like) and be funnelled through some kind of filter to produce a native
bibliography.


I'm a little confused here. I would say minimal support might be able 
to throw out the database altogether and provide an API to plug-in 
different reference management solutions.


Is that what you are saying, or are you saying that database management 
should be part of this minimal support?


So for me the different levels would support:

minimal

1)  new citation coding
2)  formatting processing via citeproc (or equivalent)
3)  API for third-party access (inserting citations)

intermediate

adds:
4)  local database
5)  full new editing GUI for 4

advanced

adds:
6)  more advanced remote functionality (ZOOM; though this might relate 
to 3 above, and probably should)



Tasks:

(1) Modify the sw code to enable citation data to be saved and
displayed, to making citations avialable by UNO hooks. (these are CPH's
'1-4' of an earlier post.)  Assigned to CPH.

(2) Complete design of database.  Not assigned

(3) port Citeproc to python. Not assigned.
-
1-3 can be worked on simultaneously and starting from now, I reckon.
-


Correct. One thing we have to decide now is the relationship between 
data and formatting. If the data source for formatting is embedded 
XML/RDF, then the database per se becomes less critical.


[note: I see you just posted something on this Matt; will probably 
respond there]



(4) build filters to generate database records and xml/rdf metadata
records from MODS datasets.  THis might be conceived as an extension to
bibutils?


Yeah, and I might be able to see if Chris can help us on that.

However, I'd put the above slightly differently in that MODS datasets 
are one possible input format. By using something like bibutils, we 
also get support for RIS, Refer/Endnote, BibTeX, etc.



(5) build a UNO application that provides a graphic user interface to
the bibliographic data, allowing insertion and (per-document) 
formatting

of citation data).  This involves


...?


-
4 will probably be tricky in its particulars but it might be possible 
to

get something basic off the ground quite quickly.

5 seems to me a good candidate for a Summer Of Code or other ambitious
programming project.


Yes.

Bruce

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



[dev-biblio] Re: embedded references/functional requirements wiki page

2006-04-04 Thread Matej Cepl
Bruce D'Arcus wrote:
 my question: what is lost when info is embedded rather than fetched?
 
 Not much.

Synchronization with further modifications of the database -- when I open
five years old document, I would like it to reflect all updates and
corrections I made into my central bibliographic database in meantime.

Matej

-- 
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
http://www.ceplovi.cz/matej/blog/, Jabber: [EMAIL PROTECTED]
23 Marion St. #3, (617) 876-1259, ICQ 132822213
 
I believe in the power of prayer. It's been said: I would rather
stand against the cannons of the wicked than against the prayers
of the righteous. The prayers of a friend are one of life's most
gracious gifts.
-- George W. Bush at the 2001 National Prayer Breakfast


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



Re: [dev-biblio] Minimal Target

2006-04-04 Thread Matt Price
On Wed, Apr 05, 2006 at 08:42:30AM +1000, David Wilson wrote:
 Matt,
 
   In the the developer Page 
 ( 
 http://wiki.services.openoffice.org/wiki/Bibliographic_Project's_Developer_Page
  ) 
 Stage 1, was intended as the 'minimal' requirement. And Stage 2 as the 
 intermediate . I can see it would be better to state this as a clear 
 objective.

ah.  that's really excellent, thank you.  This also pointed me to
wiki/Bibliographic_Document_XML_Format which I had skimmed over
before, but is now much clearer to me.  I have to say the changes to
the file format look so simple and manifestly superior to the current
setup that it's astonishing they haven't been approved yet.  

 
 Your suggestions are good so I will have a go at re-working the page with 
 Bruce's and your comments.
 
 I agree with Bruce the OOo database is not a minimal requirement. I like the 
 idea that the OOo database would behave like any other Internet data source.
 If we built the DB interface to work via Zoom / Z39.50 interfaces direct to 
 internet sources - (library catalogues, etc) then the Internal OOoBib 
 database becomes more complex to build because we would need to build a 
 Z39.50 server for it as well, or other programming to make look as if it was 
 working behind a such a server. 
 

I see you and Bruce are not of one mind about this, I can't say I know
enough to have an opinion.  

 Also CiteProc is working right now using data stored in an eXist xml 
 database. 
 The quickest way to build something that works would be to build a xforms 
 based browser to work with eXist and a function to inset the selected 
 citation into Writer. 
 

I know nothing about Xforms.  Is this something that could be built,
as it were, from within OOo?  Or are you talking about a separate
application?  

sound in any case as though the minimal target is not quite so far
away as I'd htought, which is very good news of course.  

Matt

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



Re: [dev-biblio] Minimal Target

2006-04-04 Thread Bruce D'Arcus


On Apr 4, 2006, at 9:58 PM, Matt Price wrote:


ah.  that's really excellent, thank you.  This also pointed me to
wiki/Bibliographic_Document_XML_Format which I had skimmed over
before, but is now much clearer to me.


FYI, I just changed the bib example to reflect the current direction of  
where I hope ODF is headed:


http://wiki.services.openoffice.org/wiki/ 
Bibliographic_Document_XML_Format#biblo-data.xml


I have to say the changes to the file format look so simple and  
manifestly superior to the current

setup that it's astonishing they haven't been approved yet.


Well, big companies move slowly, and they don't want to make changes  
specific to our project when more general solutions can be found. Those  
take time.


Also CiteProc is working right now using data stored in an eXist xml  
database.
The quickest way to build something that works would be to build a  
xforms

based browser to work with eXist and a function to inset the selected
citation into Writer.



I know nothing about Xforms.  Is this something that could be built,
as it were, from within OOo?  Or are you talking about a separate
application?


OOo has built in XForms support in 2.0. The problem is it's really  
designed for end users.


Bruce

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



Re: [dev-biblio] Minimal Target

2006-04-04 Thread David Wilson
On Wednesday 05 April 2006 1:02 pm, Bruce D'Arcus wrote:


  Also CiteProc is working right now using data stored in an eXist xml
  database.
  The quickest way to build something that works would be to build a
  xforms
  based browser to work with eXist and a function to inset the selected
  citation into Writer.
 
  I know nothing about Xforms.  Is this something that could be built,
  as it were, from within OOo?  Or are you talking about a separate
  application?

 OOo has built in XForms support in 2.0. The problem is it's really
 designed for end users.

I was actually thinking of the bibliographic browser forms already in the 
eXist sample demos. 

In OOo the Base forms are easy to build, but you need to do OOo Basic 
programming to set up more advanced features like tabbed panels and probably 
to do complex multi-table updates.

You can use Xforms in OOo but it is harder to use than Base forms which are of 
the point and click type, to link database fields to form fields.

In OOo Xforms you have to construct your own Xpath statements for the form 
fields. Which for me is like hard programming.

These are probably only suitable for early and quick prototyping .

 Bruce

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

-- 
---
David N. Wilson
Co-Project Lead for the Bibliographic 
OpenOffice Project
http://bibliographic.openoffice.org

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



Re: [dev-biblio] embedded references/functional requirements wiki page

2006-04-04 Thread David Wilson
On Wednesday 05 April 2006 6:40 am, Bruce D'Arcus wrote:
 On Apr 4, 2006, at 3:54 PM, Matt Price wrote:
  comment:  seems to me that it might be a good idea to start some of the
  actual deletion/consolidation suggested by Bruce or others.  WHile
  fairly exhaustive, the document is currently pretty hard to follow and
  very long.

 Actually, I'd like to start by suggesting we scrap the current
 requirements document and start over with the basics.  

You are probably right.
I will copy it and take it off.



 This is in part 
 because the existing document is so big that it's very difficult to
 disentangle. Perhaps once we have a solid core, we can then go back and
 look through the current version and add stuff back in where
 appropriate.

-- 
---
David N. Wilson
Co-Project Lead for the Bibliographic 
OpenOffice Project
http://bibliographic.openoffice.org

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