Here's more codes from the Model Railroad Magazine Index, with our current guess on the magazine.  Suggestions for the magazines we don't recognize greatly appreciated!  Thanks in advance.

A
AE
COHS = C&O Historical Society
CPR
CR
CRM = Canadian Railway Modeller (?)
CT = Classic Toy Trains
D        (~1940)
DE = Diesel Era
E        (~1951)
E22S
ERA
F        (~1939-41)
F09
FL
FRP
FSM = Fine Scale Modeler
GAZ = Narrow Gauge Gazette
GMR = Great Model Railroads
GR = Garden Railways
HO = HO Model Trains (~1953-61)
ICHS
KEYS = Keystone (PRR Tech Soc) ? Keys Lock & Lantern ?
L        (~1933-35)
LD
LEJ
LNHS = L&N Historical Society
LQ = Locomotive Quarterly
LRP
LS = Live Steam
M        (~1960)
M10
MB        (~1947)
ME
MECH
MG = Model Railroading
ML
MM = Mainline Modeler
MODR
MP
MR = Model Railroader
MRP = Model Railroad Planning
MT = Model Trains ? Model Transport ?
MX
NHHS
NMRA = NMRA Bulletin
NMRC =             (1982-93? Annual?)
NN
NRHS
NS = N Scale
NWPM
NYCH
OGM = O Gauge Modeler
OGN
ON
OR = Outdoor Railroader
OSN = O Scale News
OSR
OST = O Scale Trains
PM = Prototype Modeler
PS
PTJ
RA
RC = Rail Classics
RE
RF = Rail Fan
RG
RJ
RLC
RLHS
RLN
RM = Railroad Modeler ? Railway Modeller ?
RMC = Railroad Model Craftsman
RMJ = Rail Model Journal
RMR
RN
RNE
RPN
RQ
RR = Railfan and Railroad ?
RY
RYA = Railway Age
SG = S Gaugian
SGN = Slim Gauge News
SH = S Gauge Herald
SM
SN3 = Sn3 Modeler
SP
SS
T = Toy Trains ?       (~1942-50)
TH
TI
TM = Traction & Models
TOY = Toy Trains ?
TT = Toy Trains ? TT Scale Magazine? Trolley Talk?
TTOS = TTOS Bulletin
UP
VR
WR
WT

You can get to enough of the index to see some of the magazines on the Internet Archive Wayback Machine.

http://web.archive.org/web/20080727141209/http://index.mrmag.com/

You can glean the magazine codes out of the links.

That said, it seems like there are more magazines listed here than I recall seeing in the database.  For instance, E22S is probably Extra 2200 South.  I don't recall it being indexed in the database.  Were all of these actually used?  Also, VR seems like it was probably Vintage Rails.  I don't recall that one indexed also.

Good luck!

Paul

Try looking on this page:

http://web.archive.org/web/20060511024005/index.mrmag.com/tm.exe?tmpl=tm...

Paul

Martin

MR Jun 2005 has a review of a Kato SD38-2.
MR Jul 2005 Has the performance chart for the loco. Must have been first in Jun.

How would this fit the series model?

Rod

Title says it.

Rod,

MR Jun 2005 has a review of a Kato SD38-2.
MR Jul 2005 Has the performance chart for the loco. Must have been first in Jun.

How would this fit the series model?

So did they forget the performance chart in the original article?

I'm not sure whether this could actually be called a series.  But anyway:

Title of series: Review of Kato SD 38-2 (whatever title they gave the June article). It doesn't actually matter.

Title of article in Jun 2005: Review of Kato SD 38-2

Title of article in Jul 2005: Performance chart for ... (or whatever they called it)

Both articles would be a part of the same series. So if you find one of the articles, it is indicated in the result that this is a part of a series and you are given a link to quickly find all other parts. As in this case this could also be used to index corrections to an article.

Regards

Martin

Benny,

Another potentially useful column might be the "Article Order" Column, which would give the position of the article in the magazine or re-issue of the article.  Multiple entries for the order would be allowed, with the autofill set to "1"; Careful editing would ensure the order is eventually rectified.  This would tell users and administrators which magazines are potentially done, or if there are articles missing - and not just because the missing pages are filled with adds or photospreads.

