Re: Draft Treaty On Links

[Marc Stiegler <marcs>]

markm states:

When selecting this line on
the Link-list display, presumably the front-end will give the user a
choice of which of the documents-on-the-other-side to go to.

Note that first class links do not make the need to support this extra
complexity of interaction go away.  In our famous "A(N)" example, were
the links first class, the Bert Context of the link would
unambiguously be A1.  I haven't heard anyone yet suggest that "A1" is
the right choice of default in this scenario. To my mind, the scenario
argues even more strongly against first-class links than it does
against embedded links.
-------
Indeed, neither embedded nor first class links make this issue
go away; the problem is stunningly fundamental. One of the points
in the A(N) example was that A2 was a perfectly reasonable target
even though the link wasn't embedded within it. No matter how
many instances of the link there are (1 or 3), there are even
more perfectly reasonable choices of default (4).

Basically, I believe that the mechanism for selecting the most likely
desired Bert Context is fundamentally different, actually a
frontend function (I think this may be the first time I've ever
used the standard Xanadu phrase for shirking a responsibility;
of course, since I am so much more closely connected with the
design issues in the frontend, I'm actually ACCEPTING a 
responsibility :-).

As I noted in an earlier message on this topic, the closest thing
to an acceptable solution I've yet heard is dean's proposal that
the best default Bert Context is the Bert Context of the most
recently used Bert-that-contains-the-endset.

Anyway, to me it appears that embedded links add noise to the
problem of picking the right bert context, rather than solving it.
 This is one of my major complaints about embedded links (it adds
noise in that you wind up with 3 representations of the same
link, a link that has 4 contexts you might want. And none of our
current filtering criteria can select them down to 1).

I can't help observing that, if we backfollow and collect all links
first, then do EQ tests on all the links we found in the backfollow,
we get to perform N * (N-1) comparisons, where N is the total
number of links found in the backfollow. This is probably not 
a problem since N will tend to be small, but it grates on me a 
little (or will the backend return these links in sorted order, so
that you only have to compare a link with the next one in the
series to determine whether they are identical?).

Coming at this whole issue from a very different direction,
there is a theoretical filtering criterion that would reduce 
my objections to embedded links: being able to filter by
project. If every document was part of one or more
projects, and you could filter for project, it might be reasonable
to represent each Bert found in the backfollow separately
(and you would only see berts in the projects you've filtered
for). Once again, embedded or not is uninteresting--if A2 were
a part of the project and A3 were not, you'd get a listing for 
A2 and not A3--but it gives you a good filter for these links 
that are otherwise similar.

However, I've not thought of a way of implementing projects
that doesn't depend on mind reading--it requires that the 
user tell the software about it when the user changes projects.
I consider such a mechanism to be just too unreliable.

I think there's a solution to filtering-by-project when we 
implement sophisticated tabletops. But we've already 
postponed sophisticated tabletops till Release 2. And at this
point in the history of the frontend, it is time
to find some capabilities to eliminate, not capabilities to add.

Still, I think that if a third alternative exists, it exists in 
this direction. What innovative ideas do people have for
associating documents with projects, so that filtering
by project works well?

--marcs