Magazines

[PeterJ]

@sho. It's having to have a magazine publisher per issue rather than by magazine that potentially causes the extra work.

Currently there is a 1:1 relationship between the magazine (not a specific issue) and the publisher:





Einar is the SQL guru, and I'm sure he can sort it out.

[sho]

Sure, then there is the question of a historic database, should it be correct or easy to work with?

[AndyC]

I'm sure you could keep the existing system as, in effect, the primary publisher. Then add a many-to-many table arrangement for full publisher history. And then eventually phase out the old one if necessary.

Or at least that's how I'd do it.

[PeterJ]

Sure, then there is the question of a historic database, should it be correct or easy to work with?

If you read my earlier comments you will see that I'm agreeing you @sho ! I'm just saying that changes to a database structure need careful consideration (which I'm convinced Einar would do) and not sudden knee jerk reactions.You can't suddenly potentially break websites for all the ZXDB users to please one or two people.


Nice constructive suggestions @AndyC. Follows my broad thoughts too. keep the old structure running too. Thank you.

[StooB]

I'm sure you could keep the existing system as, in effect, the primary publisher. Then add a many-to-many table arrangement for full publisher history. And then eventually phase out the old one if necessary.

Or at least that's how I'd do it.

Adding an extra table would be a workaround for the changing publishers, but it doesn't solve the underlying problem.

Because of the way WoS and the magazines refs were originally separate entities, magazines issues don't actually exist as items in the database in the same way as software, books and hardware.

That's why we have this odd situation where you can't add a reference to a page in a book or add an artist for a magazine cover, but you can do the opposite.

Magazines issues should be in the main database like everything else, but as Peter says it needs careful consideration in case it breaks everything.

[redballoon]

Yip, i'd follow @Andyc suggestion.

I can think of a couple of ways to do it, 1 better than the other and, note, I've not looked at the ZXDB DB.

• Assuming there may be a detail table hanging off of the magazines table listing each issue for each publication, then simply adding the LABEL_ID to this detail table allows you to then specify a publisher per issue. You can leave LABEL_ID on magazines for the primary publisher, or eventually just remove it completely, or

• If there's no magazine detail table and there's no scope for this to be created, you could still create a detail table where you can then have a start and end date against each publisher of a magazine. The downside to this is there's no direct tie of an issue to a publisher so you'd introduce some vagueness if trying to determine which issue was released by which publisher. Again, you could leave the LABEL_ID on the magazines table as the primary, or it could contain the LABEL_ID of the current publisher or you could decide to just delete the column all together.

Obvs either option means you have that link and leaving LABEL_ID on magazines means nothing will break, but if it is left on, you have to make it clear what it means.

[redballoon]

OK, I was having some further thoughts about this as a continuation from above.
Since I don't have all the data, I'm guessing that a magazine having multiple publishers is the exception rather than the rule.

If that's the case, then in my first option, having LABEL_ID on the magazine issues table is fine but for the rule, it'll be pretty much the same for every issue. Even if there are multiple publishers, it's not going to have too many different values. Also, if you were wanting to know how many publishers of a specified magazine, you'd have to use the magazine issues table within the table and include a distinct in your query.

With my 2nd option,

if you were wanting to know how many publishers of a specified magazine, you'd have to use the magazine issues table within the table and include a distinct in your query.

this is no longer an issue, as we have the table with 1 record per publisher per magazine. I say "1 record per publisher per magazine" but there's nothing stopping a publisher going on to publish the magazine at different times, so a publisher could appear multiple times in this new detail table with different start and end dates, therefore, you would still have to use a distinct in your query if you wanted to find all publishers of a magazine...though I'd wager there'd be better performance on this detail table rather than on the magazine issues table.
In addition, unless we find proof of exact start and end dates, where applicable, we'd be guessing at these dates.
Going back to

magazine having multiple publishers is the exception rather than the rule.

then this "detail" table of magazine publishers would, for the majority of magazines, have 1 record, so it'd be mainly a 1 to 1 mapping...but I suppose, it can handle multiple publishers without any further changes.

There's a 3rd option form this - a hybrid of option 1 and 2.
You've still got the new magazine publisher table:

Code: Select all

MAGAZINE_PUBLISHER_ID (unique)
MAGAZINE_ID (this is the Magazine unique ID)
LABEL_ID (this is the Publisher unique ID)
START_DATE (the date the publisher started publishing)
END_DATE (the date the publisher stopped. This may only need a value if there were further publishers)

and on the magazine issue table, you could add MAGAZINE_PUBLISHER_ID, rather than LABEL_ID in my first option. You'd still be able to tie an issue to a specific publisher of the magazine.
So, it really all depends on the analysis of the actual data before a decision could be properly made.

[AndyC]

Personally I'd avoid anything with start/end dates. It's compact but they're messy in that you start having to introduce the concept of open/closed searches to avoid accidental "gaps" in data. Not to mention that the publication dates of various issues are a bit vague anyway.

I don't know if "how many publishers produced magazine X" is that common a query in reality, but it's the kind of thing an index could answer relatively quickly. Issue numbers might be better but I've a suspicion they may have occasional quirks and some magazines may never have used them anyway. Linking an issue to a publisher directly is probably better if you want to represent this sort of data accurately.

[redballoon]

Yip, that’d be my preferred option, too. Easiest, less hassle, doesn’t affect the current model and if you do need those reports, hardly the most difficult either.

[Einar Saukas]

The problem here is that currently magazines don't have individual publishers for each issue - even the new Crash from Fusion Books is listed as still being published by Newsfield.

Good point!

As a general rule, we try to keep all ZXDB structural changes to a minimum, because we are aware that each change impacts several sites and applications. But in this particular case, it's a small change that will help improve ZXDB accuracy, and it will be extremely easy for anyone using this information from ZXDB to make the required changes. Therefore I have already incorporated this suggestion in today's ZXDB release. Thanks for pointing this out!

Also we are making gradual changes as usual, so everyone will have plenty of time to adapt. It means we always add first any new tables and/or columns, while keeping the old ones for some time, so these changes won't suddenly break anything.

To fix this:
Sinclair User is published by ECC up to issue 29, and EMAP from issue 30 onwards
Your Sinclair before issue 17 is Sportscene Specialist Press, 17 to 51 are Dennis and from 52 onwards are Future Publishing
Crash is Newsfield, apart from 94 to 98, which are Europress, and all Crash specials from 2018 onwards are Fusion Retro Books

I will update these details in the next ZXDB update. Thanks!

[Einar Saukas]

perhaps a more correct method of displaying publishers for covermounts and type-ins is the publisher of the magazine.

Actually ZXDB does NOT store "indirect" original publisher information. For instance, if a certain program is a type-in, then ZXDB only stores the magazine reference where it appeared first, but not the "publisher" of this type-in. If it's a program that first appeared in a covertape or e-magazine or compilation, then it only stores what's the covertape, e-magazine, or compilation. And so on.

The point is, ZXDB contains enough information so any site using ZXDB can extract and show the "indirect" original publisher in cases like these, in whatever way they want (without changing anything in ZXDB).

Here's an example how SpectrumComputing displays a certain entry:

Original Publisher: Magazine Sinclair User - within covertape "Sinclair User issue 118: Great Eight 7"

Other sites could choose to display it differently, for instance:

Original Publisher: Sinclair User covertape

Original Publisher: Sinclair User #118 - 1991/Dec covertape

Original Publisher: ECC Publications Ltd / EMAP Business & Computer Publications Ltd - within covertape "Sinclair User issue 118: Great Eight 7" from Sinclair User #118 - 1991/Dec

Original Publisher: ECC Publications Ltd / EMAP Business & Computer Publications Ltd - within covertape "Sinclair User issue 118: Great Eight 7" from Sinclair User #118 - 1991/Dec referenced as CoverGame on page 8

I think SpectrumComputing uses a good tradeoff. It shows the most relevant part of the available information without making it too long. Someone could argue that displaying the actual magazine publisher would be more "logical" than indicating the exact magazine issue, but which information most people will be more interested when looking at a cover game?

[sho]

I think SpectrumComputing uses a good tradeoff. It shows the most relevant part of the available information without making it too long. Someone could argue that displaying the actual magazine publisher would be more "logical" than indicating the exact magazine issue, but which information most people will be more interested when looking at a cover game?

Keep in mind Spectrum computing also has "Magazine Issue Link" (for covertapes) and "Magazine References"(for type-ins) that kinda include redundant info as pointed out by @StooB ("Original Publisher" and "Magazine Issue Link" contain almost the same info)



One suggestion is to have "ECC Publications Ltd / EMAP Business & Computer Publications Ltd" (or the one that was the actual owner of the magazine at that time) as publisher, and then either have "Magazine Issue Link" or "Magazine References" (preferably not both) for both types, that includes the particulars of the magazine / issue.

[sho]

Type in presentation for comparison:





And on second thought, perhaps both "Magazine Reference" and "Magazine Issue Link" should be used for both type-ins and covermounts?

In any case the presentation of both covermounts and type-ins should be consolidated.

[Einar Saukas]

One suggestion is to have "ECC Publications Ltd / EMAP Business & Computer Publications Ltd" (or the one that was the actual owner of the magazine at that time) as publisher, and then either have "Magazine Issue Link" or "Magazine References" (preferably not both) for both types, that includes the particulars of the magazine / issue.

The problem is... if you search for "Cricket" in SpectrumComputing you will get these results:

Title: Cricket
Original Publisher: Magazine Sinclair Programs - type-in from issue #9 - 1983/Jul

Title: Cricket
Original Publisher: Magazine Sinclair User - type-in from issue #9 - 1982/Dec

Title: Cricket
Original Publisher: Magazine Sinclair User - type-in from issue #19 - 1983/Oct

Title: Cricket
Original Publisher: Magazine Sinclair User - type-in from issue #32 - 1984/Nov

However if we implement your suggestion, we will get these results instead:

Title: Cricket
Original Publisher: ECC Publications Ltd

Title: Cricket
Original Publisher: ECC Publications Ltd

Title: Cricket
Original Publisher: ECC Publications Ltd

Title: Cricket
Original Publisher: ECC Publications Ltd

As I mentioned before, the latter is arguably more "logical" but not very useful!

The current choice on how to display original publisher at SpectrumComputing is a tradeoff to show as much useful information as possible while still keeping it fairly short.

[sho]

The current choice on how to display original publisher at SpectrumComputing is a tradeoff to show as much useful information as possible while still keeping it fairly short.

So, some suggestions:

Cricket:



Original Publisher:
ECC Publications Ltd - type in from Sinclair User, issue #9

Instead of:
Original Publisher:
Magazine Sinclair User - type-in from issue #9 - 1982/Dec

The yyyy/mmm is redundant since it is right above, both in search results and "details" pages.

For covermounts, such as Cricket Coach:

Original Publisher:
Newsfield Publications Ltd - within Crash covertape, Crash issue 90 Presents 26

Crash issue 90 Presents 26:

Original Publisher:
Newsfield Publications Ltd - covertape from Crash, issue v.1 #90

OR

Have magazine publisher as "Original Publisher" and add "Magazine Issue Link" to search results, in which case they would need to be added to type-ins also.

If the former, "Magazine Issue Link" could probably be removed altogether, and "Magazine Reference" added to covermounts.

Companies could even have shortnames; "Newsfield Publications Ltd" = Newsfield, "EMAP Business & Computer Publications Ltd" = EMAP etc

Btw, early C&VG was published by "EMAP National Publications Ltd", not "EMAP Business & Computer Publications Ltd", Sinclair User by "EMAP Publications Ltd".

(When there is a will, there is a way )

[Einar Saukas]

Original Publisher:
ECC Publications Ltd - type in from Sinclair User, issue #9

Instead of:
Original Publisher:
Magazine Sinclair User - type-in from issue #9 - 1982/Dec

The yyyy/mmm is redundant since it is right above, both in search results and "details" pages.

We have to be careful here: a solution that works for a specific example may not work for all cases...

In particular, the yyyy/mmm is not always redundant. Some magazines are not even numbered. In others, the number is not sufficient to distinguish different issues. A famous example is C&VG #93 - 1989/Jul and C&VG #93 - 1989/Aug. Therefore we will need the full magazine issue identification in a general case, like this:

Original Publisher:
ECC Publications Ltd - type-in from Sinclair User, issue #9 - 1982/Dec

Another problem is, everybody knows that Sinclair User is a magazine. But what about a type-in from Spectrek, El Ordenador Personal, Over the Spectrum, Espectro, etc? Which ones of them are books, which ones are magazines? Many users will probably be interested in this distinction. Therefore we better add this information too:

Original Publisher:
ECC Publications Ltd - type-in from magazine Sinclair User, issue #9 - 1982/Dec

Now let's keep in mind that we are looking at a specific case that's somewhat compact. Typical cases may look much longer:

Original Publisher:
EMAP Business & Computer Publications Ltd - type-in from magazine Computer & Video Games, issue #45 - 1985/Jul supplement "Book of Games"

That's way too big! So let's reduce it. What's the least relevant part of this text, that people will be least interested to know, when someone is looking for a type-in? I think it's the part that says what was exactly the company responsible for the magazine, when the magazine published this type-in. Now if we remove this part, we will get this:

Original Publisher:
Type-in from magazine Computer & Video Games, issue #45 - 1985/Jul supplement "Book of Games"

Although the text now seems to indicate an "original publication" instead of "original publisher". To fix this problem, let's move the magazine part to the front:

Original Publisher:
Magazine Computer & Video Games - type-in from issue #45 - 1985/Jul supplement "Book of Games"

And that's how SpectrumComputing arrived to the solution it's using nowadays...

[sho]

How to handle something that is both a covermount and a type-in?

See Compilation / Cover flexidisc, containing Blobhop/Blodhop aka type-in Froghop

[Neil Parsons]

Hi,

I've noticed that all issues of Home Computing Weekly magazine, scanned as PDF at Internet Archive, have a very poor resolution. So, I'm using existing JPEG files from same site (Generic Raw Book ZIP) to convert every issue in this type of image into new PDFs with a better quality. I usually use this online converting tool to do it: https://www.convert-jpg-to-pdf.net/

Maybe next week I can upload new PDFs to IA. I'll tell you once finished.

[Neil Parsons]

In the meantime, I'm submitting to ZXDB many HCW type-in programs files already existing (not here at SC, I'm afraid), thanks to the effort of Jim Grimwood and his collaborators in the past, if any. Many of these listings were copied long time ago for The Type Fantastic site of Jim's. No clue why they weren't uploaded to Spectrum Computing in these years... but, it's fine I can do it actually.

Of course, I'm also updating many of these entries related with Home Computing Weekly mag. Authors, availability, machine type and other features remained in blank or wrongly, using Jim's web and the magazine itself.

Today I've entered a first bunch of HCW type-ins (MIA at SC, until now) alphabetically, from A to C of Carnival. I'll continue this in the next days.

[Einar Saukas]

Thank you!!!

[Neil Parsons]

It's almost done! All PDFs are now available, while rest of formats will be automatically making themselves into the same page during next hours. Once finished all these uploads, I only have to edit main text and that will be everything. Enjoy!

Of course, I joined HCW eight supplements to the lot. They appear at the end of the list.

Home Computing Weekly magazine (Better quality PDFs)

[Einar Saukas]

Thank you!!!