Re: [NTG-context] Bibliographic Databases

2008-04-20 Thread Bruce D'Arcus
Taco Hoekwater taco at elvenkind.com writes:

 
 Hi,
 
 Andreas Wagner wrote:
  Just out of curiosity: What are your reasons for preferring this over TEI:
 
 MODS was a logical choice mostly my background (scientific publishers
 = MARC databases = MODS), and that BruceD'Arcus liked it.  Btw,
 his blog is full of bibliographic articles, if you are interested:
 
http://community.muohio.edu/blogs/darcusb/
 
 (but it looks like he has switched over to RDF now)

Yes, but ...
 
 I am not really set to any particular xml format, and there are
 more mainstream choices (risx comes to mind).

... I'd say for the design of something like mbib v2 I'd advocate an internal
model that abstracts away from any particular more concrete representation. So
think in terms of maybe a standard input driver, but leave room for easy
development of others. 

There's some work going on a Python version of my citeproc effort, for example,
and he's planning input drivers for MODS, RDF, BibTeX, etc.

http://xbiblio.svn.sourceforge.net/viewvc/xbiblio/citeproc-py/citeproc/

This makes is easy for someone to write another input driver for some SQL model.
 
 But the few times I've had to work with TEI stuff I found that you
 can easily get much more than you bargained for. Bibliographic data
 is not easy on its own, and a format that allows (almost promotes)
 extra tags to be embedded also is not helping at all.
 
 Look at this:
 
http://www.tei-c.org/release/doc/tei-p5-doc/html/ref-author.html
 
 Just the 'core' module is already pretty complex, but 'namesdates'
 and 'linking' are definately also required for a useful bibliographic
 database.
 
 The nice, consise examples in the TEI docs are misleading because
 
authorLucy Allen Paton/author
 
 is useless, more specifics are needed. We need at least this:
 
author
  persName
forenameLucy/forename
forenameAllen/forename
surnamePaton/surname
  /persName
/author
 
 But with the use of persName, there are suddenly a gazillion
 ways an author can encode the same name  (and it does not
 preclude any of the other ways to encode a name).
 
http://www.tei-c.org/release/doc/tei-p5-doc/html/ND.html#NDPER
 
 Etc. etc. Imagine having to support that in a simple context module.