that's an interesting idea. I haven't given that a thought. IMHO the usual workflow is that somebody sits down with a magazine and enters all articles in one session. But that must not be true for everybody. But if you don't know how many articles a publication has, there is no way to know whether it's complete or not.

Another interesting note: sometimes RMC would run a Prototype article about a specific subject; right after the prototype article would appear a modeling article reproducing that exact prototype.  Sometimes it was the same author, sometimes not.  And I bet there's also the case of specific prototypes and modeling articles separated by multiple issues.  The "series" column might be able to be commandeered to provide additional options that cover these other situations.

That's what the category / subcategory field are for. One would be a combination of Prototype / Depot , the other would be Construction / Depot. So if you search for Preston you'll find two references in two categories.

Regards

Martin

That is true in regards to category and subcategory fields - perhaps that is best. If there is enough categorty differentiation, ti would be fine.  I put it out there for thought.

Now I hate to throw wrenches this late in the design process game, but I went back through and rethought this whole beast out.  My revelations might be useful.

I reduced everything down to the simplest entity diagram possible.  My results are as thus:  Imagine four ovals on a blue field.  The left oval is the "People" oval; the upper oval, the "Publisher" oval, the right oval is the Publication oval, and the lower oval is the "Parts" oval.  And the arrows in this diagram tell this story: Author or Authors construct parts; Author or Authors, related or unrelated, then take these parts and make articles for publications.  These publications are submitted to People who are part of Publishing companies, who then publish said publications under that company name. 

I said "bluefield" because all of this data is independent of database user data, the "community.  So now imagine an equal sign on the border of the bluefield called "Access." Outside the bluefield is a new oval called "User Profiles," which makes up "the community."

Now this may seem vastly oversimplified, but I think you'll see how powerful this setup is when you see the 'ghost" main data table that appears in the very center of the four ovals, a table almost entirely made up of primary keys supplied by the four ovals.  I'll give a couple examples;

Let us say I have two articles, containing multiple parts, including diagrams, a trackplan, ten pictures, and a scale plane that was published as a practical standalone article right after these two articles.  When I enter the components into the computer, that author/photographer/draftsman/editor/et al would go into the resepective fields.  The presentation side of the database then integrates the outputs based upon the values of the "ghost table" in the middle that relates keys to each other.

Another example, in the "position" table: I have one Person [column 1.0, Who, Pkey from Personal table] who has a value in the "position" field that means he was the editor [What, sub column 1.2] of the magazine [Sub column 1.3, of what Pkey from Publication table] from 2000 to 2007[sub column 1.4, when]. The publisher Pkey is unnecessary because the publication entry references that Pkey within itself.  I then add a new entry into this table for the same person except this time, he wrote an article for the magazine in 2007.  I subsequently have all the other pieces too - so I simply patch together the Pkeys by either entering the new data, and thus allowing the engine to enter these values into the respective tables and then generate the new original Pkeys, or I thread exisitng values together.  of course, you and I never see it as Pkeys - we just see SQL outputs in a web environment.

In the "publication" table I thread together the primary keys from the person table [who contributed to it], the publisher primary key, and add in the new information in this tables area: when it was published, the name of that publication, and all that pesky stuff librarians love like ISBN numbers, LOC.DDC Call numbers, and publication qulaities [thickness, height, weight.  Yes, really silly stuff, until you are the guy looking ot moove 1000 model railroad books.  Imagine this database spitting out an accurate readout of your collection [by using the userprofile account "build my collection" section], complete with shipping weights!!!] End result - all the information is present to accurate and throughly describe the item, so the webdeveloper can create additional functions for the database without havign to reinvent the whole database.

Let us suppose that in a year, everything is humming along - and we decide 'you know, ti would be really nice if all the scale plans were in this database.  You or I, the database developer would go into the "items" sub area, creat these new "plan" tables, and thus, we could add both articles and plans to the database.  And further down the road, we want to add in trackplans - because they are drawn by others.  Poof, we create a "trackplan" tableset, and all the redundant stuf [publisher, publicaiton] is already done.  What if the NMRA want to use this database to catalog their huge collection of photographs?  Or we desire the ability to look up photos - like, who took that covershot of the April 2007 Magazine - and who's layout was it, what scale was it, what region, what road...?  Poof, we add the "Photo" Tables, which allows us to add each photo with adequate descriptions through the "Photos" set of database tables. 

