Publishing

Publishing: editor in chief for periodicals?

2008-06-27T22:40:07.0000Z

Most periodicals should also be typed as Employer. The intent was that editorial staff could be entered there.

Publishing: editor in chief for periodicals?

2008-06-27T17:07:45.0012Z

I don't see a editor in chief or executive editor in any of the newspaper, magazine or periodicals. May I suggest a field be introduced if none exists?

Literary School Or Movement: Request: Remove links from Author and Written work

2008-06-11T05:48:28.0009Z

That might help but I doubt it will ever be as intuitive or as used as author, publication date, publisher, editor, etc. Written work is a very basic type that is almost always co-typed. Adding a such a non-essential property to it just seems wrong to me.

Literary School Or Movement: Request: Remove links from Author and Written work

2008-06-10T19:09:11.0000Z

Ed: upthread a bit, you mention that the property "school or movement" is not immediately intuitive. I think this may be the root of the problem. Coming from a literature background, it seems obvious to me. But it just occurred to me that from the standpoint of academic or scholarly writing "school" is a pretty ambiguous term. Maybe we should try to come up with a better name, and see how that looks.

Literary School Or Movement: Request: Remove links from Author and Written work

2008-06-10T18:15:06.0007Z

I think you overestimate the utility of hiding unused values. In viewing one, you view all. Further, you don't get information for a property until you start to edit it. Further still, in terms of types, the relevance manager does a lot of the work by narrowing down types. For properties you need to look at and interpret them all. You could probably develop a "functionality" distribution curve based on the number of properties for any given type. How many is too many? There will be a too many. I'm thinking about usability too.

Literary School Or Movement: Request: Remove links from Author and Written work

2008-06-10T07:57:36.0007Z

The only reason for moving date and place of death to a new Deceased Person type was that, especially in the old UI, it was extremely creepy to look at an instance of a person with those values just sitting there… waiting… empty… hungry for a value… The semantic value of a separate type was a much more minor point.

Especially given that the new UI hides unused values unless one really wants to fill them in, and given the comparative difficulty of figuring out which type needs to be added to facilitate using a particular desired property, proliferating types is really not useful. Sure, it may be more purely semantically clean—and I’m quite the sucker for that argument—but the usability is paramount.

Further, in this specific case, every piece of writing can be said to be in a school or movement, even the driest of non-fiction. So go ahead and, as you say, load it up!

Literary School Or Movement: Request: Remove links from Author and Written work

2008-06-10T03:07:23.0000Z

Welcome to the party Faye! I take your point but I still don't agree.

The deceased person type approach seems like a good one to me, although I might have kept the death date on Person because all people die. I can certainly understand the case for a Deceased_person type with associated properties but I can't understand why that case is perceived differently than Work_of_literary_school. I think the case is stronger for that type to be a separate one and not Deceased person.

The TV_program example is the same in that I would use an end date on the program type and possibly a "Cancelled_program" property or type for the details. Programs, like people, all have end dates no matter how good they are (see The Adventures of Brisco County Jr.). The details of the ending are tangential.

I would probably add spin-offs as a property of TV_program because the property is so intuitive and simple, even though spin-offs are not as common/universal as children and siblings. Plus, the potential for siblings, children and spin-offs is always present even if through adoption and/or nostalgia.

A "None" value could be used for siblings, children and spin-offs without asking the user to look up what they mean. The same can't really be said for Literary school/movement.

If you still don't agree, maybe I should start looking for other possible but not always relevant properties of written work so we can really load it up!? ;)

Literary School Or Movement: Request: Remove links from Author and Written work

2008-06-10T01:05:13.0007Z

Grrr, my super-unsupported internal discussion RSS died last Wednesday, and I can't believe I missed this discussion (kicking myself)!

As the person who asked for the property "Poetic/Literary School or Movement", Ed, I have to say I agree with Jeff. It's just not possible to normalize types and properties in such a way that all instances of a type have values for all of its properties.

Now we do try to factor out the rather silly or morbid cases. For example, having a "Date of Death" property on type Person for people still alive just seemed wrong, so the Deceased Person type was, uhm, born. But this logic is applied on a case-by-case basis.

