If someone else were getting started and didn't want to assemble their 
own training data -- do you think it would be likely useful for them to 
aggregate your training data _and_ Brown's training data together and 
generate a new model?  Was there a particular reason you chose not to 
use Brown's training data and add on it to it, but start over from scratch?

Forgive me if this is a stupid question, I'm still trying to learn about 
this stuff.

And start to figure out how I'm going to deal with it when I get around 
to using FreeCite, which I surely will. Would it maybe make sense to 
actually seperate the training data and trained model in a seperate 
library, so people could even pick and choose what already built trained 
model they want to use, or build their own, without dealing with repo 
conflicts?

> The training data is not currently under source control (it's in the 
> database), but the trained model is.
>
> That's, admittedly, a bit of a downside to my fork (although the model 
> being checked into git is true of the original, as well) since you'd 
> always be in conflict with my trained model if you train your own.
>
> -Ross.
>
> On Monday, October 17, 2011, Jonathan Rochkind <[log in to unmask] 
> <mailto:[log in to unmask]>> wrote:
> > When you say you've added to the training data, have you shared your 
> additions back with Brown, or your new improved training data is only 
> in your fork? Or is only held locally by you and isn't even in your 
> github fork?  Please clarify, thanks!
> >
> > On 10/13/2011 8:52 PM, Ross Singer wrote:
> >>
> >> Yeah, we've been doing a lot with (and putting a lot of updates into)
> >> FreeCite.  We only use the webservice (although we don't use the
> >> OpenURL context object and instead added a JSON response).  It works
> >> pretty well (not always great, but certainly better than nothing) -
> >> especially for giving us something "good enough" to throw against some
> >> OpenLibrary and Crossref data to look for matches.  Basically what
> >> we're using it for is to go from a citation string to an RDF graph.
> >>
> >> BTW, there have been no problems with post-2000 dates (not to say that
> >> there aren't plenty of other problems) - this might have been either a
> >> training issue or something a later version of CRF++ worked out.  We
> >> also add the citations it couldn't parse correctly to its training
> >> data, which might help this.
> >>
> >> Anyway, yeah, if anybody is interested, feel free to try it out.  One
> >> thing my fork does is remove the PostgreSQL dependency, if that's an
> >> issue for anybody.  It's kind of handy to be able to just use SQLite
> >> or MySQL or whatever to try it out.
> >>
> >> -Ross.
> >>
> >> On Thu, Oct 13, 2011 at 7:42 PM, Avram Lyon<[log in to unmask] 
> <mailto:[log in to unmask]>>  wrote:
> >>>
> >>> On Thu, Oct 13, 2011 at 2:33 PM, Will Kurt<[log in to unmask] 
> <mailto:[log in to unmask]>>  wrote:
> >>>>
> >>>> I always think that Brown's FreeCite api is under utilized.
> >>>> http://freecite.library.brown.edu/
> >>>> It's far from perfect, but I'm sure more use could be made of it.
> >>>>
> >>>> A few months back I threw together a copy/paste citation look-up 
> with it:
> >>>> CiteBox
> >>>> http://willkurt.github.com/CiteBox/
> >>>>
> >>>> Of course I don't think anyone is really making use of it, but I've
> >>>> also done nothing to really promote it either ;)
> >>>
> >>> The FreeCite parser had major issues for a while with post-2000 dates,
> >>> and I believe the installation at Brown still does, but, to judge by
> >>> the GitHub activity (most active fork here:
> >>> https://github.com/rsinger/free_cite/), some enterprising folks have
> >>> picked it up after a period of apparent dormancy. This is great to
> >>> see, and vital to any project that hopes to use its API for anything
> >>> serious.
> >>>
> >>> By the way, the rarely-used XML representation of OpenURL
> >>> ContextObjects that FreeCite produces is supported by Zotero as a
> >>> full-fledged input format, a fact that might come in handy if you're
> >>> hoping to have your API produce something that Zotero users can
> >>> import.
> >>>
> >>> Avram
> >>>
> >>> UCLA Slavic, Zotero community dev
> >>>
> >