Discussions on Comic Book Story

Hi Chris, Let's see if I can explain my thinking in designing this domain. The model I chose for comic books defines the smallest narrative unit (how's that for jargon) as a story in a single issue of a comic book. This allows us to handle the very frequent pattern (well in the golden and silver ages anyway) of multiple stories in a single issue. So issues of comics are more of a story container. This allows us to model reprints effectively without just recreating all the data. Story arc is a collection of related stories. For instance the dark phoenix saga took place over many issues of the X-men, each issue with it's own chapter (frequently with a story title on the the first page "Deadly Reaction Part 3." etc. (okay I made that one up)). In our model you would create a story arc called Dark Phoenix Saga and then add the issues that are part of that story. Your suggestion of adding the ability to specify what form a story took (was it pages from a single comic book? was it issues from a single series? was it issues from multiple series?) would be very flexible, but it would also make querying Freebase very very difficult. Any property is only allowed to have one expected concept type. This means you would have to model story to have all those properties (start page, end page, etc) and only use the ones that apply. Then you would have to query and run some logic to determine which form it takes (heaven help us if someone has filled out both) and how to display it. It would also tie a story arc inextricably to its printing, making it very difficult to model multiple printings of a story. I hope this clears it up a bit. Feel free to post any more questions you have... and to key any comic books you have ;) Tristan

I understand the problems with having properties which are sometimes used and sometimes not. I think that means you have to distinguish between the two kinds of stories. The common mode for modern comics is to have a story-like narrative thread last for several issues. But I don't see how to represent that. Also, I think representing that using two full-blown "Issues" objects might be overkill, when all you need is two integers to represent the starting and ending issues of the mutli-issue story. Perhaps we could use two types.

Comic Book Multi-Issue Story
-- start issue
-- end issue
-- "Comic Book Story"

Comic Book Sub-Issue Story
-- start page
-- end page
-- "Comic Book Story"

This seems a little clumsy. I might actually prefer the optional parts of a story that
I originally described, even though I it will cause the searching problems you described.
But the searching and presentation problems you described would apply equally if we
used different types for the different kinds of story sequences, right?

Are there other examples of similar optional properties in freebase? I'll see if I can find
any similar examples, and come back and post them here.

But what if a story consists of multiple sub-issue stories? I think story-arc combined with making an issue entity for every issue and a story entity for every story contained therein is our best bet.

Generally we try avoid optional properties if we can, so it's somewhat hard to find. I think it shows up in the politics domain a bit.

Also is there a case you can think of that the current model wouldn't handle? I haven't been able to think of any, so I'm not inclined to change it in a hurry. But let me know if there's something bothering you about it.

Okay, help me understand. I have two comic issues. Amazing Nobody #103 and Amazing Nobody #104. The first one says in front: "Rainbow Zebras Part 1". Issues #104 says at the front: "Rainbow Zebras Part 2". Tell me the way to record that using the existing types. At the end of issue number #103 there is a cliffhanger. It seems clear to me that issue #103 does not constitute a "Story" by itself. But I can live with it, if that's the model we've chosen to use. Do I say that #103 has a story, and #104 has a story, and both stories are part of a story arc called "Rainbow Zebras"?

Exactly, except for our purposes both parts are stories (for lack of a better word). I also don't think "part of story arc" would even have to be unique, as "Rainbow Zebras" could be part of some larger cross-over event.

Thinking more about all this, I realize that the case might come up where some issues are sort of "weakly" part of an arc. For example there might be some general continuity between the issues and references to the events, but nothing really taking place over the two issues. I suppose you'd have to leave it to the fans of that particular series to determine if it warranted the creation of a story arc.

