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 Green code.
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 'middle end'.
A slightly longer answer is "Middle end", it is some other mechanism perhaps strongly coupled to the backend, but not of it. In other wordsit's modular.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.
-Jeff