A short story is not an edition of a book or magazine

There seem to be a lot of cases where a short story in a book or magazine is entered as a book, and the book or magazine is entered as an edition of the story. For example, Henry S. Whitehead’s story “Jumbee” was entered as a book, and two different collections with different contents were entered as editions of the story. Can we agree this is wrong?

This also happens with the pulp Planet Stories a lot.

Book: ctlgs

Edition: ctlgs

A book can contain a story, but a story cannot contain a book.

I wonder if this stems from the original bookogs data, where you entered all the individual stories in a magazine or collection?

I agree with you
Stories (with their title and author or authors) conform a Book.
A Book has several Editions.
And apart
Stories conform Magazine Issues too.
So:
Several Stories → 1 Book → Several Editions
Several Stories → 1 Magazine Issue

But the problem here is, if i have an Edition in other language, how can i add the translated titles of the Stories or translated title of book.. or edition… We should need to fix logic

Also, I think we need a button to alert difficult to solve cataloguing errors.

(Sorry for my bad english, i hope i was understood)
Hugs

I’ve been thinking about it, and the issue is that a Book is an abstraction of something that doesn’t really exist. What actually exists—what you can physically hold in your hands—are editions. I think everything would be much simpler if we only abstracted physical objects; that is, if only the following existed:

Several stories → 1 Book Edition
Several stories → 1 Magazine Issue

or easear:
Several stories → 1 Book Edition or 1 Magazine Issue
(because the fields would be similar)

In fact, if you look at the list of recent contributions with books and editions, the Books don’t have images because they don’t physically exist.

The only thing that would still need to be clarified is that a story has fixed author(s). But they do have translated titles. And in each Book Edition, if we include a Language field, then it should display the story title in the language of that edition.

By the way, I have copies that, in addition to containing stories, also include forewords by authors—what would that be? It wouldn’t be an edition of the same book, but of another book…

I am completely convinced that the Book concept should stop existing. Please give it some thought.

Anyway, that’s my way of seeing it… I understand this would be a major shift, and it would require a lot of work to reorganize everything.

I think that the idea should be to add a Work. The Work can be a written text of any length.

A Book then contains one or more Works.

Book A

Editions:

…English Edition

…French Edition

…Reprint Edition

Contents

Work A; Work B; Work C

For example, there are at least three Editions of The Novels of Dashiell Hammett I know of (Ignoring reprints): Knopf, Avenel, Library of America). Each edition contains the same five Works: The Maltese Falcon, etc.

I have no problem with short stories existing as Works, and then they can be added to Books as one of multiple Works (or possibly a single work, in the case of chapbooks).

An Edition is a physical object. A Book is an abstract text that corresponds to the text of an edition. A Work is an abstract text included in a Book, which may contain multiple Works.

Ideally, if you click on a story title in a Book or an Edition, you go to a list of Books including that story.

Does this make sense?

I think we’ve circled back to a discussion we had in the “ogs” era - and I seem to remember we did have works

I listed a number of these Agatha Christie volumes that contain 3 stories apiece.

Evil Under the Sun / Death Comes as the End / The Sittaford Mystery - Books - ctlgs

I recall that works were used so that individual stories could be tracked across books and publications.

As the model currently stands it’s great for tracking physical books. But having a concept of a work is much more interesting in terms of making connections between source material.

For the Science Fiction genre, I think it’s particularly important as many stories first appeared in pulps (weeklies and monthlies) long before they were published in book form.

That’s what was originally driving me up a wall. I found out my 1944 Arham House collection Jumbee and Other Uncanny Tales was an edition of the 1926 Weird Tales story Jumbee. I edited the book to fit the collection, but then began to think that was a mistake. Since then, I just keep the story as a Book, but change the Book entry on the edition.

Not just science fiction; lots of Western stories, mystery stories, and adventure stories initially appeared in pulps. Black Mask and Adventure were just as important as Astounding.

1 Like

Ey! Howdy?

Sure!! a introduction, a story, a tale, a foreword..poem.. memoir… WORK is the word!!!

Yes, I have found similar books, not only with Agatha, Queen of Crime, other than the title is not the title of the book but a concatenation of stories titles

I’ve noticed Burnett has been replying to many threads but in this one hasn’t ventured to say anything — maybe we scared them off.

