eprints_tech messages

From: Clayton Carter <crcarter AT cs.indiana.edu>
Date: Thu, 10 May 2001 15:13:31 -0500

	I wouldn't go this far, but I will say that I didn't have too
much trouble with the install.  I had to work some voodoo so that the
Debian installed Perl modules would co-exist with the newer versions
from CPAN.  Also, I had never used MySQL before, so that was an
adventure; but overall, I didn't have too much trouble.  I'm not
saying it's easy or that it's done well, mind y'all, I'm just saying
that installed it without major problems.

	What I will say is that the system is a bitch to develop for.
Whoever developed this code was living in some strange fantasy world.
A lot of it is done very well and quite cleverly, but the rest is
bizarre and can only be described by a big bowl of extra sloppy
linguine.  But it works, so make of it what you will.

--pc


On Wed, May 09, 2001 at 10:24:26AM +0000, Dan Fleming wrote:
> Buggy eh?
> 
> Eprints is a breeze to install on Linux. I set it up on Red Hat 7 where I 
> guess I had the benefit of Red Hat's quck & easy installation methods ↵
for 
> locating and setting up all the prerequisite stuff. I used to use Solaris ↵
and 
> imagine it would have been a lot harder getting that sorted out prior to 
> installing eprints. I know Chistopher says negative feedback is more ↵
useful 
> than positive, but I just thought I'd offer this encouragement to anyone ↵
who 
> wants to set it up on Red Hat and might otherwise be put off.
> 
> Dan
> 
> Dr D Fleming
> University of Ulster

-- 
Clayton Carter   crcarter AT cs.indiana.edu
"My mom says I'm the handsomest guy in school."

From: "Faine, Mark" <Mark.Faine AT msfc.nasa.gov>
Date: Fri, 11 May 2001 07:10:34 -0500

Seems from I can tell that Linux installs work best.  

Is eprints the only OAI software available?

-Mark

-----Original Message-----
From: Clayton Carter [mailto:crcarter AT cs.indiana.edu]
Sent: Thursday, May 10, 2001 3:14 PM
To: EPrints.org Technical List
Subject: Re: [EP-tech] eprints (buggy?)


	I wouldn't go this far, but I will say that I didn't have too
much trouble with the install.  I had to work some voodoo so that the
Debian installed Perl modules would co-exist with the newer versions
from CPAN.  Also, I had never used MySQL before, so that was an
adventure; but overall, I didn't have too much trouble.  I'm not
saying it's easy or that it's done well, mind y'all, I'm just saying
that installed it without major problems.

	What I will say is that the system is a bitch to develop for.
Whoever developed this code was living in some strange fantasy world.
A lot of it is done very well and quite cleverly, but the rest is
bizarre and can only be described by a big bowl of extra sloppy
linguine.  But it works, so make of it what you will.

--pc


On Wed, May 09, 2001 at 10:24:26AM +0000, Dan Fleming wrote:
> Buggy eh?
> 
> Eprints is a breeze to install on Linux. I set it up on Red Hat 7 where I 
> guess I had the benefit of Red Hat's quck & easy installation methods ↵
for 
> locating and setting up all the prerequisite stuff. I used to use Solaris
and 
> imagine it would have been a lot harder getting that sorted out prior to 
> installing eprints. I know Chistopher says negative feedback is more
useful 
> than positive, but I just thought I'd offer this encouragement to anyone
who 
> wants to set it up on Red Hat and might otherwise be put off.
> 
> Dan
> 
> Dr D Fleming
> University of Ulster

-- 
Clayton Carter   crcarter AT cs.indiana.edu
"My mom says I'm the handsomest guy in school."

From: Christopher Gutteridge <cjg AT ecs.soton.ac.uk>
Date: Mon, 14 May 2001 15:31:23 +0100

Did you set the username to connect as in the config file (AND HUP/RESTART
APACHE?) It sounds like the username you're using is still eprints (hence)
eprints AT localhost. 

Did you create a DB call "eprints" by hand?

Did you run the create_database script which builds all the SQL tables?


