I created a new type Comic Book Collection and populated all Fables TPBs data. Let me know what you think.
If the type is useful enough, what's the process of adding it to the official comics domain? If it gets added there, do I still have some control over it or do further changes need to go through review?
Thanks
I think this is an interesting type, and it has some potential. I'm concerned about its overlap with the types book, book edition, and written work, though. I think it would be good to take out the properties that are duplicated from those types, and get them via including the other types. Before we could do this, though, we'd have to figure out whether comic book collections are books or book editions. The difference is that the topic with the types Book and Written work is for the abstract notion of the work, and contains information that is always true about the work, no matter how it's published -- author, copyright date, genre, etc. Book edition is used for specific publications of the book, and has properties for publisher, publication date, etc.
Comic book collection has properties that correspond to both the abstract and specific notions, so we'd need to figure out where they went.
I want to reconcile the two schemata because we're ultimately going to be getting a lot of book data from various sources, and comic collections/TPBs/graphic novels will almost certainly be included with some of that data, and I'd like to avoid duplication.
But I do like the specificity of contents and contributions that this provides, which is more specific than the contents model in the publishing domain. We could do issues and stories collected using that model, but the roles would have to be less specific (author, editor, interior illustrator, cover artist).
Comic Book Collection does resemble a book edition, but it's not really an instance of abstract written work. And it's definitely not an abstract book/written work.
After all, a comic book issue is a written work in some sense, but we don't have an abstract comic book issue and then an actual published comic book issue.
I think there's too many properties not directly applicable to comic books. But I see your point about importing book data, so maybe inherit the book edition and live with the differences?
I think including the Book Edition type is probably the best solution. And I really think only a few properties don't apply to comic book collections. TPBs and graphic novels are, after all, published like books, and have ISBNs and Dewey classifications and all that stuff. Audio reader is obviously not applicable, and the cover artist and illustrator properties are less precise than we would want for comics; contributing author is about as wrong for comics as it is for everything else -- it's there only for when we don't know more specific data.
(You did, however, just give me a very scary thought. It would not be wrong to model comic book issues using an abstraction/instance model, although it would probably only apply to the cover art in most instances, since variant covers tend to come in and out of fashion. And every once in a while, single issues are reissued, like for Free Comics Day. Not that I really want to do this -- it just occured to me that it would be possible.)
I ended up including the Book type in the Comic Book Collection (CBC) type. Both TPBs and hard cover volumes can be modeled through its Editions property. This would also work better for data import: i.e. Amazon has Punisher War Journal Vol. 1: Civil War as hardcover and links to the TPB edition.
Do you agree that Comic Book Writer, Comic Book Cover Artist, and Comic Book Publisher should not be removed from the CBC type even hough they map to more general Writer, Illustrator, and Publisher properties? The users can add comic book specific data after data imports that prepopulate general properties.
I definitely think that publisher should be removed, since it's properly a property of book editions, not books (Jeff Smith's Bone collections, for example, have been published by at least three different publishers). I'm not 100% sure about writer and cover artist. I'm starting to think that these properties are not that different for comic collections than for other types of books. For example, visual artists will probably be listed as authors of monographs; newspaper comic collections will have the writer as author and illustrator as cover artist. I could be convinced the other way, though. (I'll take a look at Graphic Novel tomorrow.)
I removed the CBC publisher, and also removed the collection cover artist, as different editions might have covers done by different artists. I still think the CBC writer might be good to keep, especially if the comic book writer had a 'Comic Book Collections written' property which would be automatically linked to collections.
I guess the Book type Editor property might be reused too, depending on how precise we want to be at the collection level. Some comics credit Editor, Assistant Editor, Senior Editor, and Editor in Chief, but it's not that precise at a comic book issue level either.
In terms of editor, I'd say that if the level of precision is valuable, then we should keep the CBC properties. But if we only care about the primary editor, or don't mind lumping all editors together, we could use the property from Written Work.
For writers, I guess the advantage to the denormalization is that "comic book collections written" is more specific than the "works written" property on Author. Chances are, CBCs will end up with values in both properties, which would not be wrong, and is not necessarily bad.
>typelibrarian
Thanks for the input. I agree about the CBC writer. As for the editor properties, I could go either way, but it never hurts it include more properties as someone might use them.
