This is a year 2006 and you are talking about a database that is not search-able. Do you know this as a fact or some Meta told you this? In the same time you are stating that powers in DMOZ can not understand that there is something wrong with this. Would it be correct for me to draw a conclusion that powers in DMOZ must be total morons if they can not see what is wrong with this picture?
Gworld, given your tremendous technical know-how (as advertised in this forum thread) and your strong conviction that ODP needs a system to inform submitters that their sites were accepted, you will get nowhere by complaining here. Instead, you should be volunteering your services to develop a feedback system for ODP. ODP is a volunteer project. AOL owns and maintains the servers, but when ODP needs new technical resources there is no Sugar Daddy to create those resources for it. Instead, ODP depends on the services of volunteer editors.
gworld, it will not help to show your diplomatic licence from DP. For sure, there is no such thing, like getting a guarantee, granting immunity from "prosecution", should you decide to uncover your identity.
What kind of crap is that? Aren't you an Admin in DMOZ? As long as I have been following the DMOZ drama, which is probably closely for about 3 years or more now, every time the concept of an automated status system has been raised, without exception, DMOZ editors have entered the discussion with the standard party of line of "this has been suggested and discussed many times and it just is not going to happen because it will aid and abet spammers". Are you now trying to suggest that DMOZ would welcome such a suggestion and would explore how to implement it? Frankly, that sounds downright disingenuous to me.
Well, it seems I am getting somewhere if an Admin is willing to discuss the possibility of such implementation which is more than anybody succeeded in internal forum. My suggestion actually is more than just sending an email to inform people if their site is accepted which is not very useful and it includes the overhaul of the whole submission procedure and feedback system to clear up all the confusion people can have about what is happening with their submissions and also to help editor to be more efficient in processing the new listings. I am honored that you think so highly of me but implementing proper submission procedure and feedback for a directory is no mystery and I am sure there are many people here that are even more qualified than I am and in the same time users in DP can provide us with opinion and feedbacks regarding the system design. Therefore, my suggestion is that we set up this project in DP and ask for all users help and opinion since I think you can agree that there is nothing secret about general discussion about submission and feedback system design. DMOZ suppose to be a volunteer system, so let's us ask people to volunteer to help us, unless you believe that there is no such thing as unselfish volunteers. Will you be ready to implement such system in DMOZ, if it is shown that it will highly improves the directory?
The evidence - the listed sites are not contained in a database that is searchable, the data has to be dumped into a second database every so often and that is used for DMOZ search; editors would love to be able to search on an URL sitting amongst unreviewed sites - that function would be extremely useful in anti-spam efforts - but it is not available. Worthwhile reading orlady's actual words - a system to tell people when their sites have been accepted - which they can tell by looking or using existing DMOZ search.
What kind of database is not search-able? Isn't the primary reason for having a database is to be able to store, sort and search data? Is non-search able database something that was invented by AOL and only used in DMOZ? You have talked about system design, quality control, validation,... before; do you really belive in this mysterious database system that has no search possibilities. I have worked on PDP-11 with multitasking operating system that had only 256 KB RAM and we could do search. I know, what she said and that was the reason for my previous posting. I think it is very common in DMOZ culture to make suggestion for improvement to procedures and guidelines that are no improvement in reality.
Ahhh... thanks for pointing that out. Gworld is correct again - nothing new there - just more bafflegab and smokescreening from DMOZ. Really, orlady. What is the point in wasting your time and everyone else's by even posting this sort of garbage?
If you take a database with 700,000 separate tables then searching across all 700,000 tables is going to be more or less impossible. It is the only kind of structure I can think of that would not permit easy search facilities and would explain why the data has to be dumped into another database to provide DMOZ search. Maybe the reason for that is to do with editor permissions - I don't know how they are controlled. Why not ask for a specification of the database, inputs, outputs, and dependencies - that would probably tell you what you want to know and what might and might not be possible/achievable, otherwise it is all really supposition based on how things appear to work.
Somebody has designed a database with 700,000 tables? Who was this genius? Do you really believe that anybody in the world can be that stupid or are you mixing the definition for table and record? Who knows, maybe next time they will tell us that it also has 5,000,000 table with 1 table for each listings and the pigs fly too. I know the specification of the database and that is the reason, I think it is so ridiculous that editors keep repeating this nonsense that is fed to them without thinking about it.
700,000 categories. What is your theory for having to dump all the data into another database to serve DMOZ search? But wait, you know the specification - how many tables are there? And why are you asking me (and I don't have the specification) when you know?
Anyone with any real world experience of older databases would be aware that switching databases is not a trivial exercise. This is made even more difficult by the number of internally developed utilities that have been tailor made to work with the existing database structure. These utilities greatly help editors and are not at this point something that can be just thrown away. Since much programming is done by volunteers, this would require that all those utiities be rewritten. Comparing it to a PDP-11 running searches on DECTAPE is most amusing. To paraphrase, this is 2006, not 1973.
That was exactly my point, it seems DMOZ ability for database handling in 2006 is behind what was possible in 1970s. You can try to make as much excuse as you like to confuse people who do not understand these subjects (usual editors) but don't forget that this is a webmaster forum and you just make yourself look ridiculous with these excuses. 700,000 categories doesn't make it 700,000 tables, it only means 700,000 records in a 1 category table. in today's world 700,000 is not a big number of records. I just wanted to clarify that excuses by powers in DMOZ is just that and there is no need for anybody to repeat it, if they just stop and think for a second.
Stop talking out of your rear end about "excuses". Excuses only apply if someone is supposed to have done something but hasn't. No-one has yet established that there is a pressing need or desire to do what you want to do with the database. *If* you persuade the powers that be that what you want is necessary and desirable. *If* you manage to get a schedule for the work. *If* it is not delivered to schedule. *If* there is no good reason for a delay. Then you might be talking excuses. You said you had the database specification so presumably you know exactly how many tables are involved. What is it? What do you think the listings in each category are contained in? Tables maybe. One table per category maybe. But you have the spec you said so is that so or not? And accountability makes a good point about the utilities - who is going to convert them to work with an updated database design? You? So utilities, editor permissions, the editor dashboard, all designed to work with the current database design. And you think this is a simple 10 minute job? If you have designed and implemented major database systems then you know full well the complexities so why are you trying to convince others DMOZ should do things in a way you know would be totally irresponsible?
If it's the case that DMOZ has to copy all its data from one database into another just to allow the database to be searchable, I'd say you definitely have a problem with database design and structure, and I would take that as evidence that "there is a pressing need" to do something with the database before it explodes. On the other hand, getting anyone inside DMOZ to acknowledge a problem and to actually do something about it isn't likely - perhaps when the database does eventually collapse it will be more clear.
Databases are designed to offer an organized mechanism for storing, managing and retrieving information. They do so through the use of tables. .................... Just like Excel tables, database tables consist of columns and rows. Each column contains a different type of attribute and each row corresponds to a single record. For example, imagine that we were building a database table that contained names and telephone numbers. We’d probably set up columns named “FirstNameâ€, “LastName†and “TelephoneNumber.†Then we’d simply start adding rows underneath those columns that contained the data we’re planning to store. If we were building a table of contact information for our business that has 50 employees, we’d wind up with a table that contains 50 rows. .................... Here are just a few of the actions that you can perform on a database that would be difficult if not impossible to perform on a spreadsheet: Retrieve all records that match certain criteria Update records in bulk Cross-reference records in different tables Perform complex aggregate calculations Database Fundamentals But may be you are right and there is no excuse. AOL has just succeeded with design of a unique product, a non-search-able database. I think they should apply for patent for this concept before someone else decides to copy them. Who cares that database is not search-able and it is effectively hinder to operation, we can always say that we have editor designed tools to justify doing nothing. I mean it is not our fault that we sit around and do nothing, we have to work with this unique non-search-able database and these unclimbable mountains of problems.
Apparently the DMOZ database is not a relational database but a series of files. Which complicates matters somewhat further. But then you knew that because you had the specs didn't you! You can always volunteer to redesign it. But it won't be an easy job because of all the dependencies. You think the job is easy - prove it by doing the analysis properly and then proposing a project to redevelop it. I don't see mountains of problems at the current time let alone unclimbable ones - you seem to be in a small minority on that one. If the problems are with submitter feedback then most editors don't even rate that on the radar as being a problem. As I said in another thread, there is another hook you could use to persuade people this would be a priority but it won't get done without the resources and if you are the only one who thinks it important then it is down to you to lead it. It works for what DMOZ wants to do with it today - if it ain't broke... Gworld is the only editor I know of really convinced it is broke.
May be Hutch is right and it is not even in digital form and he is writing down each new listing on a piece of paper in his basement. I offered to orlady to start a project for re-designing it here in DP but it seems she lost interest as soon as it became obvious that it is possible to do and it can make a change for better. Since there are many here who are interested for DMOZ to work, so they will have chance to get listed, may be we can start collecting donations for new servers and hard-disks at the same time since that seems to be another popular excuse.
Oh please, you know a project like that could only be done internally. Why should orlady waste her time responding to such a silly question?