On Wed, May 09, 2001 at 12:58:20PM -0500, Faine, Mark wrote:
> Ok, I've gottent the apache with mod_perl operational and all is good on ↵
the
> web server front.
> 
> I decided earlier to re-install manually the eprints software. I'm to the
> point where I need to 
> run scripts that update/create the database, specificaly the cron tab
> scripts but really none of the scripts will work.
> 
> I just get somehting like:
> 
> [root AT trs]296[/usr/local/apache/eprints/bin]# ./subs_daily 
> DBI->connect(database=eprints) failed: Access denied for user:
> 'eprints AT localhost' (Using password: YES) at
> /usr/local/apache/eprints/perl_lib/EPrints/Database.pm line 134
> TRS has encountered an error:
> 
> Failed to connect to database
> 
> Can't call method "retrieve_fields" on an undefined value at
> /usr/local/apache/eprints/perl_lib/EPrints/Subscription.pm line 338.
> 
> -------------------------------------------------------------------
> 
> I would like to change the username the scripts are using to ↵
"nobody" but I
> can't figure out how, except a direct hack on the Database.pm file, and ↵
I've
> tried, nobody can't connect either.   $EPrintSite::SiteInfo::username is ↵
set
> to "nobody" but still it tries to connect as eprints.
> 
> I know the grants and users are set up right because I can connect as ↵
nobody
> or eprints from the command line.
> 
> 
> Basically if I get through this database problem that should be the last
> hurdle to clear as that is the only thing holding back a completed
> installation at this point.
> 
> Any help would be appreciated?
> 
> -Mark
> 
> 
> 
> _____________________________________ 
> Mark Faine 
> Computer Programmer III/MTRS Administration 
> Lesco/MSFC 
> 256-961-1295 

-- 
Christopher Gutteridge -- cjg AT ecs.soton.ac.uk -- +44 (0)23 8059 4833
Aside from mathematics, just two things worth doing - Kill a man and love a 
woman. He had done both; he was rich. - Robert Heinlein

From: Christopher Gutteridge <cjg AT ecs.soton.ac.uk>
Date: Mon, 14 May 2001 15:34:26 +0100

Storing the metadata as XML is impractical, searching becomes very 
clumsey - the diffinitive(sp?) copy of the data will remain in the database,
however the new version may have multiple pages for one record - eg: one with
subjects and links in french and one in english. I may try to look into making
XML versions of the abstract pages and views pages which get regenerated at
the same time  - that would mean they could be harvested/processed without
any extra load on the server.... Hmmm. 

Don't hold your breath, though.

On Thu, May 10, 2001 at 07:33:26AM -0500, Faine, Mark wrote:
>     Ok, I've noticed there are several different upload types and an
> arbirtrary flag. If you were building from the ground up a new system
> wouldn't it be best to provide an interface for that system that allowed ↵
new
> reports to be inputted to the system directly and converted to XML to be
> stored on the archive server as XML.  Then when the user searched for a
> record it could be displayed in any number of formats using XSL or CSS.
> Before I started digging into the functionality of eprints, I thought that
> was how it worked.  
>  
> -Mark
> 
> _____________________________________ 
> 
> Mark Faine 
> Computer Programmer III/MTRS Administration 
> Lesco/MSFC 
> 256-961-1295 
> 
>  

-- 
Christopher Gutteridge -- cjg AT ecs.soton.ac.uk -- +44 (0)23 8059 4833
Trust and Obey, for there's no other way to be happy in Jesus than to Trust 
and Obey.

From: Christopher Gutteridge <cjg AT ecs.soton.ac.uk>
Date: Mon, 14 May 2001 16:55:45 +0100

Oh, hang on, I misunderstood. Brain not work good.

You mean converting the actual upload, rather than the metadata to XML:

Hmmm. This is, in theory, the best solution. But I don't know of an XML
format with tools which will convert to and from it from Postscript, PDF,
MS Word and HTML, without loss of information.

The easiest solution is to convert everything to postscript as a base
format, but that is still hard for MS Word (there are tools, but not 
free to my knowledge)

Any advice and suggestions welcome.

On Thu, May 10, 2001 at 07:33:26AM -0500, Faine, Mark wrote:
>     Ok, I've noticed there are several different upload types and an
> arbirtrary flag. If you were building from the ground up a new system
> wouldn't it be best to provide an interface for that system that allowed ↵
new
> reports to be inputted to the system directly and converted to XML to be
> stored on the archive server as XML.  Then when the user searched for a
> record it could be displayed in any number of formats using XSL or CSS.
> Before I started digging into the functionality of eprints, I thought that
> was how it worked.  
>  
> -Mark
> 
> _____________________________________ 
> 
> Mark Faine 
> Computer Programmer III/MTRS Administration 
> Lesco/MSFC 
> 256-961-1295 
> 
>  

