Re: RE: searching the nlm catalog

> available for download from their site. It would be a trivial matter
> for a very good programmer (not me :-) to learn how to convert these
> files to something that pyblio could use (see
> http://www.google.com/search?complete=1&hl=en&lr=&c2coff=1&safe=off&q=+site:www.endnote.com+endnote

I just had a casual look at it, and I feel like a bad programmer because
these binary files don't make me very enthusiastic about the chances of
converting them :-}

> and the link pointing to "Import Filters"). The other option is to
> develop new filter files de novo. Nevertheless, this ultimately means
> that pyblio would need to use a filter/template file system too (which
> it essentially does already). If anyone out there is a pro at
> understanding MARC, please try to contribute.

My plans (which are more intended for a developer than an end-user so
far) regarding import from external sources with pybliographer 1.3 are:

  (1) describing (in a pyblio 1.3 schema) the model of data for some
  major data sources, like MARC, BibTeX, ISI,... There is not
  necessarily a model that properly encompasses those, my idea is rather
  to have a specific model for each of those, so that it can include
  their specific properties.

  So far, I've a simple BibTeX model, and it is quite easy to write the
  other ones (though writing the MARC model is certainly a _major_ task
  if it aims at exhaustive support. I guess it's more tractable to start
  with a subset of the beast)

  (2) implementing the specific parsers able to convert data from the
  different sources. pyblio 1.3 has a quite modular system. There are
  already "syntactic" parsers able to cope with files in these different
  formats. They must be enriched in order to fit the actual data into
  the models described in (1). In addition, once you have a "standard"
  MARC parser for instance, you can still make a more specific class
  capable of handling a given database (ala EndNote import filters)

  (3) Now you have data that are represented in different models. An
  important missing piece is an "adaptation layer", so that you can
  "see" your marc data and your bibtex data homogeneously. I've some
  plans for that, but no code yet.

  (4) To integrate this for the user, there is a need for a common query
  system, able to fetch the data from the servers. Peter started looking
  for a common interrogation language. I would tend to solve the problem
  in a similar manner as the one proposed for adapting the different
  data model: having for each family of servers (z3950, medline, web of
  science,...) a custom interrogation system, which could then be
  adapted to a common query language, or accessed directly when there is
  a need to do so.

I really need to do draw this, I'm afraid it's a bit opaque if you don't
live in my brain.

As I said, these are my plans for 1.3, which require still a bit of work
:-) For their backward integration in 1.2, adapting the results to
BibTeX should be a good starting point.

Frédéric

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEIackFjQHpltE9KURAjjEAKC6huvylIrLlyDD+KaaQBf1KAkpswCgvL5k
Tl7OL8MQ0A630776Im22TpU=
=jYQC
-----END PGP SIGNATURE-----