Publishing

Publishing: Possible revision for Journal Articles

2008-09-04T18:09:52.0012Z

If Jounal Article were linked directly to Journal Issue, it would remove the need for co-typing it with Published Work. But otherwise, what you suggest would work. But if we do keep the existing Journal Issue model (as opposed to the CVT version under review), I'd be reluctant to undermine the existing Published Work/Publication model by creating a special type that used a different method of publication. (I realize that I'm already proposing this with the CVT model, and I do recognize the inconsistency; I guess my argument is that if the needs of modeling Journal Articles are significantly different from other types of publications the different model is justified, but if it's just a question of copying the current model onto different types, I'm not sure that it is justified.)

Publishing: Possible revision for Journal Articles

2008-09-04T04:37:43.0012Z

You could make a Journal Article type that includes the published work type. then make the contents of the Journal Issue type link to Journal article. That way any new objects that get linked to from a Journal Issue will automatically be created as Journal Article types. So users won't have to manually add the Journal Article type. The problem is that all existing articles that are presently of the published work type would have to be migrated over to being of the journal article type.

Publishing: Possible revision for Journal Articles

2008-09-03T22:07:06.0012Z

At that point, Journal Article would be nothing more that what we sometimes call a "bucket" -- a type that has no properties, and is therefore just a place to collect things that can be said to be of that type. There are a number of these here and there, but we try to avoid them as much as possible. In order for it to be useful, users would have to remember to add it themselves to each topic that is published in a journal; we're already asking users to manually add a lot of types in the publishing domain, just to use the basic functionality, and I have doubts about how much this type would ever be used.

I can't think of a way, through the UI, to filter out only those works that were published in Journal Issues. How often do you think people would be looking for journal issues but not other types of academic or scholarly papers?

Publishing: Possible revision for Journal Articles

2008-09-03T21:10:00.0012Z

Okay, let me see if I understand. Currently, you can enter the journal article in the contents of a journal issue where it links in as a publication. And in published work type, there is the "published in" property which gets filled in with the journal issue. So there is no specific Journal Article type because there doesn't need to be one separate from publication. Sorry about the confusion.

So now I'm having trouble figuring out what to do if you want to search for only journal articles? I start by searching for published work, but when I try to filter it by the "published in property", it wants me to put in the name of a specific publication, it doesn't accept the type Journal Issue. I suppose that the sandbox version would solve this problem, but at the expense of not being able to record issue level information. It might still be more user friendly to have a journal article type under the current system even if the journal article type has no extra properties above and beyond published work. It would simply allow for distinguishing journal articles from other publications at a glance.

Publishing: Possible revision for Journal Articles

2008-09-03T19:17:23.0012Z

The issue isn't about having both an article type and an issue type -- we already have those (see the help topic Entering Scholarly Works and Citations for an explanation of the current model). The issue is how to best represent the publication information of an article -- whether by omitting the issue type entirlely, and just using a CVT to capture the basic bibliographic information, like you would see in a bibliography (or bibtex or similar format), or whether to have an explicit topic for every journal article.

There is not, alas, a way to display the information in chained links. You can display disambiguating properties from the expected type of a property only. So in the sandbox version, the volume, issue, etc. are properties on the Journal Publication type, and so can be displayed on the article and journal types the connect to it. But the way we otherwise handle publications is by using the "published work" and "publication" types, which have to be set as co-types on the article and issue. Because the expected type is not explicitly "journal issue", properties on "journal issue" are not displayed on the article or journal.

Let me know if this doesn't make sense.

Publishing: Book edition properties

2008-09-03T15:29:52.0017Z

I wonder whether there should be an optional editor property for book editions. I just added the book, The Right and the Good, by D.W. Ross. It was originally published in 1930 with no editor. It was re-published in 2002. The 2002 edition was edited by Philip Stratton-Lake. Given the current schema I had to put Philip Stratton-Lake as editor of the book, but this is misleading because it makes it appear that Stratton-Lake was the editor of the 1930 original.

Publishing: Possible revision for Journal Articles

2008-09-03T00:31:03.0012Z

I like the way the sandbox version looks, but I'm not sure I understand the concern about the schemata coming apart if you have both and issue type and an article type. You wouldn't store the issue information separately in the article type, you'd just link to the issue, and the issue in turn links to the Journal.

i.e.,

Object of Article type has a property "Published in" linking it to an object of Journal Issue type

Object of Journal Issue type has a property "Journal" linking it to a journal.

