[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: How was Xanadu to handle value lookups?
- To: xanadu@xxxxxxxxxx, udanax@xxxxxxxxxx
- Subject: Re: How was Xanadu to handle value lookups?
- From: Jeff Rush <jrush@xxxxxxxxxx>
- Date: Tue, 15 Feb 2005 20:41:59 -0600
- In-reply-to: <1108230431.7903.53.camel@ds>
- References: <4fdbc18c14b8dad71125938f840f190a@xxxxxxxxxxxxx> <20050209104100.GH18048@xxxxxxxxxxxxxxxxxxxxxxx> <1108059765.4593.47.camel@ds> <1108167079.12586.30.camel@xxxxxxxxxxxxxxxxxxxx> <1108168891.12586.46.camel@xxxxxxxxxxxxxxxxxxxx> <1108170886.7903.18.camel@ds> <1108204689.14870.25.camel@xxxxxxxxxxxxxxxxxxxx> <1108230431.7903.53.camel@ds>
roger gregory wrote:
The short form answer is No. We don't believe in any of that, no sql
databased none of it.
Well, I think queries of *some* complex type are necessary. In fact to
me the existing Green ability of performing the ANDs of the ORs of the
link endpoints to locate those links that correspond to a certain
defined relationship is very similar to a (structured) query. In fact
I was using some SQL optimization techniques in implementing link
searches in my Python code. Nothing fancy but reordering of the ANDs to
eliminate as many failures cases as early as possible in the search.
Back to structured, it seems a link query for "find links from user A's
document group X that point to anything I've written, of link type
'quotation'" is pretty SQL-like. And I can do that with the existing
If a system could be found to induce/coordinate 'well known names' such
that when people linked to a keyword they were all using the tumbler
address for that keyword (think some kind of hash), then we gain
variable value searches.
The existing proposal of 'well-defined' type tumbler addresses is
similar but relies upon everyone agreeing which addresses to use; not
likely. But a scheme of well-known names like at erights.org (thanks
Mark), might be applied to this issue, which I guess might count as your
A slightly longer answer is "Middle end", it is some other mechanism
perhaps strongly coupled to the backend, but not of it. In other words
We saw the direction that sgml and databases were going and tried to
stay well away from it. Structured data, structured queries, faugh....
On Sat, 2005-02-12 at 02:38, Jeff Rush wrote:
The fact the the web is at all useful with mostly searching is
astounding to me, and is certain to get more unwieldy as time goes by,
and more documents accumulate.
I think we miscommunicated. I didn't mean the unstructured wide-ranging
textual search of Google, but rather a structured lookup like DNS or
LDAP. Something I can use to build a roster of forum members, or
directory of document/filenames, or diary of dated journal entries or
list of billable timesheet entries extractable by non-prearranged (i.e.
written originally in monthly journals) date range.
But I meant that, you don't expect Google to stay unstructured do you?
Actually I do, for the foreseeable future. There have been several
proposals of structured XML tag files on site roots, but Google never
stepped up and started parsing them.
The concepts of text + links is very powerful, but if you combine text +
links + lookups, you get all of the applications I listed above.
There isn't an existence proff of Links+text yet so it's hard to add
lookups to it.
Soon... as I've studied Xanadu and gotten my head around its concepts,
its amazing how simple and powerful it works out to be. I think its
possible to write a simple proof of link sieving in just a few pages of
Python, albeit without persistence or performance. ;-)
part of the problem here is that we couldn't see any general purpose way
to do it. Or rather too many ways that seem completely at odds with
each other, perhaps it would be useful to brainstorm out all the
possible ways m=one might want such extensions to work, and see if
anything jumped out of it.
I was just hoping I'd overlooked a plan to leverage the links
infrastructure without adding a new layer or using a totally separate
service. It would be elegant if such could be reused at different
levels of abstraction.