Never mind. I goofed.

Given we’ll eventually have some sort of marketplace, it makes sense to start modelling based on things that can be bought and sold, i.e. Editions of books.

There was some discussion about how “tight” a definition of “Book” needed to be. Viewed thought the sales lens, I like that I can discover lots of items based on a fairly flexible definition.

Works are interesting from a research perspective, but might not be necessary in a marketplace if search facilities are good enough. For instance new vector based search can find things based on queries like “Find books by Agatha Christies containing the story Evil Under the Sun”. (It’s been hinted that we should expect some changes in search).

Personally, I still like modelling relationships between things in a more structured way… but it can lead to excessive complexity and increased costs for running the site.

I would say, let’s wait and see…

Perhaps each Edition could contain one or more Sections or Editions. An Edition and a Section would have more or less the same properties, and might even be able to be the same database object, differing only by a type field. An Edition with multiple Editions would be a set packaged as a single physical item, and an Edition with multiple Sections would be a volume split into, well, sections.

With this basic structure you can encompass boxed sets and collected works, and collected works of collected works.

Because my contrubutions aren’t yet tied to my account I just spent an age trying to find this (I couldn’t remember the title, the physical book is packed away, it’s by Harlan Ellison who has a ton of stuff, and this didn’t come up alongside his credit until I edited it just now!):

That’s a collected edition of two volumes that are themselves collections of assorted works, with page numbering restarting half way through.

Hello

what?

So we should need “Set” entity or typed field..

It reminds me DragonLance box sets of “books” (Edition Books):

more structured way..
it’s true that a more fixed and less optional structure prevents people from having doubts about how to enter new data.
You also point out that this site has a commercial purpose; I understand and respect that, but we can’t stop there. That stance in life of “if it works, keep going” is quite disheartening.

Burnett is taking his time to reply — or he’s ignoring us. Haha. So “let’s wait and see..”

An Edition is the entity type for a standalone physical publication. This could be a physical book, a magazine, a boxed set, etc. A physical book can be a collection of short stories, an omnibus (as in my example), or something else I might not have though of.

If an Edition can contain nested Editions, then you can have, say, one or more Edition of a boxed-set which contains Editions that are physical books that may have also been published separately in that same physical edition. I have a few examples of this set up (not yet submitted - there’s no point doing that until I can see what’s what listed on the Book page); a boxed set released in two editions with revised art, and ISBNs etc, and varying printings (sometimes the same printings) of the same titles inside each.

This structure can also handle sections that are things like Introductions, chapters, etc, that have individual separate credits from others, or from the main container Edition. It will also allow handling page numbering per section, if page numbering can be entered as a range.

ie,

Section 1 - Introduction, pages i - ix

Section 2 - Work 1, pages 1 - 420

Section 3 - Work 2, pages 421 to 807

Section 4 - Work 3, pages 1 -226

etc

I think it’s more a case of lots to do, and possibly @Burnett doing it all.

It’s still very early days - and the response to squashing bugs has been great. Getting the model right will need a lot more thought.

1 Like

Hi, no, I’m not ignoring this topic! I just don’t feel I’m an expert on this area and I’m glad more people are giving their opinion. I’ll digest it all soon and give my thoughts.

1 Like

Hello! I’m so glad you answered, I was dismayed. Thank you for embracing new ideas.

Thanks everyone for the thoughtful discussion here. I’ve been reading along and want to share my thinking.

The original Bookogs had a Work → Book model, but I switched to Book → Edition for ctlgs. The reason is language — people say “I have this edition” or “I’m looking for the first edition.” The Book is the abstract concept (title, author), and the Edition is the physical thing you hold, collect, buy, and sell.

I want to keep this model simple. The priority is making it easy to:

  1. Catalog — data entry should be fast and intuitive, not an academic exercise
  2. Collect — mark what you have, what you want
  3. Discover — find things you’re looking for
  4. Sell — eventually list items in a marketplace

A Work entity adds a third layer of abstraction, and I worry it makes data entry more complex for most users without enough payoff. The majority of books are single-work editions where Work and Book would be identical — that’s a lot of duplicate effort.