What I'm not sure about, because I'm new to freebase, is whether there is a good way to display the information if links are chained in this way. If you set up the types in the way I've suggested, can you look at a journal article and see both the issue and the journal that that issue links to?

Maybe there's something I'm not getting about your concern about schema getting out of sync. Please let me know as I'm anxious to learn more about how things work around here.

Publishing: Possible revision for Journal Articles

2008-09-03T00:07:30.0012Z

The proposed schema is on sanbox again, here this time:

https://sandbox.freebase.com/type/view/book/journal_publication

Publishing: Possible revision for Journal Articles

2008-09-02T21:57:56.0012Z

I see your point about the theme and target-article issues, and why it would be useful to be able to view the contents at the issue level in those cases. Although if you know the issue/volume/date information, you could use the filter view of the CVT to recreate a table of contents (there would be nothing anywhere that said, however, that "This is the X-themed issue of Y journal". I am more than a bit concerned about using both schemata simultaneously -- I worry both that the two schemata would fall out of synch very quickly, making it harder for users to use the bibliographic data, and also that someone might figure out a way to keep them in synch (via some automated process), which would eat up a lot of extra space.

I'd be curious to hear more of your thoughts on this.

I'll repost the schema to sandbox either later today or tomorrow (the data on sandbox is due to be refreshed in an hour or so).

Publishing: Possible revision for Journal Articles

2008-09-02T20:04:54.0012Z

I think it might be going too far to eliminate the issue type, although I agree that for most purposes the article is what matters. Some journal issues deal with a set theme or with responses to a target article. For example, The American Journal of Bioethics always sets one or more target articles that other contributors respond to. So it might be useful to keep journal issue as its own type to enable tacking this kind of issue-level information. I don't know the system well enough yet to know whether this information can be stored in a CVT or if it needs a standard type. It might make more sense to eliminate the issue type for newspapers, since generally there is no theme to the content of a single newspaper issue.

Publishing: Feild of study

2008-09-02T19:53:19.0000Z

Thank you, you're right that does seem to cover it. I'm still getting used to the way that co-typeing works (i.e., that something can be both a feild of study type and a book subject type).

Book: Feild of study

2008-09-02T19:53:19.0000Z

Thank you, you're right that does seem to cover it. I'm still getting used to the way that co-typeing works (i.e., that something can be both a feild of study type and a book subject type).

Publishing: Feild of study

2008-09-02T17:40:31.0012Z

All books have a subject property, which seems like it should be sufficient. (The property is actually on the type "written work", but all books should have that type as a co-type.)

Book: Feild of study

2008-09-02T17:40:31.0012Z

All books have a subject property, which seems like it should be sufficient. (The property is actually on the type "written work", but all books should have that type as a co-type.)

Publishing: Fair use of academic journal indexes

2008-09-02T15:17:36.0017Z

It would be great to have some serious bibliographic data on academic journal articles. Would it be within copyright law to download biblographic data from a proprietary index and then use a custom script to extract and repackege the data into a freebase friendly form and then to bulk upload the lot?

It seems to me that as long as the information in the index which is uploaded is information that is available freely to be public, this should not be a violation of copyright. Obviously a distinction would have to be made between those indexes which simply provide publically available bibliographic data and those which actually generate content that could be considered proprietary (e.g., an index which provides an abstracting service).

Would any copyright experts care to weigh in on this?

Publishing: Journal article type

2008-09-02T15:04:24.0017Z

There doesn't appear to be a type for journal article. There is journal issue, but this doesn't quite cover it. It would be very useful for academic research to have a journal article type which would be for a specific journal article.

Publishing: Feild of study

2008-09-02T00:16:42.0019Z

Academic books should have a property linking them to a feild of study, e.g., philosophy, psychology, etc.

Book: Feild of study

2008-09-02T00:16:42.0019Z

Academic books should have a property linking them to a feild of study, e.g., philosophy, psychology, etc.

Periodical Publication Date: Issue as machine readable text?

2008-08-21T18:09:07.0005Z

Well this thread got completely lost. I'm going to see about actually getting this done now.

Publishing: Newspaper: Accomodate Weeklies

2008-08-20T22:00:22.0012Z

Take a look here: https://www.freebase.com/view/user/jeff/newspaper and see what you think. I've filled out the San Francisco Chronicle with data in both old and new formats for comparison.

Publishing: Newspaper: Accomodate Weeklies

2008-08-08T17:27:45.0000Z

It could also address local vs. national editions (like the NY Times), which might be interesting to some people. I'll add a task for myself in the old refactoring queue.

Publishing: Newspaper: Accomodate Weeklies

2008-08-07T23:47:38.0012Z

I was thinking something like that, where we combined the fields into one.

And I had no idea there were papers that still did morning/evening editions!

Publishing: Newspaper: Accomodate Weeklies

2008-08-07T22:59:52.0012Z

That would also help modeling papers with morning and evening editions (the Providence Journal-Bulletin had this until very recently).

Publishing: Newspaper: Accomodate Weeklies

2008-08-07T18:54:35.0012Z

Good point. The issue then is how to model things like price and circulation in a way that accomodates weekly papers as well as those that have both daily and sunday editions. We could do a CVT with value, date, and frequency (or maybe call it edition?). Papers with only one edition could optionally leave frequency blank, I suppose. Any other thoughts?

Publishing: Newspaper: Accomodate Weeklies

2008-08-06T18:15:37.0010Z

Can we remove the "daily" specific nature of the Newspaper Type so we can use this for weeklies?

Publishing: Pubmed Article

2008-07-28T21:30:32.0012Z

Thanks !

Publishing: Pubmed Article

2008-07-28T20:33:59.0012Z

For a start, see the help topic Entering Scholarly Works and Citations. The short answer is that an article should have the types Scholarly Work, Written Work, and Published Work. Between these, you should be able to enter most of the properties you mention.

Publishing: Pubmed Article

2008-07-28T19:57:22.0017Z

An article in pubmed ( http://www.ncbi.nlm.nih.gov/pubmed/ ) can be defined by a journal (issn, abbreviation, title) , an issue ( volume, issue, date ) , a title, a pubmed identidier (pmid) , a doi , a list of authors. I'm lost in all those types. Dear Lazyweb, hat are the types that should be used to create a new instance of an article ?

Thanks

Pierre

Publishing: Possible revision for Journal Articles

2008-07-24T23:20:13.0005Z

Spurred on by an aside that spatialed made in some discussion post awhile back (I can't locate the post), I'm considering revising the way that we model journal issues. Currently, each issue has its own topic, which links to both the journal and the articles contained in that issue. (See
http://www.freebase.com/type/schema/book/journal_issue) The main problems with this format are that it is cumbersome to enter data, and also that most bibliographic sources are concerned primarily with the article and the journal, relegating the issue to a series of strings (volume, issue, date). This latter issue might make integration with standard bibliographic schemas a bit cumbersome, although it wouldn't be insurmountable.

As an experiment, though, I thought I'd try to see what a model that eliminated the issue type entirely looked like. Here are the results:
http://sandbox.freebase.com/view/guid/9202a8c04000641f8000000008cd1edd.

I've replaced the issue type with a CVT that connects the article and the journal, and includes the standard bibliographic data of Volume, issue, date, issue date extra, and pages ("issue date extra" is something I had to make up for journals that aren't published on a schedule that translates into mm/dd/yyyy). Journal articles have both Scholarly Work and Written Work as included types, although a journal article can also be a review, editorial, letter or other type of writing.

The only real disadvantage that I see to this is that constructing the contents of a given issue will be harder -- users will have to query on a combination of several fields (volume, issue, etc.) to find what they're looking for.

I'd love to hear what people think about this. If it seems to work, I might do the same thing for newspaper issues.

This is also being discussed on the data-modelers mailing list: http://lists.freebase.com/pipermail/data-modeling/2008-July/000989.html

Publishing: "Genre" as properties of "Book" and "Short Story"

2008-07-22T18:35:33.0007Z

I think that about covers it.

Publishing: "Genre" as properties of "Book" and "Short Story"

2008-07-21T19:57:15.0007Z

It does seem silly that some short stories have "short story" as a genre. Feel free to delete those assertions. Poems have genres, but those are pretty much already handled by the "verse form" propety. Plays have their own genre type. What other types of written works do you think have genres (that aren't already covered by an existing type)?

Publishing: "Genre" as properties of "Book" and "Short Story"

2008-07-17T01:04:29.0012Z

I'm curious why "Genre" is not a property of the type "Written Work" but exists separately under both "Book" and "Short Story" (though not "Poem").

It seems silly that some short stories have the genre of "Short Story", which would make more sense if tagged on the more generic "Written Work" instead.

Written Work: Subjects

2008-07-08T18:59:15.0012Z

"Subjects" is pretty much wide open; do what you will.

Written Work: Subjects

2008-07-08T01:11:25.0005Z

Are the "subjects" of a written work restricted to subjects that are addressed in a non-fictional manner, or can e.g. Octavia Butler's biology-focused SF works have a "subject" of biology?

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.