In the XML citation style language I designed [1] (which *could* serve as the
basis for that internal model I mention above), there's an implicit notion
that any name can have both a sort form and a display form, and that they may
(but in contexts like Eastern Europe or Asia often don't) differ. 

This makes things in many ways both simpler, and more general (works for
organizations, as well as is more international-friendly than traditional
first/last). You just handle the details you note above in the input drive code.

Bruce

[1]
http://xbiblio.svn.sourceforge.net/viewvc/xbiblio/csl/schema/trunk/csl.rnc?view=markup

___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : https://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___


Re: [NTG-context] bib amd mods

2006-06-20 Thread Bruce D'Arcus
Hi Hans,

Hans Hagen pragma at wxs.nl writes:

 I wonder, is there any interest in the following:
 
 - support for http://www.loc.gov/standards/mods/ as basic bibl format

I think Ulf's conclusions are right. MODS is expressive, which is why I was
originally attracted to it, but it's also more complex than it needs to be for
this sort of use case.

The big question becomes, if not MODS, then what? As Ulf pointed out, my
solution -- and the one I will be advocating for OpenDoucment (I am on the TC)
-- is to use a particular RDF serialization. Indeed, I have a draft RELAX NG
schema for it, and my formatting system (citeproc) now works with it quite well.

Microsoft, incidentally, is implementing pretty good bib support (that looks
suspiciously like what I've been advocating for OpenOffice!), which I've blogged
about extensively. Their XML format is not bad, though it is totally flat, which
means it won't be as flexible as MODS or RDF. More here:

http://netapps.muohio.edu/blogs/darcusb/darcusb/archives/2006/06/16/flat-vs-relational

 - provide converters from marcs and bibtex to mods
 - layer the bib module on top of that

Curious question: would you be writing it in Lua (closer to the pdftex level),
or go more high-level (as now)?

 If so, who'd like to join/volunteer for subtasks

I can certainly help with advice and design, particularly if you want to use CSL
to configure the output. I've made some changes to it (again) recently, but
think I'm zeroing in on freezing it. The more feedback I get, the easier it'll
be to do that.

Incidentally, I'm considering the possibility of submitting CSL to OASIS for
standardization, though only if I can get some industry players involved.

Bruce

___
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context


Re: [NTG-context] crossref in bibtex

2006-03-23 Thread Bruce D'Arcus
Taco Hoekwater taco at elvenkind.com writes:

[.. snip ...]

 The next major release of the module (but don't expect a release
 anywhere this year) will indeed support MODS through citeproc:
 
   http://xbiblio.sourceforge.net/citeproc/

As the author of citeproc (hi Taco!), let me just update people on recent
developments there, which are currently in the project subversion repository*,
but not yet officially released.

First, I have switched to using a particular RDF/XML as the internal
representation, and also therefore the primary input format. I will likely be
adding back a MODS input driver when I get a chance, but it's no longer the
focus. I will also be releasing a schema for this RDF representation for people
that need it.

The primary reason for this change is that in comparison to MODS, RDF has a
consistent model that makes it easier to model reference metadata. It's also
fundamentally a relational model, and so easier to integrate with relational
databases where needed.

Also, I am working with the OpenDocument Technical Committee on a plan to add
extensible metadata support using this RDF-based approach, so we hope to adopt
this in OpenOffice as well (I am co-project lead for the OOo bib project).

Second, I have started porting CiteProc to Ruby (and put a citeproc-py directory
in the repo for those python coders that might want to contribute), which might
integrate better with ConTeXt. (I suppose Lua might also be an option given the
integration with pdftex?) In any case, this will take me a bit of time as a) I
don't have much of it, and b) my coding skills aren't that great.

But the actual formatting code (Ruby, XSLT, etc.) is to my mind less important
than the logic as embedded in the XML citation style language I wrote to
configure the formatting.

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

Bruce

* http://svn.sourceforge.net/viewcvs.cgi/xbiblio/

___
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context


Re: [NTG-context] typescript repository

2009-03-24 Thread Bruce D'Arcus
Wolfgang Schuster schuster.wolfgang at googlemail.com writes:

 Am 23.03.2009 um 22:51 schrieb Mohamed Bana:
 
  I personally would like see a professionally done typescript for  
  Minion and Warnock Pro with Myriad and Cronos Pro.  I posted mine a  
  while ago, but I got no feed back.
 
 Because people need the fonts to make a test and Adobes *free* Minion/ 
 Myriad
 come only with four styles (no opticals). You could also opticals with  
 MkIV
 but it requires more work - http://wiki.contextgarden.net/Optical_Size

I think:

a) dealing with typescripts in ConteXt is a far bigger problem than 
it should be

b) that it's fantastically good idea to have a repository of 
typescripts to address this problem

c) that there's no reason at all to make a distinction between free 
and professional fonts in such a repository

As for how to do it, I could imagine using the wiki. But I could also 
imagine some other approach, like someone starting a project on GitHub or
something similar.

Bruce




___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : https://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___


Re: [NTG-context] New bib module

2009-03-31 Thread Bruce D'Arcus
Wolfgang Schuster schuster.wolfgang at googlemail.com writes:

 Am 31.03.2009 um 09:27 schrieb Taco Hoekwater:
 
  Will this new module also provide BibX support?
 
  Perhaps ;)
 
  On the input side, the new module will load bibliographies from disk
  into an internal XML structure and then use lpath queries to fetch
  bibliographic data. It will use separate loaders to do so, so in
  the end, anything can be plugged in as long as it can be converted
  to the internal structure.
 
 Why not just a lua table to save the data?

Yes, I was wondering the same thing. This is typically how the various CSL
implementations work; parse the input data (XML, RDF, BibTeX, etc.) into some
internal structure.

Bruce

___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : https://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___


Re: [NTG-context] New bib module

2009-04-01 Thread Bruce D'Arcus
Taco Hoekwater taco at elvenkind.com writes:

 Bruce D'Arcus wrote:
  Wolfgang Schuster schuster.wolfgang at googlemail.com writes:
  
  Am 31.03.2009 um 09:27 schrieb Taco Hoekwater:
 
  Will this new module also provide BibX support?
  Perhaps ;)
 
  On the input side, the new module will load bibliographies from disk
  into an internal XML structure and then use lpath queries to fetch
  bibliographic data. It will use separate loaders to do so, so in
  the end, anything can be plugged in as long as it can be converted
  to the internal structure.
  Why not just a lua table to save the data?
  
  Yes, I was wondering the same thing. This is typically how the various CSL
  implementations work; parse the input data (XML, RDF, BibTeX, etc.) into 
  some
  internal structure.
 
 I was't clear enough. internal XML structure actually is a lua
 table structure. It just follows a bunch of special rules that
 make lpath queries work.

