Article View: comp.text.sgml
Article #46Re: Identifying Overlaps
From: Darrell Raymond
Date: Thu, 23 Jul 1992 18:54
Date: Thu, 23 Jul 1992 18:54
128 lines
6098 bytes
6098 bytes
I said:
> Here is the text:
>
> now is the time for all good
>
> And the contents of each element (and of their overlaps) is defined as
>follows (where the operator "^" means intersection):
>
> X: now is the for
> Y: is the for all
> Z: the for all good <-- Typo? Should Z contain 'the'?
> X^Y: is for
> X^Z: the for
> Y^Z: for all
> X^Y^Z: for
...but I blew it. The typo is actually in Y, which should be "is time
for all". Here's the Venn diagram.
......... .........
.... .... .... ....
X .. ... ... Y
.. .. .. ..
.. .. . .
. . .. ..
.. .. . .
.. .. . .
. . . .
. . is . .
. . . .
. now . . time .
. . ......... .. ..
. .... .... .
. .. . for . ... .
. .. . . .. .
. .. . . . .
. . the . .. all .. ..
.. .. .. .. . ..
.. .. ... . ..
... ... ... ...
.............. ..............
. .
. .
. good ..
. .
Z . .
. .
. .
. ..
.. ..
.. ..
... ...
.............
But anyway, let's look at Eliot's solutions. The first one succeeded
<x start>now <y start>is the <z start>for<x end> all<y end> good<z start>
...only because Eliot left "time" out of the text, and thus made X
contiguous, only because I botched the specification and made Y contiguous,
and only because Eliot cleverly discarded the leading word from Z and hence
made Z contiguous. If specified properly and not ingeniously corrected,
this approach fails. Part of the "gotcha" is that the fragments are not
contiguous and so you can't just bracket the start and end of each fragment
with tags.
>If the markup didn't all have to be embeded in the string itself
>I could use HyTime location functions to define each of the spans
>(or DSSSL location function), or define my own markup that
>did so. I could also define indirect methods where I identify
>each different part and then combine them.
I think I am being fair in insisting that external structure not
be classified as "markup". If I allow you to claim that non-embedded
structure is really markup, then I guess I get to claim that FulText
indexes are also markup too! In fact, any and every structure then
becomes markup. In that case, please tell me what word you would
like to use for "little codes inserted in the text that tell me
something about its structure", and I will reword the problem to
ask for that instead.
>I could also define
>my processor such that it does string comparisons, with something
>like this:
>
> <text id=x>now is the for</>
> <text id=y>is the for all</>
> <text id=z>for all good</>
> <intersect refids='x y'>X intersect Y
> <intersect refids='x z'>X intersect Z
> <intersect refids='y z'>Y intersect Z
> <intersect refids='x y z'>X intersect Y intersect Z
This solution fails for some other reasonable programs because it
makes copies of the text, thus breaking applications that naively do
things like count the number of words, or that try to substitute
"some" for "all".
>I could also define a "delta-chain" structure, like so:
>
> <text id=base>now is the for</>
> <text id=x refid=base><!-- No change as x=base -->
> <text id=y refid=x><deletion start=1 len=4><text>all</text></text>
> <text id=z refid=y><deletion start=1 len=7><text>good</text></text>
Even worse. Now in order to do something reasonable like search
for the phrase, I actually have to execute a program (the one embedded
in your deletion elements) just to get back the plain text!!
>I think the first solution meets the letter of Darrell's new
>challenge, if not the spirit. The other solutions demonstrate
>other approaches to the problem of identifying relationships
>among data elements that are not strictly hierarchical.
The first type of solution solved the wrong problem, partly due to my
error. I think it fails in general anyway.
The second type of solution violates the constraints of the problem
by appealing to structures that can't by any reasonable stretch of the
imagination be called markup.
The third type of solution involves not just marking up the text, but
dismembering it and beating it to within an inch of its life, so to speak.
Not to mention rendering it unusable for other reasonable programs.
-Darrell.
Technical Details
Message-ID:
<Bruv6B.n3o@watdragon.waterloo.edu>Path:
arc1-ca.pugleaf.net!sparky!uunet!utcsri!torn!watserv1!watdragon.waterloo.edu!drraymonReferences:
<9207231518.AA22593@ucbvax.Berkeley.EDU>Show Full Headers
Complete Article Headers
Newsgroups: comp.text.sgml Path: arc1-ca.pugleaf.net!sparky!uunet!utcsri!torn!watserv1!watdragon.waterloo.edu!drraymon From: drraymon@watdragon.waterloo.edu (Darrell Raymond) Subject: Re: Identifying Overlaps Message-ID: <Bruv6B.n3o@watdragon.waterloo.edu> Organization: University of Waterloo References: <9207231518.AA22593@ucbvax.Berkeley.EDU> Date: Thu, 23 Jul 1992 18:54:10 GMT Lines: 128