[Bibjson-dev] BibJSON Goals

Peter Murray-Rust pm286 at cam.ac.uk
Thu Jun 2 14:06:54 UTC 2011


Great,

I have changed my attitude on textediting. (It was worth floating).

BUT it means we have to have tool support for certain types of editing and
this has to be trivial and universal.


> (things like unique ids, numbering/counts, etc. require programs)
>
> I dont think this is a realistic or very useful goal. My experience is that
> in limited contexts it is
> much easier to work in a plain text editor with ad hoc formats like
> something I have developed with Matthew Watkins
> which we call bibtxt and looks like e.g.
>
> @@article 1234
> @author David Aldous ; Jim Pitman
> @title  the title
>
> and so on with no fussy quotes or backslashes. You just have to kill one
> double quote by accident in a text editor and
> you have screwed up an entire BibJSON file. BibTeX suffers from the same
> problem.  These ad hoc formats will come and go.
> We need something more rigorous for reliable machine processing, and that
> is what BibJSON is for. So programs can
> read and write BibJSON.
>
> PMR - I recant. more below


>
> > * *The number of optional features in bibjson (syntax) is to be kept to
> the
> > minimum*. Ideally, there would be zero optional features. Optional
> features
> > cause problems because they are not guaranteed to be in any given
> situation.
> > The more optional features there are in a system the more combinations
> there are for the system and so the more difficult the programming becomes.
>
> I think I agree for syntax. But there should be no limit on optional
> fields.


Absolutely. That's why I suggest "syntax" in the text. It should be possible
to write a bibjson parser in 2011 and not have to maintain it for the next
year.

All extension is done through vocabulary, not syntax. And all (except a
T-shirt minumum) vocabulary is optional


> And we should strongly encourage if not enforce
> conventions for simplifying flattening of lists, like consistent use of ";
> " as a default separator for author lists and the like.
>

I agree.

>
> > bibjson is intended to not require a special editor or tool to create.
> And in fact, most bibjson
> > documents can be edited in a text editor like Notepad or TextEdit.
>
> Very bad idea to directly edit BibJSON in a text editor like Notepad or
> TextEdit, as explained above.
> Rather, edit in any environment where you can easily maintain the
> structure, and then map by script to BibJSON.
> There are lots of existing tools for editing BibTeX, and the map from
> BibTeX to BibJSON is already very stable.
> Where there are remaining issues is with character encodings,  support of
> mapping BibTeX accents to utf-8 which
> should be required for standard BibJSON.  Here we encounter the issue of
> specifying format in BibJSON e.g.
>
> i like the editing via BibTex. IOW it should be possible to go round the
trip:
BJ ->(auto)-> BibTex -> edit -> Bibtex ->(auto)-> BJ

As soon as possible we should work to get BJ input and output into tools


> title
> title_tex
> title_html
>
> are all variants I have used and I think essential to support.  The main
> thing is you should  be able to use BibJSON to
> immediatley encode bibliographic data whereever it may have come from, and
> then perform BibJSON-> BibJSON processing to
> clean it up.
>
> OK - I agree about requiring some form of tools. That means *we* have to
write them or get them written. (Specs which are just specs don't get
traction).

Many people today only work through GUIs. This (IMO) represents a dumbing
down of the human mind, but... (I encountered a grad student here - not mine
- who after 1 year in chemical informatics (sic) do not know what a
commandline was. But we cannot assume people can use UNIX-like tools.

So...
* add-in for Word (no thanks, been there)
* web service (could be a useful way of growing the community)
* emacs - yes. But these are not the main problem
* add-in for TextPad, Notepad, - no idea of effort or value
* IO tools for existing editors. Yes, and this also helps us get bib content

So my suggestion would be that we offer tools online and elsewhere and that
these will transparently also capture content. This could be very powerful
in moving the community.

P.



-- 
Peter Murray-Rust
Reader in Molecular Informatics
Unilever Centre, Dep. Of Chemistry
University of Cambridge
CB2 1EW, UK
+44-1223-763069
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/bibjson-dev/attachments/20110602/c30e197a/attachment.html>


More information about the bibjson-dev mailing list