If you take a look at the TV Program type, you'll see that there's a "air date of final episode" property. We could've created a similar "Canceled TV Program" type for that and separate it from the TV Program type, but then why stop there? The type also has "Spin-offs" and "Spun off from" properties, but since most programs don't ever achieve the kind of requisite popularity to have or be a spin-off, why not spin off those properties to form new types that only the most successful programs get cotyped with?

And BTW, since I'm an only child, I reject the fact that Person has a "Siblings" property that I can never fill out. Why isn't it moved out to a more appropriate "People with Siblings" type? You see where I'm going with this. :)

(Off to find more discussions I missed last week, grrr...)

Literary School Or Movement: Request: Remove links from Author and Written work

2008-06-09T23:07:29.0000Z

Er, yeah, that's what I meant!

Agreed, no workable model will have 100% of properties applicable to all instances. However, this one just seems really particular to a sub-group, not the whole.

Using the spouse/partner example, that property is immediately intuitive and has potential to be applicable to any instance. I don't think either of those traits apply to literary school/movement.

Literary School Or Movement: Request: Remove links from Author and Written work

2008-06-09T22:09:47.0007Z

I don't think it's possible to create a workable model in which 100% of properties on a type would always be applicable to 100% of possible instances. I note, for example, think we're not having this conversation about the property "spouse (or domestic partner)" on the "person" type, even though that property is not applicable to people who have never been married. Is your argument that there are too many types of written works and authors for which the "literary movement" properties can't apply? (Scientific journal articles, textbooks, technical manuals, most reference books, most reviews, most newspaper reportage all spring to mind.)

Literary School Or Movement: Request: Remove links from Author and Written work

2008-06-09T19:09:43.0000Z

I respectfully disagree. If a property does not apply to all instances of the type then I don't think it should belong on the type. A new type should be created that is co-typed with the first one and includes the additional properties. Otherwise, the sticking point you mention will result in unnecessary and aggregative errors. There should be no need to define "many".

A "Written work of literary movement" type that is co-typed with "Written work" and adds the literary movement property makes a lot more sense to me than forcing users to figure out whether or not their topic(s) meets the requirements to be attributed by any given property of an otherwise appropriate type. It's tough enough trying to figure out which type to use! :)

Literary School Or Movement: Request: Remove links from Author and Written work

2008-06-09T17:46:07.0000Z

I moved this to "written work" and "author" from "poem" and "poet" because it was silly to constrain movements to poetic movements. And I was a bit hesitant to put them on written work and author because the types are so all-encompassing. But I do worry that creating "member of literary movement" and "work belonging to literary movement" types would be worse. It's pretty trivial to leave properties blank. It's rather more work to add a new type to get a property, since you have to know that you need to do so (although the publishing domain is chock full of these already, I admit).

Properties do not need to be applicable to all instances of a type to be on a type; they just need to be applicable to many of the topics (the definition of "many", of course, being the sticking point). And a significant number of poems, plays, fiction, essays, and certain types of prose non-fiction could be said to belong to a school or movement.

Publishing: Different authors between book editions

2008-05-29T21:33:49.0007Z

OK, looks good. :)

Publishing: Different authors between book editions

2008-05-29T06:51:52.0000Z

Sounds like something that'd be easier to visualize once it's filled out on the board. I'll come by tomorrow.

Publishing: Different authors between book editions

2008-05-28T20:23:06.0007Z

What do you think of the proposed "Edition series" --> "Book" --> "Book edition" model? Especially if we can come up with a less ambiguous name than "edition series"?

Publishing: Different authors between book editions

2008-05-28T19:47:27.0007Z

Yes, there is a huge difference between the various editions of the first edition of Compilers and the various editions of the second edition of Compilers. But the "hardcover CD-rom package" edition ("binding", really) of the Compilers, 2nd edition, still has a much closer relationship to the original Compilers book than does say, David Flanagan's Java in a Nutshell. Modeling this relationship is of interest to me.

As you said, two definitions exist for "edition", one is used to describe more or less binding, the other is used to describe content. We have the schema to model the first case, I propose we come up with a schema to model the second case.

