3 ms·

First of all, great presentation. I looked at the site and your phrasing combined with the domain name gave me an instant idea of what you do. Maybe some exampl

• cemerick 16y ago
  Thanks for the kind words. Indeed, I put a lot into the "first visit experience", and hopefully it's a reasonable first stab for this Tufte-reading programmer. :-) As for competition: (a) Nonconsumption (as the 37signals guys like to say). There's millions of people that have a directory of document type NNN that want to get some aspect of those documents into another form, but either (a) they don't have resources to get it done, or (b) the job/process isn't large enough for them to bother their IT folks with. If we can nail the UI, we should be able to capture some large chunk of this. (b) The relative waste of resources spent on non-core work related to extracting data from documents in medium-sized, usually internal software projects. These folks don't like spending the up-front money to license software to get the job done, and they don't like having to understand the minutiae of the processing involved; i.e. "I want text/images/form data/three number from the second page of each of these 10K documents, and I don't want to blow a week on figuring that out." (c) Manual entry. Organizations with very large document processing workflows currently spend millions shipping documents to "overseas" keying shops (almost all in south Asia). We have some things in the pipeline that might obsolete that practice, driving down error rates along with cost. Solutions for these customers would likely require a private installation or similar, so that's down the road a bit.
• semanticist 16y ago
  There's certainly a good amount of text extraction work in the recruitment industry - that's what the company I work for does and we have several competitors. In those cases, though, you're talking about taking CV/resume files in Word, PDF, HTML, whatever and extracting structured data for populating a recruitment company's databases. It's a bit more advanced than the kind of thing being done here, but it also requires special integration work to match the databases and handle things like candidate deduplication. CV/resume parsing isn't going to be an industry that you can get into unless you can hire some good sales guys and are ready to spend a lot of time figuring out how to integrate with a dozen different database products.
  • retube 16y ago
    Hmm that's extremely interesting. My company has developed technology to extract structured data from business websites, data types such as postal addresses, contact details (person name, phone, fax, email, job title, headshot), company logo, products (product name, prices & descriptions), food and drink on menus, business description, keywords/tags and so on. There's a fair amount of text and language analysis, machine learning, clustering algorithms. We can process a million sites (~100 million pages) in a few days. One of the pivots we were considering for this was Word/pdf docs, specifically CVs. We figured that these big recruitment companies and websites must have to process millions of loosely structured CV documents, and would need to extract specific data from these. I don't know what they do now, but I reckon we could do it pretty well.
    • semanticist 16y ago
      What they do now is use my employer's software or one of our competitors. There's several people already moving in this market, so it would be tricky to enter. One of the big things is going to be integrating with recruiter's databases - that's where most of our time is spent these days. That, and widening our language support.