A need for the author/originator/creator/etc properties and co-types is something that can import/export to common bibliographic software libraries. Also, the properties of that/those schema need to link to as many of the established Freebase topics and schema as possible. For example, author would need to point to authorship either directly or indirectly so that author topics contain lists of their written works as a single list. <br>
<br>For example, in my field an edited book is considered to be authored by the editors, and the chapters in the book are considered to be authored by the people who wrote them in the book that was authored by the editor. The bibliographic schema therefore need to maintain both kinds of authorship separately but similarly (if that makes sense) so that a citation can be formatted as something like: <br>
<br>Doe, J. 2008. Freebase authorship. In J. Smith and S. Jones. Freebase Publication Schema. Cook Publishing. San Francisco, CA <br><br>OR<br><br>Smith, J. and S. Jones. 2008. Freebase Publication Schema. Cook Publishing. San Francisco, CA<br>
<br>A list of published works in the John Doe topic would therefore need to contain the chapter details with links that allow various bibliographic formats of the chapter in the book. Lists of published works by John Smith and Steve Jones need to contain book details with links to chapters and chapter authors. However, books not comprised of edited chapters would not need to contain links to chapters.<br>
<br>This is but one wacky example of the way that authorship needs to be represented. So, while Freebase will likely store publication data and links in a different structure than existing ones that have gone through decades of R&D and are compatible (e.g., EndNote, RefWorks, Procite), it will be very important to consider those existing schema if Freebase is to be similarly compatible as well as complement and expand on them.<br>
<br>-Ed<br><br><br><br><div class="gmail_quote">On Tue, Mar 4, 2008 at 7:27 PM, Jeff Prucher <<a href="mailto:jeff@metaweb.com">jeff@metaweb.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
One more thing to consider is that a book of artworks by a single artist<br>
will usually be cataloged under the artist's name, and may not have an<br>
additional editor. The artist should be credited as the "author" (or<br>
whatever) of the book, but calling them a writer makes even less sense then<br>
calling an editor a writer. Both the suggested terms "creator" and<br>
"originator" (plus my half-joking "creator of a written or published work")<br>
do cover this case as well, which is good -- at least we're on the right<br>
track.<br>
<br>
I agree that we're looking for something fairly generic in a name. But I<br>
feel like terms like "creator" and "originator" are too generic. Saying that<br>
the topic "Toni Morrison" is of the type "author" has some semantic meaning<br>
(at least, I think it does); saying that she's a "creator" doesn't convey<br>
much at all, since there's no inherent idea of what sort of thing(s) she's a<br>
creator (or originator) of. And for visual artists who have had monographs<br>
published, it might be doubly confusing, since they are also creators of<br>
their artworks.<br>
<br>
This may be neither here nor there, but most editors (of the compiler<br>
variety, and possibly of the reference book creator) are probably also going<br>
to be writers, if not of books, then of a preface, afterword, essay, etc.<br>
That is probably less true of the artists with monographs, however.<br>
<br>
I'm still leaning toward "author", if only because I think people are used<br>
to conflating a variety of roles under that term in order to find things in<br>
card catalogs.<br>
<br>
All that said, the name is the easiest thing to change on a type, so<br>
whatever we decide on can be changed if it doesn't work out or a better idea<br>
is suggested.<br>
<div class="Ih2E3d"><br>
Jeff Prucher<br>
<br>
<br>
> -----Original Message-----<br>
> From: <a href="mailto:data-modeling-bounces@freebase.com">data-modeling-bounces@freebase.com</a><br>
</div><div><div></div><div class="Wj3C7c">> [mailto:<a href="mailto:data-modeling-bounces@freebase.com">data-modeling-bounces@freebase.com</a>] On Behalf Of Tom Morris<br>
> Sent: Monday, March 03, 2008 8:21 PM<br>
> To: Freebase data modeling mailing list<br>
> Subject: Re: [Data-modeling] Upcoming schema changes<br>
><br>
> I was thinking of the same type of editor as you, not an<br>
> acquisitions editor or copy editor or any other type of<br>
> editor. "Author" is better than "writer," but still, to my<br>
> mind, implies the creation of texts as opposed to the<br>
> selection and arrangement of texts. Unfortunately, the only<br>
> alternative to "author" that I can think of is "contributor."<br>
> I think part of the problem is that they're fundamentally<br>
> different roles, so any term that covers both tasks is going<br>
> to be extremely generic.<br>
><br>
> Tom<br>
><br>
> On Mon, Mar 3, 2008 at 7:02 PM, Jeff Prucher <<a href="mailto:jeff@metaweb.com">jeff@metaweb.com</a>> wrote:<br>
> > It just occurred to me that part of the issue here might be<br>
> due to the<br>
> > ambiguity of the term "editor". The "book editor" type, and<br>
> > corresponding "editor" property on the book type that I want to<br>
> > eliminate/merge with "author" is meant to refer to editors of<br>
> > anthologies, collections, reference works, and other similar<br>
> > collaborative efforts. It is not meant to refer to the acquiring<br>
> > editor of a book (which would really have to be modeled at<br>
> the book edition level, anyway, since they're tied to a publisher).<br>
> ><br>
> > I'd like to move forward with this change, so I'd like to hear if<br>
> > anyone has any responses to my suggestion to name the basic type<br>
> > "author" (rather than writer), or any other suggestions<br>
> for what to call it.<br>
> ><br>
> > Thanks,<br>
> > Jeff Prucher<br>
> ><br>
> ><br>
> > > -----Original Message-----<br>
> > > From: <a href="mailto:data-modeling-bounces@freebase.com">data-modeling-bounces@freebase.com</a><br>
> ><br>
> ><br>
> > > [mailto:<a href="mailto:data-modeling-bounces@freebase.com">data-modeling-bounces@freebase.com</a>] On Behalf Of Jeff<br>
> > > Prucher<br>
> > > Sent: Wednesday, February 27, 2008 11:16 AM > To:<br>
> 'Freebase data<br>
> > modeling mailing list'<br>
> > > Subject: Re: [Data-modeling] Upcoming schema changes ><br>
> > Part of<br>
> > the impetus to merge the author and editor types is > that<br>
> most data<br>
> > sources for bibliographic information don't > distinguish between<br>
> > author and editor at the property level, > although some make the<br>
> > distinction with a sub-field or > additional code.<br>
> Anthologies aren't<br>
> > written, but they can > usually be found by querying the compiling<br>
> > editors' names > against the author (or equivalent) field<br>
> in, say, a<br>
> > card > catalog or online bookstore. So when we import data from ><br>
> > other sources, and we plan to import quite a lot, we start<br>
> to > run<br>
> > into trouble if we have to make a decision about whether ><br>
> to stick<br>
> > the creator in the "author" or "editor" field (under > the old<br>
> > schema) if our data source does not make that ><br>
> distinction. Whereas,<br>
> > by combining them, we can at least > assert their "authorship" (or<br>
> > whatever term we decide on), > and can omit the specific role<br>
> > (author, editor, etc.) in > cases where it's ambiguous or unknown.<br>
> > ><br>
> > > I wonder if the name "author" might be better than "writer"<br>
> > > for the general type, since people seem pretty used to ><br>
> > conflating the notions of author and editor already -- not<br>
> in > terms<br>
> > of the actual roles involved in producing a written or > published<br>
> > work, but in how they think about finding such a work.<br>
> > ><br>
> > > Jeff<br>
> > ><br>
> > ><br>
> > > > -----Original Message-----<br>
> > > > From: <a href="mailto:data-modeling-bounces@freebase.com">data-modeling-bounces@freebase.com</a><br>
> > > > [mailto:<a href="mailto:data-modeling-bounces@freebase.com">data-modeling-bounces@freebase.com</a>] On Behalf Of Micah<br>
> > Saul > > Sent: Tuesday, February 26, 2008 4:58 PM > > To:<br>
> Freebase<br>
> > data modeling mailing list > > Subject: Re:<br>
> [Data-modeling] Upcoming<br>
> > schema changes > > > > I agree completely with these remarks.<br>
> > > ><br>
> > > > Writer = poet, author, essayist, etc.<br>
> > > > Writer != editor<br>
> > > ><br>
> > > > I admit I have not looked at the publishing domain at all, so<br>
> > this > > question may be obvious, but what do we gain by making ><br>
> > these changes?<br>
> > > > How redundant are the properties of, say, "author" and<br>
> "editor"?<br>
> > > ><br>
> > > > On Feb 26, 2008, at 4:41 PM, Tom Morris wrote:<br>
> > > ><br>
> > > > > On Mon, Feb 25, 2008 at 10:17 PM, Bryan Cheung > > ><br>
> > <<a href="mailto:bryan.cheung@metaweb.com">bryan.cheung@metaweb.com</a> > > > > wrote:<br>
> > > > ><br>
> > > > >> The type "writer" will replace the > > >> types "author,"<br>
> > "editor," "poet," "reviewer," and "interviewer"; > > > ><br>
> > > I'd be<br>
> > willing accept that a "poet" and an "author" are > > both<br>
> examples ><br>
> > > > of a "writer," but an "editor" is a different beast ><br>
> altogether.<br>
> > If > > > you really want a term that will cover all of<br>
> these roles,<br>
> > > > it needs to > > > be something more generic like<br>
> "contributor."<br>
> > Of course, the more > > > generic you make it, the less useful it<br>
> > becomes (not just > the name, > > > but the number of roles it<br>
> > covers).<br>
> > > > ><br>
> > > > > Tom<br>
> > > > > _______________________________________________<br>
> > > > > Data-modeling mailing list<br>
> > > > > <a href="mailto:Data-modeling@freebase.com">Data-modeling@freebase.com</a><br>
> > > > > <a href="http://lists.freebase.com/mailman/listinfo/data-modeling" target="_blank">http://lists.freebase.com/mailman/listinfo/data-modeling</a><br>
> > > ><br><br></div></div></blockquote></div><br>