So it's a native Lua mapping of an XML model? E.g. something like, say, element
tree provides for Python?

Does that suggest that the input data is always XML?

Bruce

PS - Frank Bennett has been doing a lot of promising work on a rewrite of
Zotero's javscript-based CSL processor:
http://xbiblio.svn.sourceforge.net/viewvc/xbiblio/citeproc-js/trunk/.

___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : https://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___


Re: [NTG-context] bibmodule (again)

2009-05-14 Thread Bruce D'Arcus
Taco Hoekwater taco at elvenkind.com writes:

 The new structure and referencing code is totally different from
 the old code and I understand less than half of it. What's worse:
 I seem to be really bad at explaining to Hans all the things that
 should happen wrt. references in the bib module.

:-)

FWIW, Frank Bennett has completely written the Zotero Javascript CSL engine to
be faster and easier to maintain and extend. It's also now independently hosted
and developed.

http://bitbucket.org/fbennett/citeproc-js

Bruce

___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : https://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___


Re: [NTG-context] Seeking a Deeper ConTeXt: Questions f or Initializing

2009-05-26 Thread Bruce D'Arcus
Hans Hagen pragma at wxs.nl writes:

...

 in which case it keeps the input in xml and converts to other formats 
 (coule be tex in the case of rendering print).

As Hans says, if you're interesting in integrating XML and RDF in source
documents, you need to think of ConTeXt as a lower-level output format; not the
other way around.

Depending on your needs, I'd consider two options for the source format: XHTML +
RDFa, and OpenDocument 1.2 (which will include RDF and RDFa support; likely to
be implemented first in OpenOffice 3.2). DocBook is an option too, but does not
AFAIK support RDFa.

In any case, I'd worry less about the technology, and more about what you need
from it. That will make it easier to figure out which approach is best.

Bruce



___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : https://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___


Re: [NTG-context] Seeking a Deeper ConTeXt: Questions for Initializing

2009-05-26 Thread Bruce D'Arcus
John Haltiwanger john.haltiwanger at gmail.com writes:

[...]

 Markdown with RDFa on the side will suit quite nicely, thanks to pandoc. 

Actually, you can embed the RDFa within the markdown files if you like. 

div property=x:section

# Introduction

Test.
/div

Pandoc will just pass it on to the output XHTML (though throw it out for the
context). But it's admittedly a little awkward to have to wrap the markdown with
XHTML every time to want to add a triple.

Bruce

___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : https://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___


[NTG-context] Re: ConTeXt Switcher?

2003-12-14 Thread Bruce D'Arcus
someone (not sure who) said:
 I know XML source should work, but at least for me, creating XML source 
 is unproductive.  I work with a text editor and find writing this:
 
 ``Hello world,'' says HAL.
 
 much more productive than writing this:
 
 p#8220;Hello world#8221;/p, says HAL.
 
 Maybe I'm missing something, but for writing, XML's markup requirements 
 -- which are invisible to field-based data entry screen -- are way too 
 intense for hand-editing. TeX source is much less verbose. It is easier 
 to create, proof (both visually and audibly),  spell check 
 troubleshoot, etc. I have not seen an editor capable of doing XML 
 source in a productive manner, like (La)TeX with text editor.

You're missing something.  For one, your above example would be:

pqHello world/q, says HAL./p

Second, try something like nXML mode for emacs, or the XML plug-in for
jEdit.  Real-time markup validation, tag-completion, spell-checking,
etc.

Finally, you're missing the biggest point of all: XML is about reuse.
You cleanly separate markup from presentation so that -- among other
things -- you can trivially transform that to different output.

Bruce 

___
ntg-context mailing list
[EMAIL PROTECTED]
http://www.ntg.nl/mailman/listinfo/ntg-context


[NTG-context] Re: mag-0008 (was: XML formulas)

