h a l f b a k e r yGetting blown into traffic is never fun.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Please log in.
Before you can vote, you need to register.
Please log in or create an account.
|
Database of everything
Now you _can_ compare apples to oranges, with an object-oriented database of everything | |
Object-oriented design mimics real life: objects have properties, and values for those properties, as well as behavior. All objects descend from the base abstract "object", which has properties that all objects possess. Other objects are derived from this object, or other objects also so derived, forming
an object heirarchy. Every derivation inherits the properties and behavior of its parent, and adds additional properties and functionality of its own.
Anyway, we can use this technology to build a database of everything. As we build, we will identify objects, what object they descend from, what new and overridden properties and functionality they possess. Certain properties will coincide with properties of other objects. When we get finished, we will be able to compare any two objects, no matter how seemingly unrelated they are, and from our database get values from any matching properties anywhere up the object heirarchy. And we can get a true, accurate, usable comparison of apples and oranges. We will be able to decide which is better, Michael Douglas films or programmable calculators. We can decide between alligator soup and church bells. Cat food or the Constitution? Shakespeare plays or Texas? Tunafish or Basketball? Think of the comparison possibilities that are, until now, unfathomable. All because of object-oriented technology and our new database of everything.
Cyc
http://www.cyc.com/
If it could be baked, they would have baked it. Suffice it to say that invoking Cyc among AI researchers is something akin to invoking Hitler among historians. [egnor, May 04 2001, last modified Oct 21 2004]
Knowledge Representation
http://directory.go...dge_Representation/
This is what you're talking about. It's a deep and largely unsolved field. Feel free to follow some of these links and start learning; I suspect that if you do, you will eventually give up with your brain tied in knots. [egnor, May 04 2001, last modified Oct 21 2004]
Ontologies
http://www.lsi.upc....gic/ON-TO/ON-TO.htm
Specifically, you are proposing that we build an Ontology of Everything. This is pretty much a classic mistake AI newbies make. This is not an easy problem, and simply waving the "O-O" magic wand ("no programming required" my ass!) won't change that. [egnor, May 04 2001, last modified Oct 21 2004]
everything2
http://www.everything2.com/
This really has nothing to do with what you're proposing, but if I don't add this link someone else will. [egnor, May 04 2001, last modified Oct 21 2004]
Semantic Networks
http://www.duke.edu...nn/mwb/15semnet.htm
With your talk of "Texas ... Executions ... Shakespeare", it sounds like you might want something from this particular well-explored field. Many of these systems are capable of finding paths between points. This particular page talks about "Insight Generators" used for marketing purposes (?) that do something very close to what you're describing. [egnor, May 04 2001, last modified Oct 21 2004]
W3C Semantic Web Activity
http://www.w3.org/2001/sw/Activity
I'm sure someone will bring this up. [egnor, May 04 2001, last modified Oct 21 2004]
NHFSD
http://www.halfbakery.com/idea/NHFSD
Non-hierarchical file management system with properties of database with unlimited number of fields [Inyuki, Oct 21 2004]
[link]
|
| |
Take away the comparison bit??? That's the whole point! See, ravenswood understands! |
|
| |
"Better" is subjective but since everyone's individual worldview would also be in the database than certainly the DB o' E would be able to define "better" in the same terms used by the person querying it. Simp. An order of techno-monks under the leadership of Abbot globaltourniquet should be able to knock this out in a few hundred years, don't you think? |
|
| |
[Peter (you posted while I had my pinky stuck between caps lock and "A") ]: Maybe the point of globaltourniquet's DB o' E is to catalogue all the properties of each object--not a trivial task--and then one would not have to input all the qualities of Texas and Shakespeare before applying the (admittedly rather magical) comparison algorithm. |
|
| |
But whatta I know? I have to use Access, forgawdsake.| — | Dog Ed,
May 04 2001, last modified May 05 2001 |
|
|
| |
(Which is better, trained monkeys or techno-monks?) |
|
| |
[Peter] No magic, but the ability to easily categorize properties and functionality. The beauty of O-O is that you would need no algorithm. The object encapsulates the data about it, no programming required. Take like properties and compare the values straight-up. As for quantifying "better", you could specify the parameters of "good" at search time. There would be default assumptions, possibly (as Dog Ed suggests) based loosely on also-contained individual world-view. |
|
| |
So, comparing Shakespeare plays to Texas, we might get a "better" result for Shakespeare plays if we parameterize the query with "things that don't execute too many people are better." (Titus Andronicus included...) |
|
| |
"The beauty of O-O is that you
need no algorithm. The object
encapsulates the data about it, no
programming required." |
|
| |
Go start building it, and you'll
quickly discover that what seems
simple and straightforward to you
now -- objects and properties and
relations and comparisons -- is
not only complex and tricky, but
so complex and tricky that it has
stymied and confused the best of
our minds, ever. |
|
| |
If we could simply "build an O-O
database of everything", don't you
think somebody would have done so
by now? To be sure, people have
tried; I'll add links. |
|
| |
I challenge you to invent and
defend even a simple example of a
small part of your database. |
|
| |
I never claimed the task would be easy. It will take a couple of decades, perhaps. But they cracked the genetic code, didn't they? That took a while too... |
|
| |
Of course it's possible. Tricky? Certainly. It's tricky putting together an O-O model for the relatively simple answering service billing program I'm currently working on. But once the model is in place, the data, while time-consuming, will be fairly straight-forward to load into the database. There would be some controversy while decisions had to be made whether tomato is subclassed from vegetable or fruit, but we can work all that out.... |
|
| |
[egnor] You are overextending my idea. I'm not asking for AI here. I don't imagine we can simply make a database that will give us the answer to life, the universe and everything, or even recommend a cure for cancer. Just a cross-reference database that will allow me to compare Shakespeare plays to Texas, based on the properties of these items that we can come up with. I can make a small model in less than a day. The issue is coming up with all of the desired properties and functionality. That will take a couple or few decades. |
|
| |
<fruit>If you're gonna play Shakespeare in Texas, ya gotta have a fiddle in the bard *dodges tomatoes*</fruit> |
|
| |
but how do you organize them?
on a colour wheel or by family tree? |
|
| |
Where do the knives go? In the knife drawer?
Does the bread knife go in there? The best silver knives? The Stanley knife from my toolbox? Palette knives?
OO is very, very limited in any but a few limited knowledge domains. |
|
| |
global: I think that the database no matter how easy or hard to create would not yield the results you're looking for. |
|
| |
If you compared a shakespeare play to an orange you'd have great difficulty finding any properties that matched (and even if the property names matched they would probably be referring to different things). However, since I get the feeling yhat you wrote this with you tongue firmly lodged in your cheek I won't bat on about it. |
|
| |
What you do have, though is an interesting slant on indexing the internet. You could look at something like the yahoo structure and continue the tree until you get to specific bits of information. |
|
| |
people.william_shakespeare[1].plays.live_performances.reviews might lead to an interesting list of sites if you want to go to a play. |
|
| |
That must make typing a thought-provoking experience. |
|
| |
Acrually st3f, I was partly kind of hoping for reaction from people on comparing odd things, and how it might work. Like Shakespeare plays and Texas could be compared on the execution level. |
|
| |
You say it wouldn't yield the results I'm looking for. Au contraire, I'm looking for automated, stretched connections and associations, even if they are by double meaning. I would find that amusing and enlightening. Mind-strertching, if you will. Like cryptic crosswords. It would be fascinating to see if more people are executed in Shakespeare's plays than in Texas. |
|
| |
As for other comparisons, commonly basil is an ingredient of alligator soup. Well, aren't there church bells in St. Basil's cathedral? See? There you go! |
|
| |
I admit the ROI is pretty low. But with enough effort, it _could_ be done. (Just like with enough effort, we could turn the moon pink.) |
|
| |
For those of you who claim that it can't be done "with no programming", what I mean is if the O-O model is well structured, if you don't care about a fancy UI (which duh of course would take programming), then all that would be required to get information is skillfully written queries. |
|
| |
I can mock you up a prototype for some objects we have already referenced right now (for you C++ types, forgive the object pascal-like pseudocode... I hate C++) |
|
| |
type
TPlayList = TList of TPlay;
TUSStateList = TList of TUSState;
|
|
| |
TLiteraryWork = class(TDocument) (or whatever);
author: TPerson;
etc
end;
|
|
| |
TPlay = class(TLiteraryWork)
NumberOfExecutions: integer;
etc etc
end;
|
|
| |
TUSState = class(TState)
name: string;
NumberOfExecutions: integer;
etc
end;
|
|
| |
now, for the queries (again, psuedo-code) |
|
| |
select texas.NumberOfExecutions, sum(shksp.NumberOfExecutions) from TUSStateList texas, TPlayList shksp where TUSStateList.name = 'Texas' and TPlayList.author = 'Shakespeare' |
|
| |
Of course given the above pseudo-code you would get repeated entries for Texas for every Shakespeare play (and vice-versa if there were more than one state named 'Texas'), but don't make me fix that. Suffice it to say that I could. |
|
| |
<Homer>mmmmmmm, caaaaake</Homer> |
|
| |
Ever read The Library of Babel by Jorge Luis Borges? |
|
| |
This would not work. To compare the number of executions in Texas with the number of executions in Shakespeare, you'd have to derive them both from a common superclass CThingsWithExecutionsInThem. You'd end up with each object derived from about a million classes. There would be some scope for inheritance expressing subclassing of concepts, but huge amounts of multiple inheritance. |
|
| |
For example, Richard II would be in CHistoryPlays derived from CPlays, derived from CLiteraryWorks, derived from CTexts, derived from CIntellectualCreations, but also in CFictionalisedHistory (which would inherit from CHistoryText), CThingsWithExecutionsInThem, CThingsMadeInEngland, CThingsContainingMirrors, etc. |
|
| |
But basically, making this object-oriented would add little to the useability. You cannot divide the whole world up by a tree structure in which each node has only one parent, and expect it to still express all the relationships between objects. |
|
| |
OO also wouldn't help when things can vary in their properties: how would you represent something which is both a tragedy and a history play, or comes in a wide range of colours from yellow through green to black? And you couldn't use Java, which doesn't allow multiple inheritance. |
|
| |
What you want to do is for each object assign a large number of fields representing different statistics, allowing multiple values in some fields, and try to keep the field names in common. So the entry for Richard II reads (in part) "Genre: History Play; art form: Play, Literature; Author: William Shakespeare; Themes: Divine rule of kings, self-deception, treason, justification for treason; Number of Executions: (I forget)..." Such a database would need algorithms to search it, but allowing algorithms to be defined afterwards gives more flexibility anyway. |
|
| |
Well, to me it sounds like someone who's just discovered OO and gotten terribly excited by it all, which is fair enough, because when it first clicks in it is exciting... and suddenly everything looks like an object. |
|
| |
But it your goal falls apart when you look at the problem in reverse. In your last example, you basically hard-coded a comparison of executions between Texas and a Shakespeare Play. Well, sure anyone can do that, but that's not what you really want, is it? Given that what you mean to say is that any object in the giant "tree" of everything can be compared to another, you are implying that an Orange must also possess, whether directly, or by inheritance, a "NumberOfExecutions" member. So would a Coffee Cup, Henry VIII, a Kodiak Bear, a Harvest Mouse, a Thames River Cruise, a Pick Axe, a Combine Harvester, and a Rabbit Warren. Everything, in fact, must share everyone else's comparable attributes, otherwise you can't do the kind of query you mocked up in the pseudo code, except upon strictly pre-defined pairs of objects (which defeats your goal). Even if some base object way up the ancestral tree contained all these comparable attributes (such as "NumberOfExecutions, NumberOfThorns,NumberOfTusks,ColorOfAntlers,NumberOfTeeth", etc), you are still dealing with a massive, massive unwieldy object somewhere up there - and that simply is not OO anymore - that's what they call a "Dog's Breakfast".... it's not a question of whether it would take 2 decades or 100 years - the end result would render the task a brutally ugly waste of time! |
|
| |
Further above, thinking about it a few seconds longer, this is possibly the least Object-Oriented idea I've ever heard of! What's the point of all that classification, etc, if ultimately everything is comparable to everything else through the same attributes?! It's like buying a Lotto game with all 40 numbers out of 40 selected! |
|
| |
//because when it first clicks in it is exciting... and suddenly everything looks like an object. //
So many times I have heard comments very similar to this describing the epiphany, the golden Aha! surrounding the moment that the OO concept comes into sharp relief in the mind. It must be a cool experience. Alas, I haven't had that moment, yet. |
|
| |
Good idea.
"Database with unlimited number of fields" migh be it. Every object = property. Every new record in database becomes also a new field.
So we may measure apples in oranges...(see link). However, in a database of everything, every object should have its set of [statements], not a set of IDs as it is in NHFSD. |
|
| |
It wouldn't work. By definition, the database itself would have to be in the database---which means it'd have to be in the database that's in the database, and so on. Of course, everything in the universe is related, so you'd eventually come full-circle and find yourself back in the original database. In fact, that may be what's going on right now. It's hard to be sure---everything is so realistic. |
|
| |
Database of everything? Umm, I think it's called "The World Wide Web". Your domain name is the primary key for information you publish. Your email address is the primary key for your online identity. |
|
| |
As far as creating a "database of everything" using OO techniques - you still need to define what descends from what, and that ain't trivial. |
|
| |
I have about 50,000 mp3s, and I have trouble putting them into categories. I mean, is this "folk rock" or "electro-folk" or "alt. acoustic"? I have albums that definitely fit into 1 but not all of the above categories. The more you try to classify things definitely, the harder it becomes, and this is using a limited domain of knowledge -- music. |
|
| |
After about two years working on the database design and various prototypes, I have now written a Database for Everything. I have called it the Ultimate Database and it seems to work. If anybody is interested then let me know. I am looking for contributors and investors. |
|
| |
[sohcahtoa314] how did you solve the fundamental and unbelievably tricky taxonomical problems associated with such a concept? |
|
| |
Also, does it run on MySQL? |
|
| |
By the way, yes I'm interested - if a little sceptical. |
|
| |
//If anybody is interested then let me know//
I am interested.
//I am looking for contributors and investors.//
I feel my interest waning somewhat. The problem with having objects like // which has properties that all objects possess // is that there are (at least) two possible problems. Russell's-type paradox and Ramsey theory. The former allows for exclusions of something from your everything and the latter gets very big very fast. |
|
| |
don't you just create a bunch of rdf triplets, put them in objects, and toss them in a database? |
|
| |
each triplet is an object. each item is a pointer to something. |
|
| |
then instead of doing people.bill. plays.live_performances you do |
|
| |
object['people'] ['involvedWith'] -> object['plays'] ['type'] -> object['live'] ['whatever'] -> object['reviews'] ['blah'] |
|
| |
then you just search by object and then pull everything else out by recursion and a handful of keys which of course you need to more or less have though you could get all keys. |
|
| |
see then you can pretend to have objects. and pretend to use rdf. because rdf is cack. it's like those herrings that icelanders piss on and bury in the snow, and then when it is rotten, they dig it out and eat it. |
|
| |