Publishing: Different authors between book editions

2008-05-28T19:00:05.0000Z

Faye, would you describe the hardcover and paperback editions of the first edtion of Compilers as having the same relationship to each other as to the hardcover edition of the second edition of Compilers? Because I don't think they do. The hardcover and paperback are just different bindings of more-or-less the same content; the hardcover of the 2nd ed. is a binding of a volume containing different content.

We're not actually redefining "book edition" at all. What the model does is specify one of two common meanings for "book edition". The relevant definitions are (courtesy of the American Heritage Dictionary, 4th ed.): "The form in which a publication is issued: a paperback edition of a novel; an annotated edition of Shakespeare." and "A version of an earlier publication having substantial changes or additions: a newly revised edition of a standard reference work." The type Book Edition was designed with the first definition in mind; you (understandably) want to use it for the second.

Hanging translations off a Book Edition is certainly possible, but which of the three editions of the original edition of Compilers would you hang the translation off of?

I like Ed's idea of treating books with multiple editions (of the second sort) as a series. I'm not sure about the name -- I think "book edition series" gets us into the same trap that "book edition" is doing. I would expect something called "book edition series" to collect instances of the type Book Edition (like the Harvard Library or Norton Critical Editions); but I don't know what else to call something that collects instances of the type Book that were published in serial editions.

Publishing: Different authors between book editions

2008-05-28T17:56:58.0000Z

I rather like that idea, edition series.

Publishing: Different authors between book editions

2008-05-28T02:29:34.0000Z

Books with multiple editions are somewhat analogous to Motorcycle series, which are one of the most common Wikipedia motorcycle subjects. A motorcycle series is a grouping of the same motorcycle body styles of the same motorcycle model over multiple model years (e.g., Harley-Davidson XL1200N, BWM F650 CS). Motorcycle series can even be nested (e.g., the Honda CBR series includes many subseries). I found that series was often used to provide a consistent name for a group of motorcycles that were thought of as a collective but not identical. Maybe a book_edition_series type could be used with a property of "Book editions within this series"? This would allow Compilers to be a topic with properties that describe the entire series including links to the various Compilers book editions.

Publishing: Different authors between book editions

2008-05-28T01:53:59.0000Z

I was all but convinced, but now that I've given this a little more thought, I have to admit that modeling Book Editions as Books still bothers me.

