Subject:
|
Re: Element search with fuzzy categories
|
Newsgroups:
|
lugnet.admin.database
|
Date:
|
Mon, 11 Jan 1999 04:32:14 GMT
|
Viewed:
|
642 times
|
| |
|
|
"Tim McSweeney" <tim##NO_SPAM##@ams.co.nz> writes:
> [...]
> If you have a well connected graph of concepts that exist (Which is probably
> pretty accurate) then every single thing in the database is probably
> connected somehow (Seven degrees of seperation :) and searchs will return
> the whole guide.
>
> even withut a fullblown graph a search for "Castle" will return all of the
> elements associated with the castle theme when all you probably wanted was
> the things like castle wallplates, doors etc.
Right-o. The real thingie (remember, the /dbtoys/elementsearch/ thingie is
just a toy/prototype) will need to be smart like that, so it knows what's too
little to return vs. what's too much.
> > Well, thanks. :) I don't know that it's anything new, though -- the
> > algorithm probably was invented and published 20 or 30 years ago by someone...
> > I haven't scoured the journals to see...
>
> Are there any new inventions? or are they just cool new ways of using old
> solutions.
Dunno. Maybe some of both, but probably few if any new ideas. Probably a lot
of re-using/re-discovering/re-inventing a lot of old stuff that's already
known. From an algorithms perspective, expanding a fuzzy-weighted tree isn't
much more difficult than a 2-dimensional matrix flood-fill (both involve queues
and domain-exploration). It's impossible to know and keep track of everything
that's already been discovered, and it's not much fun worrying about it.
Speaking of flood fills, I once came up with this nifty flood-fill-like method
for efficiently choosing the shortest path between a Pac-Man ghost/monster and
the Pac-Man in an arbitrary maze. A couple years later I was flipping through
a book at the bookstore and it turns out the algorithm had already been
discovered in 1954. I felt bad for a few hours (stupid ego thing), then
decided it's not worth caring whether some algorithm is new or not, only if its
application is useful to its problem domain. :)
> Hmm do I understand from my re-reading of the plan that the database will be
> maintainable by the users? ie we can add our own pieces etc a they are
> discovered. What about creating categories and maintaining the fuzzy
> associations?
Yes to all, but not in an anarchical way. Anyone will be able to submit new
data for incorporation, but new data isn't guaranteed to appear; new data will
go through checks & balances and a decision-hierarchy of N people. There might
be, for example, a team of 3 or 4 Castle System experts (volunteers) who would
approve or reject all Castle set entries. Anything passing that layer would
bubble up to another layer for review and approval or rejection back down a
layer. Then there'll be a team of N people (probably in specialty layers) who
approve changepoint requests for elements. And another for catalogs, or new
members (people), etc. Basically a big interconnected web of checks and
balances at all layers of the data, to weed out as much garbage and
misinformation as possible and to keep things as consistent as possible (names,
structure, etc.).
As a super-duper-tiny example, all applications for permission to post news
articles here go through a review process. Each application is either approved
or denied, and an e-mail is sent out. The process is currently handled by one
person (me) with no above-layer and no below-layers, but it doesn't necessarily
have to be that simplistic.
Another example in the opposite direction... The evolving mini-DB at
<http://www.lugnet.com/pause/search/> is an anarchy -- there are 4 people with
admin access to add entries and modify existing entries, with no checks and
balances other than voluntary e-mail cooperation. In other words, the system
currently does nothing to help its administrators communicate with one another
or review each other's changes. It's suboptimal -- and not a step in the
desired direction -- but it's OK for now, as a stop-gap until the real thing.
> Will The databases be merged so that a search for "Castle" will return all
> castle pieces and sets?
Yes. Of course, what data is actually returned as the result of a search
(whether it's all castle sets & pieces, or just pieces, or just sets) is an
interface issue. Probably, if you typed something so general as simply
"castle" into a quick-search box, it would give you some sub-categories instead
of a full-blown list of everything related to castle stuff (which is hundreds
and hundreds of things).
> if so then presumable a search for "Castle Pieces" will only return the
> actuall pieces?
That would be a nice interface.
> It should also be possible to include MOC's as well. "Castle set not MOC"
> would give you official lego Castle sets?
That would be nice too.
--Todd
|
|
Message is in Reply To:
 | | Re: Element search with fuzzy categories
|
| (...) on (...) Egypt... That sounds like a good idea. If the results told you something of the logic the engine followed to get to each hit you would have a better chance of rewording your query to avoid the spurious results. from a UI point of view (...) (26 years ago, 11-Jan-99, to lugnet.admin.database)
|
5 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
Active threads in Database
|
|
|
|
|
|