2004-12-13 Thread Bruce D'Arcus
On Dec 13, 2004, at 1:02 PM, Adam Lindsay wrote:
What I propose is clearly a debatable XML-design issue, but it seemed
strange that fx:definelayout and fx:p were put into the same namespace.
Why do the formatting definitions share the same (theoretical) schema 
as
markup? Your documents keep these categories separate, as one would
expect. Why not encourage people to put them in separate files, as with
normal ConTeXt workflows? The designer and author are more clearly
divorced when you don't assume an XSLT-centric flow, right?
FWIW, I'm currently working on a comprehensive XSLT-based solution for 
bibliographic formatting (think bibtex for xml, only better).  In that, 
I'm working across multiple namespaces:

1)  document (docbook ng)
2)  bibliographic data (mods)
3)  a citation formatting language (homegrown; again, in its own 
namespace)
4)  output (xhtml, for example)

I agree with the notion that, in principle, semantic document markup 
should be in a separate namespace from the formatting language.

BTW, Hans, I've yet to see the ContML schema.  Care to post it 
somewhere?

Also, FYI, I and an engineer at Sun have some up with a small citation 
schema designed for embedding in other XML dialects.  It has been 
approved for OpenOffice.

http://www.users.muohio.edu/darcusb/files/citation-schema.tar.gz
It's more for GUI apps (it's rather verbose), but could still be useful 
in other contexts.

Bruce
___
ntg-context mailing list
[EMAIL PROTECTED]
http://www.ntg.nl/mailman/listinfo/ntg-context


[NTG-context] Re: mag-0008

2004-12-16 Thread Bruce D'Arcus
On Dec 15, 2004, at 12:16 PM, Hans Hagen wrote:
that was from the time that i played with schema's, nowadays i prefer 
relax ng
Indeed!
It may be worth noting that the next generation versions of both 
DocBook and TEI:

	-	are developed in RELAX NG
	-	are namespaced
	-	are designed for customizability, including mixing-and-matching 
definitions across the schemas

Bruce
___
ntg-context mailing list
[EMAIL PROTECTED]
http://www.ntg.nl/mailman/listinfo/ntg-context


Re: [NTG-context] presentation (simple-slides?) master-like feature?

2009-10-29 Thread Bruce D'Arcus
On Wed, Oct 28, 2009 at 2:40 PM, Aditya Mahajan adit...@umich.edu wrote:
 On Wed, 28 Oct 2009, Thomas A. Schmitz wrote:

 Bruce,

 very briefly: I'm very very short on time this week, so won't be able to
 look into this until middle of next week, but I just wanted to let you know
 that I find your idea great. I had been thinking of adding an xml template
 for simple presentations. your html-based stuff looks gorgeous, so I would
 like to know more about it. And let us know what exactly it is that you're
 missing in simple-slides. In theory, titles are typeset in layers, so
 everything should be there.

 I also like this idea. In fact, it will not be too difficult to map these to
 simple-slides. Basically

      li class=slide title
        h1Test Slide Show/h1
      /li

 should be translated to

     \setupTitle[title=Test Slide Show,author=,date=]
     \placeTitle

Well, except that I want the option to have this sort of rendering
elsewhere in the presentation. I see you address that in a followup;
would love to see you add that macro.

BTW, I'm an  academic as well, so using this for both teaching and
research presentations (my immediate concern here; have a talk coming
up in a few weeks I'd like to try this on).

 and
     li class=slide
        h1Hello/h1
        ul
          lione/li
          litwo/li
        /ul
      /li

 should be translated to

    \SlideTitle{Hello}
    \startitemize
        \item one
        \item two
    \stopitemize

 we currently do not have any specific environment for blockquote (but Thomas
 and I have discussed adding something similar). The vanilla ConTeXt
 equivalent \startblockquote ... \stopblockquote doesn't do anything fancy.

 Finally,
        li class=slide imgbig
           h1Container Ships/h1
           img src=filename.jpg /
        /li

 should be translated to

    \IncludePicture[horizontal][filename.jpg]{Container Ships}


 I do not know what is the best way to do these translations. ConTeXt can
 also handle XML files, so it is just a matter of writing the translation
 rules in ConTeXt. Or, if you prefer, you can write an XSLT transformation.

Yeah, using XSLT is pretty straightforward for this.

Bruce
___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___