Possible revision for Journal Articles

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.

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).

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

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

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.

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.

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.

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?

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.