In short, this give us wings now to develop a small kernal, the hub, and attach to it four subclouds [enough to do just articles with people, publicaiton, and publisher] and in time, when we get the time, the database has the ability to handle many more pieces of information without becoming cumbersome.  Furthermore, we don't end up with one table that tries to handle articles, photos, trackplans, scale plans and such all at once.

Now here's a userbility scenario just to envision the user paths throughthe web interface.  I click the "Browse" tab and it pulls up the "browse jump page, offering me a couple areas I can browse by - magazine, author, scale, you name it.  I click on the "Author" and it displays the list of authors who have created pblications, sorted by last name.  I click on one author, it displays his 'resume,' everything in essence "created" by that person currently in the database.  If I click on "magazine name" in one of these results, I would be directed to a "Wiki" info page about that publication - including a table of linked "years" that would then open a "year" page upon which in the upper part the Publishing staff of that year would be displayed.  The only years displayed in this table would be those that have information in the database.  Under this section would appear the magazine contents for that year, in a "table of contents" format.  This would all be functions a "browser" of the index would see - useful for the person who has a vague idea, but not enough to recall keywords.  And contributors would be able to see what is completed thus far by "the community."

A useful note:  When I open the "year" page, I would see that the 2000 is plain underlined if one piece has been entered in the database, underlined and in red if half of the issues are done [metrics measured by year] and underlined in boldface green if all of the data for all issues has been entered.  An Admin would be in charge of verifying that all of the data for an issue has been entered, and with setting the "flag" to Done in a higher level table.

A searcher of the index would open the text form page, construct a search, and then recieve a page of linked results - because it would be in the same format as before.  If he starts clicking on the datalinks, and each unique result is a datalink, it would be like he was browsing.

and before this iron grows cold, I'm going to bring back up that idea about the book metrics subtables.  This could verywell be how this whole database gets "sold" to the submitters.  Since we all want to catalog our book collections, we go to this database to create that personal database.  In some cases, we can add piece in the database to our personal library, but in other cases, we have a piece that is not yet entered into the database - or an issue, or a magazine, or a trackplan, or a rare obscure 1:400 plan of the depot as it appears in 1909, published by ATSF and drawn up by what turns out to be an infamous draftsman becasue he drew up all the plans in the southwest in a five year period.  On one hand, I the user can add my "piece" to the database - and then that piece is available to not jsut me, but everybody else to digitally add to their personal collection.  I enter "MR 2007 SEPT," and then add it to my personal library  I have two copies, so I enter it again - system prompts me that I have it, but it allows me to enter the itme again as the condition and the autographs on this piece may be different form the first piece.  Jim and Bob and John are working on the project too - Jim tries to type the whole thing into the "Add a reference" part of the sit, and he's prompted that it's already been entered.  Bob and John simply smile and use the "add the issue" button to import a digital copy of the item into their personal libraries.

Finally, and this is the most powerful part of this whole "user library" idea, and idea that would really put a lot of steam into the viability of this project, is when users decide to sell their books - I simply click the "Sell" button that appears next to each entry in my library, and a popup window pops up and requests a value, and upon clicking "submit" a record appears in the 'marketplace" section, advertising that my book is available for sale.  r my magazines for 2007.  Or my duplicate coppies of the magazine.  Or my whole model railroad publicaiton collection,because I just died and left behind a tremendously potent library of terrific stuff!  Oh, how to get it inot the hands of the people who would treasure it all most?  :P

Obvioulsy, most of my ideas are a long ways out into the future - but I think the forward perspective is as valuable as hindsight.  Looking backwards from a far forward position is 20/20, right? :P  And yes, you just saw it, I figured out a way users could use this database to make money!! ;)

Well, I'm going to put this to rest - I look forward to what comes up.  I'm in the AF, and I have CDCs for the next couple of months, but I am ripe for conceptual assistance and user testing!  I am not the best programmer, but I and very good at "seeing" these things work!

Think RNE is Rails Northeast (fan publication-Conrail Era), RQ - Railway Quarterly, OSR - O Scale Railroading, WR - Western Railroader (early '50s), CT - maybe Classic Trains Magazine?...still taxing the brain cells !  Bob C.

I didn't realize archive.org could get to this stuff.

dave