First, the more philosophical argument: I think of the second edition of the Compilers book as the second edition of the Compilers book because it is, as we say even now, the second edition of the Compilers book. When we redefine common terms like "book" and "book edition" (completely disregarding M-W's many wonderful editions of their hot-selling dictionary) to accommodate a "special case", we introduce an extra hurdle in the learning curve new users must overcome before they can enter quality data. Perhaps not so bad that one can't shrug it off as I was tempted to do, but nonetheless it seems forced, sloppy, compromised, and resigned to having to live with data and schema that are...incongruent -- and I don't mean that as a criticism but just a reflection on the fact that no neat little boxes of Types, no matter how thoughtfully constructed with perfectly curved-out included typed and supporting types and cotype usage, can accommodate the myriad varieties of real-world data that's beautiful and complicated and convoluted at the same time and oh God I've become Mark Morford. I do ponder the cumulative effect of these counter-intuitive "special cases." Maybe it's just me, but I can't seem to go a week on Freebase without running into these "special cases". :)

Then again, it also seems intuitive to me, at least after mulling over the Compilers book data, that translations should be at the Book Edition level. David Flanagan's "Java in a Nutshell" has gone through 5 editions in the last 10 years. If I'm looking for a translated version, I'm definitely going to make sure it's of the 5th edition. Does that mean we model every book edition (that belongs to a book with at least one other edition with different content) that has an associated translation as a separate book? I'm confused.

Oh, and how does one reconnect the severed link between a book's multiple editions when they are modeled each as a separate book? Looking at each edition as a book, how do I know if other editions exist?

Publishing: Different authors between book editions

2008-05-27T23:53:23.0007Z

These are some of the thoughts that make think it makes more sense to model it as two books. The original version of Compilers was published in at least six editions, including three translations. All these editions have a similar relationship to the original (three-author) Compilers. But I don't think they have the same relationship to the four-author version. Taking this further, I think it's quite useful to be able to say which edition the translations are made from. If we combine the two editions at the Book level, it is impossible to know which version the translation is of, which might be valuable to know, especially for a hypothetical work that might have had translations made of multiple editions.

Another analogy is dictionaries. I have a hard time thinking of Merriam-Webster's Collegiate Dictionary, 11th Edition as being the same book as Merriam-Webster's Collegiate Dictionary, 2nd Edition, say.

But I do agree that to a certain extent, we're dealing with Theseus' paradox, and any solution is likely to be idiosyncratic. (Even WorldCat, which conflates all of the various types of editions of Compilers as editions of a single work, only conflates the various versions of the 10th and 11th eds. of the M-W Collegiate Dict.)

You can perform an end-run around it, though. You could simply not create a Book topic for the book, and just have individual Book Editions, each linked to the appropriate authors.

Publishing: Different authors between book editions

2008-05-27T23:31:06.0000Z

Souldn't each edition be a new book? I can think of many examples when different editions of textbooks have different authors or editors. There are often different cover artists and even publishers. A similar argument could be made for printings if the cover, forward, etc. have changed.

Poem: Poem vs. Written Work

2008-05-05T21:10:37.0007Z

No, we probably don't need the "poet" type, now that you mention it.

Poem: Poem vs. Written Work

2008-05-05T20:36:51.0007Z

Not to gang up on you, but it does bother me that the Poet type is pretty much an empty label, tagging an author as a poet. Do we need such a data-barren label? Why not just do away with it altogether?

The singular "Poetic School or Movement" property could be easily merged into a more general "Literary School or Movement" that would hang off of the Author type. That a person can be labeled as a Poet could be entered in the Profession property of the Person type, if at all.

Poem: Poem vs. Written Work

2008-05-05T19:51:06.0000Z

Thanks for the replies. Unfortuantely, I don't have too much time to deal with the intricacies of data modeling, but I do like to throw my hat in the ring now and then.

It's quite interesting, however, to dive in deeper and see some of the complexities that you're dealing with. I'll keep adding data whenever I can =)

Poem: Poem vs. Written Work

2008-05-05T18:58:16.0007Z

I'd add, to Faye's excellent explanation, that the documentation might be a bit out of synch with the current model -- we're in the middle of refactoring this domain, and I wanted to hold off redocumenting until the schema was stable. I hope to fix this soon!

With regards to the question that Faye fobbed off on me (as a domain admin, that is), the reason that "poem" doesn't link directly to "poet" is because to do so would create a denormalization -- people would have to enter the poet both in the poem type and written work type. "Written work" contains properties, including author, that are common to all kinds of written works, making it more consistent to query and enter.

What conflicts do you see between written work, published work, and poem? I've tried to make these complementary, but if I've missed something, I'd like to know so I can fix it.

Financial support provider: Suggestion: generalize and reciprocate with supported projects

2008-05-05T18:04:33.0005Z

Can we generalize this type to include any financial support provider and attribute it with a list of reciprocated support types. Some properties could include Supported research projects, Supported programs, Supported organizations, ...

Poem: Poem vs. Written Work

2008-05-02T02:00:42.0007Z

Hi Mark,

I think my reply to your other post is relevant here as well. Published Work and Written Work are included types of Poem (meaning a new poem topic you create will automatically be typed Published Work and Written Work as well), because we find that relationship to be generally true.

Authorship is a basic shared property of all Written Work: be it a Poem, Short Story, Short Non-fiction, or Review. It's not a conflicting relationship, but an inclusive relationship. The fact that there's no direct link between a Poem and a Poet is unfortunate, but I'll leave that to be answered by an admin in this domain.

The publishing domain is one of the more complex (and well thought out) domains in Freebase. I suggest taking a look at the list of help documents at the top of the domain page. They go through how to enter different types of data in detail. It may sound straight-forward, until you realize the data model allows you to input a collection of translated excerpts of non-fiction work in a periodical -- that kind of data modeling requires some complexity, which unfortunately does make the simple case a little more complex as well.

Oh, one more thing. Bear in mind that there's heavy refactoring work going on here, so what you see is not necessarily what will be.

Poem: Poem vs. Written Work

2008-05-02T01:04:58.0012Z

Poem doesn't have an author? This seems weird to me; and shouldn't it be a type of written work? There seems to be some weird conflicts between Poem, Published Work, and Written Work

Written Work: Online versions vs. Weblinks

2008-04-29T16:24:26.0000Z

Perhaps some, but probably not too much. Part of the idea behind having distinct properties for some types of links is to allow users/the API to distinguish between miscellaneous links and links with some specific meaning/value/purpose. In the UI, all links are actually entered and displayed in the "weblinks" box. The association with the property is made in the "type" menu when you enter a link.

Written Work: Online versions vs. Weblinks

2008-04-29T04:16:18.0012Z

Seems like you will get redundancy between these two fields. Thoughts?

Publishing: Plans for scraping publishing data?

2008-04-28T18:43:59.0007Z

I agree about that! I can tell you that we don't have any current plans to import written works in bulk other than books, book editions, and possibly academic publications, so poems, essays, stories, etc. that aren't in Wikipedia will definitely be needed. And, for topics we got from Wikipedia, anything that's not in an infobox or implied by a category, will probably not be extracted in the near future. (By "implied by a category", i mean that a category like "Sherlock Holmes stories by Arthur Conan Doyle implies information about the author, the series, and one of the characters.)

Publishing: Plans for scraping publishing data?

2008-04-28T18:30:20.0000Z

Thanks Jeff! It's interesting to know what the plans are for these data loads. It's more satisfying to fill in data if you feel like all/most of the work that could have been done by a bot is already finished.

Publishing: Plans for scraping publishing data?

2008-04-28T18:13:16.0007Z

We were waiting until the publishing schemata stabilized before going after large amounts of data. We're mostly done mucking about with it now, so we're going to start doing more with this. In terms of getting Wikipedia data typed correctly, we have some bots that look at categories and infobox templates which should type more of the essays, stories, poems, books, etc. that are in Wikipedia, and in some cases be able to associate them with authors.

We can't get Amazon or WorldCat data, because Amazon and OCLC don't have licenses compatible with CC-BY, alas. We do have some data from ISBNDB, which we're working on reconciling and loading.

Publishing: Plans for scraping publishing data?

2008-04-28T17:47:09.0012Z

A quick search for "an essay by" on Wikipedia.org gives 800 results compared to the 96 pieces of short non-fiction on Freebase:

http://www.google.com/search?hl=en&client=firefox-a&rls=org.mozilla%3Aen-US%3Aofficial&hs=KjC&q=site%3Awikipedia.org+%22an+essay+by%22&btnG=Search

More generally, what are the plans to fill in publishing data? Can Freebase scrape Amazon or WorldCat data ( http://www.worldcat.org/ )?

Book: Book Titles in other languages

2008-04-10T21:08:57.0007Z

freevase? I mean freebase. ;)

Book: Book Titles in other languages

2008-04-10T21:08:34.0007Z

I'm afraid that currently, there is no good answer on how we should name books (and such) with non-english titles. There's been discussion around this issue - see the data-model list for the thread.

Unfortunately, that also does not answer your question at hand. Aliases show up in autocomplete, so you can input either the original language title or english title as the alias and it will show up in autocomplete.

Also, you can check out this excellent blog post about freevase and internationalization by crism.

Book: Book Titles in other languages

2008-04-10T20:13:59.0000Z

This is fairly common problem, unfortunately. This was discussed on the Freebase data-modeling mailing list a little while ago, starting with this message.

More generally, this post on the Freebase blog discusses some of the ways internationalization is (and isn't) handled in Freebase.

In the short term, I'd recommend using the English title (when there is one) as the main title, and entering the original-language title as an alias. (If you're entering book editions, however, you should always enter the title as it appears on the book, no matter what language it's in.)

If you're feeling enterprising, and don't mind mucking about in MQL, you can try to insert the title in Spanish, following the examples in the blog post.

Book: Book Titles in other languages

2008-04-10T18:53:09.0000Z

Yeap, i have the same problem with Vargas Llosa.

Publishing: Different type for collections of poetry, short stories, essays, etc.

2007-12-22T07:50:28.0007Z

You might want to check out the Published work type and the Short story type. Also, there is a Help Center topic on Entering the Contents of a Book or Periodical.

Publishing: Different type for collections of poetry, short stories, essays, etc.

2007-12-22T04:38:09.0007Z

Has there been any resolution on this? There are some books which are really just collections of short stories that I'd like to enter.

Reviewer: Reviewer as Author

2007-12-19T21:21:38.0000Z

I agree that peer-reviewer is more of an editor than an author. A peer-reviewer does not create content but critiques someone else's work (not that I'm trying to make it sound bad...). ;)