-- 
Christopher Gutteridge -- cjg AT ecs.soton.ac.uk -- +44 (0)23 8059 4833
Life is like a box of chocolates: It's given to you by relatives on your 
birthday; it's not really what you were expecting but it's better than a 
pair of socks.

From: ePrints Support <support AT eprints.org>
Date: Tue, 15 May 2001 09:56:28 +0100

On Thu, May 10, 2001 at 03:13:31PM -0500, Clayton Carter wrote:
> 
> 	What I will say is that the system is a bitch to develop for.
> Whoever developed this code was living in some strange fantasy world.
> A lot of it is done very well and quite cleverly, but the rest is
> bizarre and can only be described by a big bowl of extra sloppy
> linguine.  But it works, so make of it what you will.

I'm re-writing a lot of the "odd" bits. Rob, the origional author, is ↵
an 
academic, where I'm a sys-support/admin/hacker. I'm attempting to rebuild
it as OO as possible too, since a few other sarcy comments from Tim Brody
<grin>. I've not been into the doc submission method bit which seems
very strange, but I've had a crack at most of the rest.

One of the reasons to make the code much more strict is the problems with
running multiple copies on one instance of modperl (name space conflicts etc).

Hopefully the new version will be a bit easier to work with. Credit to Rob
though, the good bits are very good. 


> > 
> > Dr D Fleming
> > University of Ulster
> 
> -- 
> Clayton Carter   crcarter AT cs.indiana.edu
> "My mom says I'm the handsomest guy in school."

-- 

 Christopher Gutteridge                   support AT eprints.org 
 ePrints Technical Support                +44 23 8059 4833

From: ePrints Support <support AT eprints.org>
Date: Tue, 15 May 2001 10:01:48 +0100

I think currently eprints is the only generic software.

I imagine that in time other already existing systems may
add an OAI interface. It is relatively easy to build OAI as
a bolt on for another database. I think Tim Brody has done 
some fairly generic perl code which people could use.

Although, eprints.org is the one true system, but I would
say that, wouldn't I? <grin>


On Fri, May 11, 2001 at 07:10:34AM -0500, Faine, Mark wrote:
> Seems from I can tell that Linux installs work best.  
> 
> Is eprints the only OAI software available?
> 
> -Mark
> 
> -----Original Message-----
> From: Clayton Carter [mailto:crcarter AT cs.indiana.edu]
> Sent: Thursday, May 10, 2001 3:14 PM
> To: EPrints.org Technical List
> Subject: Re: [EP-tech] eprints (buggy?)
> 
> 
> 	I wouldn't go this far, but I will say that I didn't have too
> much trouble with the install.  I had to work some voodoo so that the
> Debian installed Perl modules would co-exist with the newer versions
> from CPAN.  Also, I had never used MySQL before, so that was an
> adventure; but overall, I didn't have too much trouble.  I'm not
> saying it's easy or that it's done well, mind y'all, I'm just saying
> that installed it without major problems.
> 
> 	What I will say is that the system is a bitch to develop for.
> Whoever developed this code was living in some strange fantasy world.
> A lot of it is done very well and quite cleverly, but the rest is
> bizarre and can only be described by a big bowl of extra sloppy
> linguine.  But it works, so make of it what you will.
> 
> --pc
> 
> 
> On Wed, May 09, 2001 at 10:24:26AM +0000, Dan Fleming wrote:
> > Buggy eh?
> > 
> > Eprints is a breeze to install on Linux. I set it up on Red Hat 7 ↵
where I 
> > guess I had the benefit of Red Hat's quck & easy installation ↵
methods for 
> > locating and setting up all the prerequisite stuff. I used to use ↵
Solaris
> and 
> > imagine it would have been a lot harder getting that sorted out prior ↵
to 
> > installing eprints. I know Chistopher says negative feedback is more
> useful 
> > than positive, but I just thought I'd offer this encouragement to ↵
anyone
> who 
> > wants to set it up on Red Hat and might otherwise be put off.
> > 
> > Dan
> > 
> > Dr D Fleming
> > University of Ulster
> 
> -- 
> Clayton Carter   crcarter AT cs.indiana.edu
> "My mom says I'm the handsomest guy in school."

