Hi,

a few minutes ago I uploaded an updated data model that reflect suggestions from this forum.

See home.vrweb.de/~martin_fischer/overview.html

URL: added

Author: added and extended. It might be nice to show the contributions an author made. So you could search for all articles with photos by John Olson.

Vote: added a tracking mechanism to prevent abuse

Category / Subcategory: this is inspired from the earlier printed indexes Model Railroader did. It helps you to get an idea about the type of article (Construction, Review, Prototype, ...) and the topic (House, Industry, Tree,...) It allows for browsing for a certain topic. Otherwise personally I don't see at being used for a specific article. That being said, a second set could be added. But would it be really helpful?

Keyword: I see the keyword system as a taxonomy ( en.wikipedia.org/wiki/Taxonomy ) that needs to be predefined by humans. All articles should be tagged with keywords from that list. The original index had a great keyword list for that purpose.

Taking the words from the title like you suggested sounds like full text index to me. Full text search is needed for the index but I'd leave that up to the database or a search engine.

Let me give you two real world examples. RMC July 2010 has two interesting articles:

'It's a beautiful day in the neighborhood' by Gerry Leone shows how to kitbash a row of company houses and add nicely detailed backyards. This is information that can't be taken from the title. I'd enter the article with keywords like: kitbash, house, company house(?), detail, scenery

In that case the keywords are needed to help find the article. More keywords might be added, depending on the list.

'The PRR F33 deep well flat car' by Kris Kollar describes kitbashing and superdetailling a flatcar including its load. The title describes this very well. Doing a full textsearch for "PRR" and "flat car" would help you find that article very fast. This is where your suggestion works very well. But then this article has interesting information about building a load, something that is not visible from the title.

Therefore I'd add keywords like: kitbash, detail, flatcar, PRR, scratchbuild, carload

A combination of both methods, full text search and keywords would IMHO be the best way to allow users to find every article. Features like fuzzy search or synonym search can make this more comfortable.

BTW it might be an interesting idea to let assignment of keywords be a community effort. Users could add the keywords from the list that they find appropriate. Maybe the count a keyword has been selected could even be used to measure how specific the keyword is.

Regards

Martin

I think having the email and phone number of the user who provided the listing is a good idea as long as that is not publicly available but only for use by the administrators of the index.

Making that kind of information public on the web is a bad idea given the way the scumbags on the internet harvest that data for spamming purposes.

But if we had that info in the database, that makes it possible to have a contact page that "staff" can use to contact the person. The contact page would be behind a login and only accessible by those who are authorized to contact the user who provided the listing.

As soon as you put info behind a login, spambots can no longer access it. And even then, the contact page I'm thinking of would not reveal the email but simply allow you to compose a message to be sent by the system to that email. That makes it quite secure and unavailable for "harvesting" even by authorized staff.

I don't want to toss any cold water on this project - certainly not - but it seems what is being created could be handled by some sort of Wiki software.

Martin;

For the two items you quoted from RMC Jul 2010, I do not have that issue at hand. Were there subtitles, that text between the title and the article, on those?

Rod

Dave;

I learned a long time ago that anything that does things FOR you will invariably, without fail, now and always, amen, end up doing things TO you. I am talking about software here, but it really applies to everything in life. A sharp knife is great for cutting your meat, but who here has not been cut by the knife?

The system we propose here is the same. If it was to be perfect, it would always return exaclty what we looked for, no less and no more. So we work to include features and functions that minmize the degree of failure.

So, what will "fuzzy" search do FOR us, and what will it do TO us? I think its basic reason for existence is to show us items with keywords/text words which are either synonyms or close sounding to what we asked for. Are these items one we really wanted, or are they just clutter? Would it be better with or without fuzzy search?

If that was all we had, it might be very good, but from my point of view, I have a well developed, working system were the "fuzz" is under my control. It's not perfect, but nothing else is, either. I would stack mine up against anything I have seen so far.

Rod.

Martin;

I use MySQL. I have not looked, but there are many packages available to sit on top of MySQL, and most probably fuzzy search, etc., are there.

Rod.

For the two items you quoted from RMC Jul 2010, I do not have that issue at hand. Were there subtitles, that text between the title and the article, on those?

Rod,

sorry I missed that. Judge yourself whether these would be helpful:

Article 1: "Solving a housing problem also brightens up the layout" - at least we have a variation of the keyword 'House'

Article 2: "A heavy duty survivor" - heavy duty might be helpful in a full text search.

Regards

Martin

Martin, that is a really nice Diagram.  You might convert it to a more conventional ERD style diagram by taking hte Ovals and making them items in a box, where the title of the box is the piece [article, issue, publication] and conventionally, also the title of the table within the database.  The entities within this box become the table headings.  Then you have a quick reference for the whole database, in a quick easy to see format.

It's very slick.  Complicated like the inside of a 747, but honestly, it handles like a cadillac in the air!

Thanks!!

You might convert it to a more conventional ERD style diagram by taking hte Ovals and making them items in a box, where the title of the box is the piece [article, issue, publication] and conventionally, also the title of the table within the database.

Benny.

is that what you mean: home.vrweb.de/~martin_fischer/umllike.html ?

This is absolutely less confusing. Also it seems to loose some information, like the relation. I did add that in some cases as textual description to make it more clear.

I'll be on vacation for a few days and won't be able to reply. I'm really looking forward to see the result of the discussions.

Regards

Martin

HOn3 Narrowgauger I like the idea you linked to, it just seems so much simpler at least from my perspective.

Dan