Reviewer: Reviewer as Author

2007-12-19T21:07:21.0007Z

I saw that. It looks good! I did not realize that this type was getting rolled into authorship during that refactoring. It looked to me like it would be linked instead.

I agree that peer-reviewer should be a different type than other reviewers but I was thinking of going about it another way where peer-reviewer is a type of editor. They are not really authors. Also, the reviewer described in this discussion topic is an author of a type of published work (i.e., review).

Reviewer: Reviewer as Author

2007-12-19T19:19:55.0007Z

Heh. I meant to say that "I posted a set of proposed changes to the data-modeling and developers mailing lists last week".

Reviewer: Reviewer as Author

2007-12-19T18:52:32.0007Z

I posted a set of proposed changes to the publishing domain that might include this change last week (among other things, I want to roll most of the types that are similar to author together). My proposed schema has been subsequently wiped from sandbox, so it's not visible now. I'm hoping to make some adjustments to it and re-post it today (if not, it might have to wait until after the holidays). I'd recommend creating a new type for peer-reviewers, though. Partly because we'll want to be able to migrate the data cleanly to the new types (rather than having to sort out which person is what kind of reviewer), and partly because peer-reviewer would presumably link directly to the work reviewed, rather than to a published review.

Reviewer: Reviewer as Author

2007-12-19T06:39:00.0005Z