I'm glad we're discussing all this, as it will be good fodder to use in the documentation for story arc (which I seem to have been putting off to everyone's detriment).

Okay. Just to make sure I understand. I have two comics in front of me. I want to enter their basic information (including story name). I create the following objects:
Story Arc:Rainbow Zebras ---
Story: Rainbow Zebras Part 1 (Part of Story Arc -> Rainbow Zebras) ---
Story: Rainbow Zebras Part 2 (Part of Story Arc -> Rainbow Zebras) ---
Comic Book Issue: Amazing Nobody #103 (Has Story -> Rainbow Zebras Part 1, Part of Series -> Amazing Nobody) ---
Comic Book Issue: Amazing Nobody #104 (Has Story -> Rainbow Zebras Part 2, Part of Series -> Amazing Nobody) ---
Comic Book Series: Amazing Nobody ---

That seems to be a little more clicking than I was hoping for, since I'm currently entering this data manually.
I'll go search on this site and see if there is a spreadsheet upload functionality. It might be easier to
type a few pages of data into a spreadsheet then upload it, if I can configure the processing of a table
to automatically creat objects for me.

Arg, sorry. I thought of another snag. One problem is that the creator names and roles in most of my comics are all the same for all the issues that are part of a "Story Arc", but in the current heirarchy that information is attached to the "Story" not the "Story Arc". That's one of the things that originally steered me toward wanting to say that my two issues in the example above were part of a single "Story" because the creative team and other supporting details are exatly the same. It seems really flexible if I can say a "Story" has a "location". I found some food for thought here: http://freebase.com/view/?id=%239202a8c04000641f8000000005136237 .

Okay, I worked on a new type. I've created types in my own domain and exported them. There's one called "Comic Book Work" which can designate two things: the list of contributions by artist, writer etc, and also a link to the existing "Comic Book Series" data type. Give them a look and see what you think. I'm not sure how to make use of other people's types at this point. I made some and exported them. Let me know if I have to do anything else to make them visible.

I think you need to connect the writers and artists to the individual story, because you can very easily have arcs which encompass the work of many artists and writers.

In this sort of modeling I've tried to use the finest grain detail necessary for the vast majority of situations. Our current model does make more work from a data entry standpoint (though we have autocomplete, so that helps), but the way your proposing I think makes it far too difficult to query.

We will most likely have loading from spreadsheets at some point in the future (we have internal tools now that are just too dangerous for the outside world). So if you want to use spreadsheets, we could probably load it.

At the risk of belaboring this a bit, I have to say that I agree with quenelle since I'm running into many of the same problems as him.

For example, I'm trying to figure out how to enter Batman: A Death in the Family into the KB, a story arc containing four issues. I'd like to enter the artists, the writers, and the 4 prominent characters involved in the story. The way it is currently modeled though, instead of 8 people I would have to enter 32. It also requires adding 4 individual story components, on top of the 4 issues that I would otherwise enter, presumably linking the correct image from the corresponding issue for each. It is a lot of extra work for adding a single story-arc.

Most storylines in comics these days seem to last for multiple issues, all with the same artists and characters. I'm happy to help you guys out by entering some of the information I enjoy, but this level of repetitious entry quickly becomes tedious and isn't something I can imagine myself or others doing. It seems to me that if you depend on voluntary user input, that it should be crucially important to keep things simple for the user to enter.

I'm not quite sure I follow your point on optional properties making queries difficult. So perhaps that's part of my problem. I'm new to freebase but it's rare that I see a topic with all of its properties filled in. It also seems to me that the current representation would cause the same sorts of problems with a query by page or issue. On top of that, it would create unnecessary specification for queries by artist or character, which I imagine would be more common. For example, I imagine a user querying for stories involving the Joker would prefer to see "A Death in the Family" rather than "A Death in the Family, Pt. 1", "A Death in the Family, Pt. 2", etc., especially since the latter could have been retrieved from a query over issues rather than stories. Maybe you can give a specific example of a query that would cause problems under quenelle's suggestion but not under the current implementation? That would help me understand.

I do recognize that some large arcs/crossovers can involve multiple artists, characters, and plot-lines. (eg Marvel's Infinity War, DC's Knightfall). But given the trade-offs, it makes more sense to me to implement that either with a new "cross-over story" type or maybe even with some transitive relation allowing stories to contain other stories. Knightfall is a particularly horrifying example since it is an umbrella title for the four sub-story-arcs Knightfall, Kinghtquest, KnightsEnd, and the Aftermath, containing 73 individual issues in all.

Just so we're on the same page, the way I envision quenelle's suggestion working is with a multiple-value property called something like "Told In", where each value could contain an issue and optionally, a starting and ending page. (Could also do it with separate properties for Issues and Pages but that would probably just complicate things).

Looking forward to your response.

I've created my own types as an experiment. I made "Comic Book Work" to represent a story with a single set of creators, which might be a graphic novel, or a sequence of issues. A Comic Book Work has a list of Contributions from people. I also created a "Comic Book Contribution" which is a pair consisting of: (Role: of type profession) (Contributor: of type Person) and (Notes: of type text). A Comic Book Work can also have a reference to a "Comic Book Series" if it occurs as part of an ongoing series (it doesn't have to). I'm not sure other people can see my types and data. I've tried to open it up. Can other people see the types, and the data I entered? http://www.freebase.com/view/domain/user/quenelle/default_domain