-- 

 Christopher Gutteridge                   support AT eprints.org 
 ePrints Technical Support                +44 23 8059 4833

From: Ed Sponsler <eds AT library.caltech.edu>
Date: Tue, 15 May 2001 10:45:13 -0700

[If you have an postscript printer driver installed on your Windoz box,
converting MS Word to postscript is as easy as printing to file.]

Although using XML for storing document content is the ultimate solution,
there are significant hurdles to overcome, most not really technical. 

First, it is vital that the XML be valid against a DTD (Document Type
Definition). Without a DTD, you may still have well formed XML, however you
can forget about controlling the final output format using XSL or CSS (as
far as I'm aware). 

The DTD must be agreed upon by all authors submitting reports to your XML
based archive. For basic reports containing only text and images, this
shouldn't be too tough. Mathematical formulas may be converted to images, to
simplify an otherwise tricky hurdle.

Now that there is a DTD, scripts (XSL, CSS, etc.) are now able to take
advantage of a well defined structure and thus convert XML to HTML, for
example.

Now comes the hard part. How do you get the authors to construct the valid
XML? The best way would be to provide them with an XML editor that enforces
conformance to your DTD. I don't know of too many tools that do this. One
such tool (expensive) is available from Arbotext (http://www.arbortext.com/)
called the Epic Editor. With an editor like this, you can't violate the DTD.

Another option is to shift the responsibility of preparing the valid XML to
the archive maintainer, such as a librarian or (ugh) sys admin. The author
should at least help out by using a well defined style sheet (MS Word) or
class file (.cls in LaTex). The document perparer then has the wonderful
privilege of tagging the authors source file into proper XML. (Yack). There
are tools available to help. For example, James Clark has written a tool to
convert RTF output from Word into well-formed XML (I'll hunt it down if
anyone is interested by you can try http://jclark.com), however you still
have to make such output valid to a DTD. I don't believe this option is very
practical, except for very small projects. 

The two main barriers to using XML for the body of reports is formally
defining a document that all authors will agree on (generate a DTD) and
actually generating the valid XML.

The advantages of storing the document content in XML are numerous, as I'm
sure most are aware, and shouldn't be blown off just because of the
previously mentioned challenges. The burden of these challenges may be
reduced dramatically if the DTD were extremely simple. 

It is fortunate that OAI compliant archives (such as EPrints) spit out
metadata in XML. Thus, a important chunk of the document (the front matter)
is effectively already stored in XML. Now, if the bibliography were also
tagged in valid XML, then only the body of the document would require
definition. 

[Using XML for storing bibliographic info opens up some interesting
possibilities, such as context-sensitive reference linking:
http://www.sfxit.com. Utilities are available for converting the output of
common bibliographic tools, such as Endnote (Word) and BibTex (LaTex):
http://www.ctan.org/tex-archive/biblio/bibtex/utils/bibtools/.]

Does anyone have any thoughts on all this? Do you think authors will ever
give up their beloved Word, WordPerfect or LaTeX editors in favor of an XML
one? Do you think plug-ins will be developed for Word to enforce DTD
compliance? Does anyone know of an LaTeX/.cls to XML/DTD converter? Is it
really that important to store the document body in XML at all, or is it
good enough to have XML front matter (already here), XML bibliographies
(just around the corner) and an open-standard-formatted body like PDF or
postscript?

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Ed Sponsler, Sr. Computing Analyst
Caltech Library System


-----Original Message-----
From: Christopher Gutteridge [mailto:cjg AT ecs.soton.ac.uk]
Sent: Monday, May 14, 2001 8:56 AM
To: EPrints.org Technical List
Subject: Re: [EP-tech] Questions on use


Oh, hang on, I misunderstood. Brain not work good.

You mean converting the actual upload, rather than the metadata to XML:

Hmmm. This is, in theory, the best solution. But I don't know of an XML
format with tools which will convert to and from it from Postscript, PDF,
MS Word and HTML, without loss of information.

The easiest solution is to convert everything to postscript as a base
format, but that is still hard for MS Word (there are tools, but not 
free to my knowledge)

Any advice and suggestions welcome.

On Thu, May 10, 2001 at 07:33:26AM -0500, Faine, Mark wrote:
>     Ok, I've noticed there are several different upload types and an
> arbirtrary flag. If you were building from the ground up a new system
> wouldn't it be best to provide an interface for that system that allowed
new
> reports to be inputted to the system directly and converted to XML to be
> stored on the archive server as XML.  Then when the user searched for a
> record it could be displayed in any number of formats using XSL or CSS.
> Before I started digging into the functionality of eprints, I thought that
> was how it worked.  
>  
> -Mark
> 
> _____________________________________ 
> 
> Mark Faine 
> Computer Programmer III/MTRS Administration 
> Lesco/MSFC 
> 256-961-1295 
> 
>  

-- 
Christopher Gutteridge -- cjg AT ecs.soton.ac.uk -- +44 (0)23 8059 4833
Life is like a box of chocolates: It's given to you by relatives on your 
birthday; it's not really what you were expecting but it's better than a 
pair of socks.

From: Tim Brody <tdb198 AT ecs.soton.ac.uk>
Date: Tue, 15 May 2001 19:24:09 +0100 (BST)

On Tue, 15 May 2001, Ed Sponsler wrote:

> It is fortunate that OAI compliant archives (such as EPrints) spit out
> metadata in XML. Thus, a important chunk of the document (the front ↵
matter)
> is effectively already stored in XML. Now, if the bibliography were also
> tagged in valid XML, then only the body of the document would require
> definition. 

We, in OpCit (http://opcit.eprints.org), are working towards this. For
example see:
http://cite-base.ecs.soton.ac.uk/cgi-bin/oai/OAI-script?verb=GetRecord&metadataPrefix=opcit_dc&identifier=oai:arXiv:hep-th/0001001
(liable to change, breakage etc.)

That data is based on the automatic conversion of LaTeX bibliographic
records.

> [Using XML for storing bibliographic info opens up some interesting
> possibilities, such as context-sensitive reference linking:
> http://www.sfxit.com. Utilities are available for converting the output of
> common bibliographic tools, such as Endnote (Word) and BibTex (LaTex):
> http://www.ctan.org/tex-archive/biblio/bibtex/utils/bibtools/.]

(you may also be interested in http://www.pubmedcentral.nih.gov/ which, I
believe, stores its documents in XML - I would expect medical reports
don't suffer as much from XML's inability to express formulas. Journals
provide the properly formatted XML using a PubMed DTD)

> Does anyone have any thoughts on all this? Do you think authors will ever
> give up their beloved Word, WordPerfect or LaTeX editors in favor of an ↵
XML
> one? Do you think plug-ins will be developed for Word to enforce DTD
> compliance? Does anyone know of an LaTeX/.cls to XML/DTD converter? Is it
> really that important to store the document body in XML at all, or is it
> good enough to have XML front matter (already here), XML bibliographies
> (just around the corner) and an open-standard-formatted body like PDF or
> postscript?

Only to say that archives will always store the formats that authors give
them, otherwise the authors won't give the archive's any documents!
(and while authors use Word, Perfect, LaTeX, dodgy HTML ...)

All the best,
Tim Brody
ECS, Southampton

From: "Faine, Mark" <Mark.Faine AT msfc.nasa.gov>
Date: Tue, 15 May 2001 14:55:54 -0500

What we need for the authors is an editor with an easy to use gui that hides
all the
XML underneath and politely enforces a DTD based on a pre-defined template.

All the ease of an application like word with something like Xmetal
underneath.

That would be the killer app that would make storing document content as XML
feasible for everyone.

-Mark



-----Original Message-----
From: Ed Sponsler [mailto:eds AT library.caltech.edu]
Sent: Tuesday, May 15, 2001 12:45 PM
To: 'EPrints.org Technical List'
Subject: RE: [EP-tech] Questions on use


[If you have an postscript printer driver installed on your Windoz box,
converting MS Word to postscript is as easy as printing to file.]

Although using XML for storing document content is the ultimate solution,
there are significant hurdles to overcome, most not really technical. 

First, it is vital that the XML be valid against a DTD (Document Type
Definition). Without a DTD, you may still have well formed XML, however you
can forget about controlling the final output format using XSL or CSS (as
far as I'm aware). 

The DTD must be agreed upon by all authors submitting reports to your XML
based archive. For basic reports containing only text and images, this
shouldn't be too tough. Mathematical formulas may be converted to images, to
simplify an otherwise tricky hurdle.

Now that there is a DTD, scripts (XSL, CSS, etc.) are now able to take
advantage of a well defined structure and thus convert XML to HTML, for
example.

Now comes the hard part. How do you get the authors to construct the valid
XML? The best way would be to provide them with an XML editor that enforces
conformance to your DTD. I don't know of too many tools that do this. One
such tool (expensive) is available from Arbotext (http://www.arbortext.com/)
called the Epic Editor. With an editor like this, you can't violate the DTD.

Another option is to shift the responsibility of preparing the valid XML to
the archive maintainer, such as a librarian or (ugh) sys admin. The author
should at least help out by using a well defined style sheet (MS Word) or
class file (.cls in LaTex). The document perparer then has the wonderful
privilege of tagging the authors source file into proper XML. (Yack). There
are tools available to help. For example, James Clark has written a tool to
convert RTF output from Word into well-formed XML (I'll hunt it down if
anyone is interested by you can try http://jclark.com), however you still
have to make such output valid to a DTD. I don't believe this option is very
practical, except for very small projects. 

The two main barriers to using XML for the body of reports is formally
defining a document that all authors will agree on (generate a DTD) and
actually generating the valid XML.

The advantages of storing the document content in XML are numerous, as I'm
sure most are aware, and shouldn't be blown off just because of the
previously mentioned challenges. The burden of these challenges may be
reduced dramatically if the DTD were extremely simple. 

It is fortunate that OAI compliant archives (such as EPrints) spit out
metadata in XML. Thus, a important chunk of the document (the front matter)
is effectively already stored in XML. Now, if the bibliography were also
tagged in valid XML, then only the body of the document would require
definition. 

[Using XML for storing bibliographic info opens up some interesting
possibilities, such as context-sensitive reference linking:
http://www.sfxit.com. Utilities are available for converting the output of
common bibliographic tools, such as Endnote (Word) and BibTex (LaTex):
http://www.ctan.org/tex-archive/biblio/bibtex/utils/bibtools/.]

Does anyone have any thoughts on all this? Do you think authors will ever
give up their beloved Word, WordPerfect or LaTeX editors in favor of an XML
one? Do you think plug-ins will be developed for Word to enforce DTD
compliance? Does anyone know of an LaTeX/.cls to XML/DTD converter? Is it
really that important to store the document body in XML at all, or is it
good enough to have XML front matter (already here), XML bibliographies
(just around the corner) and an open-standard-formatted body like PDF or
postscript?

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Ed Sponsler, Sr. Computing Analyst
Caltech Library System


-----Original Message-----
From: Christopher Gutteridge [mailto:cjg AT ecs.soton.ac.uk]
Sent: Monday, May 14, 2001 8:56 AM
To: EPrints.org Technical List
Subject: Re: [EP-tech] Questions on use


Oh, hang on, I misunderstood. Brain not work good.

You mean converting the actual upload, rather than the metadata to XML:

Hmmm. This is, in theory, the best solution. But I don't know of an XML
format with tools which will convert to and from it from Postscript, PDF,
MS Word and HTML, without loss of information.

The easiest solution is to convert everything to postscript as a base
format, but that is still hard for MS Word (there are tools, but not 
free to my knowledge)

Any advice and suggestions welcome.

On Thu, May 10, 2001 at 07:33:26AM -0500, Faine, Mark wrote:
>     Ok, I've noticed there are several different upload types and an
> arbirtrary flag. If you were building from the ground up a new system
> wouldn't it be best to provide an interface for that system that allowed
new
> reports to be inputted to the system directly and converted to XML to be
> stored on the archive server as XML.  Then when the user searched for a
> record it could be displayed in any number of formats using XSL or CSS.
> Before I started digging into the functionality of eprints, I thought that
> was how it worked.  
>  
> -Mark
> 
> _____________________________________ 
> 
> Mark Faine 
> Computer Programmer III/MTRS Administration 
> Lesco/MSFC 
> 256-961-1295 
> 
>  

-- 
Christopher Gutteridge -- cjg AT ecs.soton.ac.uk -- +44 (0)23 8059 4833
Life is like a box of chocolates: It's given to you by relatives on your 
birthday; it's not really what you were expecting but it's better than a 
pair of socks.

From: ePrints Support <support AT eprints.org>
Date: Sat, 19 May 2001 18:46:43 +0100

ramble on the next gen of doc formats:

I expect that in the long term someone will produce a system which 
allows documents to be expressed in a nice generic format like XML
with all the style being seperate -  stylesheets and XHTML are a 
forerunner but I don't think we're there yet.

I believe there is a MathML for formulas...

The problem is that joe user (or joe professor) wants to use a 
WYSIWYG editor, which usually combine formating and style with semantic
structuring (headers, paragraphs, cross-refs). Even latex is
a hodgepodge of content and layout.

Ideally this magical mystery format would be easy for MS Word (and similar)
to export. Unless it's easy to edit and produces nice output both
on screen and paper, no one will use it. My discussions with users have
shown me that they don't mind using something which provides more useful
output, but they aren't going to go out of their way to help either.

I think that's why OAI has a chance to succeed because it can be
relatively painlessly bolted on top of an already existing archive -
day to day users don't have to go through any more hassle to submit
records, so they don't care.

We need the same thing from a generic document format - something that
can be added to existing software, initially.




On Tue, May 15, 2001 at 10:45:13AM -0700, Ed Sponsler wrote:
> [If you have an postscript printer driver installed on your Windoz box,
> converting MS Word to postscript is as easy as printing to file.]
> 
> Although using XML for storing document content is the ultimate solution,
> there are significant hurdles to overcome, most not really technical. 
> 
> First, it is vital that the XML be valid against a DTD (Document Type
> Definition). Without a DTD, you may still have well formed XML, however ↵
you
> can forget about controlling the final output format using XSL or CSS (as
> far as I'm aware). 
> 
> The DTD must be agreed upon by all authors submitting reports to your XML
> based archive. For basic reports containing only text and images, this
> shouldn't be too tough. Mathematical formulas may be converted to images, ↵
to
> simplify an otherwise tricky hurdle.
> 
> Now that there is a DTD, scripts (XSL, CSS, etc.) are now able to take
> advantage of a well defined structure and thus convert XML to HTML, for
> example.
> 
> Now comes the hard part. How do you get the authors to construct the valid
> XML? The best way would be to provide them with an XML editor that ↵
enforces
> conformance to your DTD. I don't know of too many tools that do this. One
> such tool (expensive) is available from Arbotext ↵
(http://www.arbortext.com/)
> called the Epic Editor. With an editor like this, you can't violate the ↵
DTD.
> 
> Another option is to shift the responsibility of preparing the valid XML ↵
to
> the archive maintainer, such as a librarian or (ugh) sys admin. The author
> should at least help out by using a well defined style sheet (MS Word) or
> class file (.cls in LaTex). The document perparer then has the wonderful
> privilege of tagging the authors source file into proper XML. (Yack). ↵
There
> are tools available to help. For example, James Clark has written a tool ↵
to
> convert RTF output from Word into well-formed XML (I'll hunt it down if
> anyone is interested by you can try http://jclark.com), however you still
> have to make such output valid to a DTD. I don't believe this option is ↵
very
> practical, except for very small projects. 
> 
> The two main barriers to using XML for the body of reports is formally
> defining a document that all authors will agree on (generate a DTD) and
> actually generating the valid XML.
> 
> The advantages of storing the document content in XML are numerous, as I'm
> sure most are aware, and shouldn't be blown off just because of the
> previously mentioned challenges. The burden of these challenges may be
> reduced dramatically if the DTD were extremely simple. 
> 
> It is fortunate that OAI compliant archives (such as EPrints) spit out
> metadata in XML. Thus, a important chunk of the document (the front ↵
matter)
> is effectively already stored in XML. Now, if the bibliography were also
> tagged in valid XML, then only the body of the document would require
> definition. 
> 
> [Using XML for storing bibliographic info opens up some interesting
> possibilities, such as context-sensitive reference linking:
> http://www.sfxit.com. Utilities are available for converting the output of
> common bibliographic tools, such as Endnote (Word) and BibTex (LaTex):
> http://www.ctan.org/tex-archive/biblio/bibtex/utils/bibtools/.]
> 
> Does anyone have any thoughts on all this? Do you think authors will ever
> give up their beloved Word, WordPerfect or LaTeX editors in favor of an ↵
XML
> one? Do you think plug-ins will be developed for Word to enforce DTD
> compliance? Does anyone know of an LaTeX/.cls to XML/DTD converter? Is it
> really that important to store the document body in XML at all, or is it
> good enough to have XML front matter (already here), XML bibliographies
> (just around the corner) and an open-standard-formatted body like PDF or
> postscript?
> 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Ed Sponsler, Sr. Computing Analyst
> Caltech Library System
> 
> 
> -----Original Message-----
> From: Christopher Gutteridge [mailto:cjg AT ecs.soton.ac.uk]
> Sent: Monday, May 14, 2001 8:56 AM
> To: EPrints.org Technical List
> Subject: Re: [EP-tech] Questions on use
> 
> 
> Oh, hang on, I misunderstood. Brain not work good.
> 
> You mean converting the actual upload, rather than the metadata to XML:
> 
> Hmmm. This is, in theory, the best solution. But I don't know of an XML
> format with tools which will convert to and from it from Postscript, PDF,
> MS Word and HTML, without loss of information.
> 
> The easiest solution is to convert everything to postscript as a base
> format, but that is still hard for MS Word (there are tools, but not 
> free to my knowledge)
> 
> Any advice and suggestions welcome.
> 
> On Thu, May 10, 2001 at 07:33:26AM -0500, Faine, Mark wrote:
> >     Ok, I've noticed there are several different upload types and an
> > arbirtrary flag. If you were building from the ground up a new system
> > wouldn't it be best to provide an interface for that system that ↵
allowed
> new
> > reports to be inputted to the system directly and converted to XML to ↵
be
> > stored on the archive server as XML.  Then when the user searched for ↵
a
> > record it could be displayed in any number of formats using XSL or ↵
CSS.
> > Before I started digging into the functionality of eprints, I thought ↵
that
> > was how it worked.  
> >  
> > -Mark
> > 
> > _____________________________________ 
> > 
> > Mark Faine 
> > Computer Programmer III/MTRS Administration 
> > Lesco/MSFC 
> > 256-961-1295 
> > 
> >  
> 
> -- 
> Christopher Gutteridge -- cjg AT ecs.soton.ac.uk -- +44 (0)23 8059 4833
> Life is like a box of chocolates: It's given to you by relatives on your 
> birthday; it's not really what you were expecting but it's better than a 
> pair of socks.

-- 

 Christopher Gutteridge                   support AT eprints.org 
 ePrints Technical Support                +44 23 8059 4833

From: ePrints Support <support AT eprints.org>
Date: Wed, 23 May 2001 10:59:52 +0100

First of all, apologies all round, I've been dealing with the
end of student year courseworks panic - I've not been able to
give much attention to eprints.


I'm being asked to compile a list of who's doing what with 
eprints. Which would be generally useful. But there is also
a need to identify a UK eprints user who would be willing to
speak at a meeting.


This is completely optional, but if you want, please mail
support AT eprints.org with information on what you are doing
with eprints,

contact name:
contact email: (may be admin AT ...)
institution/company:
location (including country): eg. Southampton, UK
archive name:
archive URL:
level of "commitment": eg.
	eprints archive deployed and in use
	eprints archive being evaluated with aim to use it
	just playing around with eprints
any interesting modifications:
interest in eprints community: (are you interested in being
involved, eg. provide speakers, answer questions, other stuff )
	-very interested
	-willing
	-can't see what I/we could help with
	-no, leave us alone

All fields are optional, this isn't a database (yet <grin>)
so feel free to invent fields that I didn't think of.

Usage of information:
  We WILL post it on the eprints.org website. We may use the
name of your institution in our propaganda (eg. University of
Badger Tech uses eprints!). 

-- 

 Christopher Gutteridge                   support AT eprints.org 
 ePrints Technical Support                +44 23 8059 4833

From: "Dan Fleming" <DR.Fleming AT ulst.ac.uk>
Date: Wed, 23 May 2001 11:25:15 GMT

contact name: Dan Fleming (Dr)
contact email: (may be admin AT ...) admin AT formations.org.uk
institution/company: University of Ulster
location (including country): eg. Coleraine, Northern Ireland, UK
archive name: Formations Media Studies Archive
archive URL: formations.org.uk
level of "commitment": eprints archive deployed and in use (just ↵
starting)
any interesting modifications: combined 'service' with a Lotus Domino 
based discussion ('seminar papers') site
interest in eprints community:  -willing (although concentrating on managing 
the archive's 'community', rather than technical development)

Usage of information: following are all OK
We WILL post it on the eprints.org website. We may use the
name of your institution in our propaganda (eg. University of
Badger Tech uses eprints!). 

 Christopher Gutteridge                   support AT eprints.org 
 ePrints Technical Support                +44 23 8059 4833