I suggest that this type should be merged with author. All the people here are authors and their published works are only different in that they are summaries of original works. The type may be better used to represent people who review works through peer-review or similar process. That's how I wanted to use it anyway. To capture the information currently included in this type you could add a Boolean property of "Original source?", or something similar, to the Published work type.

Periodical Publication Date: Issue as machine readable text?

2007-12-18T00:55:04.0007Z

Changing the expected type of "issue number" is a good idea. I'll have to check out how much data needs to be migrated, and find out if changing the type will break any applications, but I think it should be pretty straight-forward.

I've moved the "additional date info" down; it won't display as well (e.g., "Summer 2007" will now display as "2007 Summer") but I think you're right that this is less annoying than having it appear first for data entry.

Periodical Publication Date: Issue as machine readable text?

2007-12-14T09:21:49.0005Z

I know this will have pretty big consequences, but would it be possible to change Issue from Integer to Machine readable text? The reason I ask is because some publication volumes contain multiple issues (e.g., "1-2"). This seems silly to me but they do it. Also, there are probably some cases where Issue is a character (e.g., i, A). The Additional date info property could be used to store this information but it doesn't really seem appropriate to do so - it refers to date.

Another thing, would you mind moving the Additional date info to the bottom of the list of User Created Properties? It is probably less often used than the other properties and it typically refers to a subset of the Date property.

Published Work: Horizontal list?

2007-12-11T17:15:56.0007Z

I think a horizontal list would make the information harder parse when there are multiple publications. This may all become moot soon anyway, since there's going to be a major redesign of the UI fairly soon, and I'm not sure how the horizontal/vertical lists will appear.

Published Work: Horizontal list?

2007-12-11T08:51:06.0000Z

The horizontal list is presented with a smaller font and grouped tighter than the vertical list. Depending on how much information is on a page, this type tends to get pushed off the page in a vertical list so that I must scroll to see it. Changing the order of objects in the list would not really solve this problem for me. I'm pretty new to how everything is organized here so maybe I'm missing something but a horizontal list seems like it would solve my problem.