That said, I hear the problem with short stories and anthologies. The migrated Bookogs data has cases where this is clearly wrong — for example, the short story “Jumbee” is entered as a Book, and two completely different collections with different contents are listed as Editions of it. That’s backwards. The anthology should be the Book, and its various printings should be the Editions.

I’d rather solve these cases with better tooling within the current model — like being able to list contents/tracklist on an Edition — than by adding a new entity layer. I’m open to ideas on that front.

I think that the entity names are likely to be a confusing aspect for many users. People have books, they read books, buy books, etc, so they expect the Book entity to be a book. “Edition” is less clearly the physical item.

I wonder if Book should become “Title”, or “Volume”, or something, and “Edition” become “Book”. Changing Book to “Work” wouldn’t… er… work because the entity doesn’t always represent only one work, and that would also be confusing.

I still think that a Section idea would be workable without changing the current paradigm, even if it’s not a nested Edition - it’d help split up parts of a book with their own set of properties. From an operational user-perspective, I don’t think it would be complicated. When creating/editing an Edition click “Add Section”, fill in its properties, click “Add Section” repeat until all sections (be they chapters, other Editions, or whatever) are done.

A Section (or Part, if you like), would basically be the equivalent of a Track in a discogs Release.

You could look at it like:

  • Book (or whatever) = discogs’ Master Release
  • Edition = discogs’ Release
  • List of Sections or Parts = discogs’ track listing

If a Section can have a link to an Edition as its sole property, that would allow box sets to be meaningful, too.

I hope this makes some sort of sense.

As for the ability to find things, please consider my request for more fields (esp Impression No. and Notes) & larger images in a Book’s list of Editions: Visible 'Book'-level 'Edition' list data - #11 by xceque

I have 55 unique printings of The Warlock of Firetop Mountain - Books - ctlgs spanning multiple editions and multiple publishers, and it’s already impossible to work out which of the mere six entries is which in that list (one of which is a boxed set and shouldn’t even be in that Book).

Thanks to you for give it a thought

So, Books are going to be repeated for different translations:
Agatha Christie

  • Books:

    • *The Mysterious Affair at Styles

      • Editions:
        • A
        • B
        • C
        • D…*
    • El misterioso caso de Styles
      *- Editions:

      • A
      • B
      • C
      • D…
        The same in portuguese… russian… ukranian… 256 languages you can find..
        And so on for every book someone has written

In my particular view, the nowdays model is confusing.
You can’t be condescending to people who type in new data. Especially if the model right now is confusing and they have still succeeded. On the other hand, the model we propose is not at all difficult to understand, it is organic, material and direct.

But the model implemented now does not solve at all the peculiarity of editions with different works, and you cannot talk about majorities or percentages, you must create a model that accepts everything. If not, why have you been adding new fields these past few days? To compensate.

Do you really think that there are no misclassified publications currently in ctlgs?

Killing flies with cannon shots

You meant, you’re open to new ideas as long as you don’t have to touch the entities.

I am a person open to providing solutions if I believe that they could/will be taken into consideration for something useful or a proposal can be reached among all, having discussed and discerned, but if you have already given it a turn and have determined that the entities are not changed completely, then I have little to contribute. You closed my way rightly.

I thank you for taking the trouble to read the proposal.

A thousand hugs, bye

In the previous model a book was allowed to have multiple works, but as you say it was complex. And as @Burnett says, the payoff of this extra complexity isn’t clear.

The work concept is also a bit too abstract for my liking (and software engineers tend to like abstractions) - Should we be adding works for every article in a magazine, for instance?

I think it is much better to lean in to the real-world model as you suggest, but I also think as a dedicated collector community it’s fair to think we should understand the distinction familiar terms like book and edition.

The thing that’s poorly defined for me, is the inclusion of several items in the Genre entry, that feel like they’re more structural or descriptive of a format, e.g.

  • Essay(s)
  • Novel
  • Novella
  • Short Story(ies)

To me these concepts (and others) help categorise what we were previously calling a work (but could equally-well apply to a book).

I have seen a couple of example where “(Collection)” has been appended to the title of the book, because it is a collection of short stories, but the term collection was never part of the actual book title. It’s simply being done like this because of a unmet need in the data model, so let’s add “Collection” to that “format/structure” list as well.