in reply to Scraping HTML: orthodoxy and reality

"Parse" vs "extract" or "regular language" vs "context free," etc. are indeed important distinctions to be made, as pointed out by some monks. Parsing data is a (more or less) mechanical process; extracting info is a human (A.I.) process.

Suppose you want to extract info by paragraph. Consider the following text fragment:


Look at the table below...

ho ho ho...

Could you behold the secret this unfolds?

A bit more, a bit more, irrelevant thought, a new paragraph...


You might see either two or three paragraphs (if you consider "Look... unfolds?" as one paragraph). Now, let's look at the html of the above text fragment:
<p>Look at the table below... <table border="1"><tr><td><p>ho ho ho...</p></td></tr></table><br><br> Could you behold the secret this unfold?<br><br> A bit more, a bit more, irrelevant thought, a new paragraph...</p>

A parser might only see one paragraph between the <p> and </p> tags. There is a <p></p> pair in the table. Is it a paragraph? A parser might ask.

Suppose the parser takes into consideration that some people use <br><br> to denote the end of a paragraph. "Look..." and "Could..." might be considered two paragraphs. What about "A bit..."? Or are "Look..." and the table two paragraphs?

Human can read semantically; machine mostly syntactically. That's why extracting info is not the same problem as parsing data.

Replies are listed 'Best First'.
Re: Re: Scraping HTML: orthodoxy and reality
by BrowserUk (Pope) on Jul 08, 2003 at 20:01 UTC

    I applaud your attempt to clarify, though I don't necessarially agree with your example. For me, the difference between parsing something and and extracting something is that when I parse something, I am interested in the whole something. When I extract something, I am only interested in a small part of the whole.

    That's basically why using an HTML parser when all I want is an extraction, is so wasteful. I go to all the trouble of analysing (sometimes validating) and capturing the structure of the HTML only to throw all that effort away as soon as I have captured the bit I want.

    It's a bit like carefully dismantling, labelling and boxing an entire stately home, brick by brick, when the only part of value is the Adam's fireplace in the drawing room. If the rest of the place is simply going to be discarded, there really isn't any point in doing the extra work unless some conservation or restoration is intended. In code terms, that means I am going modify, reconstuct or otherwise utilise the structure I've spent the effort capturing. In a large majority of screen-scraping tasks, the structure is simply discarded.

    The argument for using a parser is that semantic knowledge gained from the structure is useful when used to locate the bits of data required, and that using the structural clues is more reliable (less brittle) when the page is updated than a dumb match by regex. The problem I have found is that when the page changes, the structure is just as likely to change in ways that require the script to be re-worked as is a match-by-context regex.

    For every example one way, there is a counter example the other, and I would never critisise anyone who chooses to use a parser for this purpose. I just wish that they would give my (and others) informed and cognisant choice to do otherwise, the same respect.

    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller

      What you said was logically sound. Apparently, "parse" and "extract" mean something very specific to you, whereas I merely used them in a loosey-goosey way.

      But I do make distinction between "data" and "info." This is data: "1I2N! 2r2U 1E! 1R 1f"; this is info: "FIRE! RUN!".