Zotero metadata format
sieh...@googlemail.com
I was wondering where there is a documentation of the internal
metadata format that Zotero uses, but I could not find any real
documentation. Especially for non native English speakers and if you
do not know SQL, it is difficult to find out all the deatils. I'd like
to show the format to librarians and other experts that are familiar
with metadata but not with technical stuff. A summary of all item
types and fields would be nice, if you include userdata, an UML-like
diagram is probably needed.
I started the wiki page http://dev.zotero.org/zotero_metadata_format
and wrote a perl script that creates a summary of the basic structure
(system.sql):
http://groups.google.com/group/zotero-dev/web/zotero-metadata-format.pl
You can use any localized language, this is in German:
http://groups.google.com/group/zotero-dev/web/zotero-format-de.html
An DocuWiki-export would help to create an updated summary in the
wiki, but first I'll dig into userdata.sql. Probably it's even better
to add the functionality to create an overview of the current metadata
scheme inside Zotero and make it available in the preferences menu.
Greetings,
Jakob
P.S: For contacting me please use my real mail address, I don't want
Google to rule my communication.
Dan Stillman
> I started the wiki page http://dev.zotero.org/zotero_metadata_format
> and wrote a perl script that creates a summary of the basic structure
> (system.sql):
> http://groups.google.com/group/zotero-dev/web/zotero-metadata-format.pl
This is very helpful--thanks. I've moved the page to
http://dev.zotero.org/data_model (which I think is a bit clearer and
more accurate) and linked it from the main page of the dev docs.
Note that the current data model is temporary and limiting, and we hope
to adopt the Bibliographic Ontology (http://bibliontology.com/) as a new
model once it's completed.
> An DocuWiki-export would help to create an updated summary in the
> wiki, but first I'll dig into userdata.sql.
Sounds good. You'll notice that a few of the tables in userdata aren't
actually used.
> Probably it's even better
> to add the functionality to create an overview of the current metadata
> scheme inside Zotero and make it available in the preferences menu.
I don't know that that's really necessary, but it'd be easy enough to
whip up a page that did this using the internal methods and have it be
accessible via a chrome URL. Regardless, having this in the dev docs
will definitely be useful.
sieh...@googlemail.com
> This is very helpful--thanks. I've moved the page tohttp://dev.zotero.org/data_model(which I think is a bit clearer and
> more accurate) and linked it from the main page of the dev docs.
>
> Note that the current data model is temporary and limiting, and we hope
> to adopt the Bibliographic Ontology (http://bibliontology.com/) as a new
> model once it's completed.
Uh, this looks very interesting, but I must urge you too have a look
into MARC and FRBR before finishing such an important specification!
There are probably some clever people from the library world at the
NGC4LIB mailing list that could help. It would be a pitty to have yet
another bibliographic format created independently!
> > An DocuWiki-export would help to create an updated summary in the
> > wiki, but first I'll dig into userdata.sql.
>
> Sounds good. You'll notice that a few of the tables in userdata aren't
> actually used.
I now use the developer XPI which looks somehow ... fluent.
> > Probably it's even better
> > to add the functionality to create an overview of the current metadata
> > scheme inside Zotero and make it available in the preferences menu.
>
> I don't know that that's really necessary, but it'd be easy enough to
> whip up a page that did this using the internal methods and have it be
> accessible via a chrome URL. Regardless, having this in the dev docs
> will definitely be useful.
I need an overview generated from the actual database because we
started a project to use (or evaluate) Zotero for library catalouging
in Germany. We probably need to define new item formats and fields
because library records are more complex and the current formats are
very English-centric (for instance the "bill", "case", "hearing" and
"statute" are just ridiculous if you consider non-US jurisdictions).
I will just post another message about my first experience with
getting started in developement.
Greetings
Jakob
Frederick Giasson
> Uh, this looks very interesting, but I must urge you too have a look
> into MARC and FRBR before finishing such an important specification!
> There are probably some clever people from the library world at the
> NGC4LIB mailing list that could help. It would be a pitty to have yet
> another bibliographic format created independently!
>
We certainly are :) In fact these, and many other initiatives, drove the
development of the bibliographic ontology. However the bibliographic
ontology is not a direct mapping of MARC and is not fully integrating
FRBR, and this, for many reasons. In fact what drives the development of
such an ontology are users. What is special in this domain is that there
is a wide range of users: librarians, book sellers, editors and
publishers, me, etc. Some want to use it to create citations, other to
list their library, other to create a catalog of the books they sell,
and others to locate unique document within an archive.
And all that should be driven by flexibility of extensions and Simplicity.
You can always scan the mailing list and its 800 mails to find all the
discussion we had with these questions and how it relates to other
initiatives and projects.
We are currently listing the pending questions to finish and release the
first draft of the ontology. So you can always check the wiki
(wiki.bibliontology.com) to add things you find important or things you
would want to change.
Thanks!
Take care,
Fred
Bruce D'Arcus
> Uh, this looks very interesting, but I must urge you too have a look
> into MARC and FRBR before finishing such an important specification!
I'm a little bothered by your presumption that we don't know the
existing state of knowledge in this area. Why have you made this
assumption?
MARC is a dinosaur, and I have no interest in being bound by its
traditions. I don't think Zotero should be either. So that you see no
evidence of MARC is a conscious decision.
OTOH, I think FRBR is quite sound, which is why our ontology is
explicitly designed to fit into a FRBR worldview (the primary
bibo:Document class, for example, is a subclass of frbr:Manifestation).
That might not be apparent on first glance, but it's nevertheless true.
I also had some hand in the FRBR RDF vocabulary that we reference.
And, of course, we also reference other widely used vocabularies such as
FOAF, DC, SKOS, and probably SIOC (for some of the stuff Zotero will need).
So there's not a whole lot of what we're doing that isn't building on
existing knowledge; it just doesn't happen to be MARC.
> There are probably some clever people from the library world at the
> NGC4LIB mailing list that could help. It would be a pitty to have yet
> another bibliographic format created independently!
Quite the contrary: this is the point! The library world has shown no
history of creating the kinds of formats we feel we need, and a general
hostility (that is now changing) to RDF and the semantic web.
A fresh take on this is required, and it can't take place within
existing other communities, *particularly* the library world.
But here's the funny thing: I know a few library people who would agree
with me, and at least some of them are on our dev list ;-)
Feel free to join us!
Bruce
Andrew Ashton
history of creating the kinds of formats we feel we need, and a general
hostility (that is now changing) to RDF and the semantic web.
A fresh take on this is required, and it can't take place within
existing other communities, *particularly* the library world.
But here's the funny thing: I know a few library people who would agree
with me, and at least some of them are on our dev list ;-)
Feel free to join us!
Bruce
I'm a librarian and I agree with you that librarians as a group have been *extremely* slow to acknowledge the obsolescence of their favorite ontologies/metadata schemas. And they have been even slower to explore and enact practical answers to some of these questions. However, there are some useful tools that have emerged from the library technology world (MODS, unAPI, OAI-PMH to name a few) and I don't think that wholesale writing off of an entire community of users/developers does any open-source project any good.
Libraries have a huge interest in seeing the technologies that surround projects like Zotero become part of their daily vocabulary. That's our problem that we're struggling with. But I believe that we can still offer some valuable contributions to projects like these - so long as they don't become so rhetorically-charged that we are made to feel unwelcome.
Bruce D'Arcus
> I'm a librarian and I agree with you that librarians as a group have
> been *extremely* slow to acknowledge the obsolescence of their favorite
> ontologies/metadata schemas. And they have been even slower to explore
> and enact practical answers to some of these questions. However, there
> are some useful tools that have emerged from the library technology
> world (MODS, unAPI, OAI-PMH to name a few) and I don't think that
> wholesale writing off of an entire community of users/developers does
> any open-source project any good.
Well, first, don't blame the Zotero project for my rhetoric ;-)
> Libraries have a huge interest in seeing the technologies that surround
> projects like Zotero become part of their daily vocabulary. That's our
> problem that we're struggling with. But I believe that we can still
> offer some valuable contributions to projects like these - so long as
> they don't become so rhetorically-charged that we are made to feel
> unwelcome.
You're of course right; both that librarians can offer "valuable
contributions" and that my rhetoric was a little over-the-top. Mea culpa.
I need to make really clear that I'm not offering some wholesale
critique here, and that perhaps was not so clear in my previous note. I
have learned a lot from library IT and metadata people, perhaps more so
than from anywhere else.
But I do think library standards tend -- perhaps for good reason; I
don't know -- to be a) insular, and b) baroque. MARC is the perfect
symbol of this for me, but I also think MODS/METS/MADS share the same
problems (just in diminished form).
But of course within any community, there is diversity, and unAPI is a
good example where library people like Dan took a different path. I'm
also really thrilled to see alternative approaches like OpenLibrary, and
to be reading Karen Coyle's blog these days!
So please don't read my post to mean that I don't there aren't
librarians doing really good work, nor that I don't value discussion
with them.
But to explain the tone of my response, I get rather frustrated after
hearing for, say, the 100th time: "why are you not just using [insert
"MARC", "BibTeX", etc. depending on where the question is coming from]?"
Bruce
sieh...@googlemail.com
> jakob.v...@gbv.de wrote:
> > Uh, this looks very interesting, but I must urge you too have a look
> > into MARC and FRBR before finishing such an important specification!
>
> I'm a little bothered by your presumption that we don't know the
> existing state of knowledge in this area. Why have you made this
> assumption?
My assumption was that the initiative is mainly driven by computer
scientists and my experience with computer scientist is, that they
frequently ignore research outside their domain and have a very
limited concept of the complexity of bibliographic data. The mistake
that every book has an
ISBN and ISBN uniquely identifies editions is just one example.
(Disclaimer: I am both a library scientists and a computer
scientist ;-)
> MARC is a dinosaur, and I have no interest in being bound by its
> traditions. I don't think Zotero should be either. So that you see no
> evidence of MARC is a conscious decision.
There are even worse dinausaurs in the library world and there are
struggles about different usage of MARC and alternatives. You better
don't want to know this in detail ;-)
> OTOH, I think FRBR is quite sound, which is why our ontology is
> explicitly designed to fit into a FRBR worldview (the primary
> bibo:Document class, for example, is a subclass of frbr:Manifestation).
> That might not be apparent on first glance, but it's nevertheless true.
> I also had some hand in the FRBR RDF vocabulary that we reference.
Oh, that's you, nice to meet you. It's a shame that IFLA still has not
published an official a RDF representation of FRBR. In my opinion FRBR
is a nice example of how good ideas coming out of the library world
are hindered by dinosaurs (people and and institutions). But libraries
are need time, they are build for more then decades! 10 years ago many
librarians were still arguing whether they should take this whole
"Internet" stuff serious or not.
> And, of course, we also reference other widely used vocabularies such as
> FOAF, DC, SKOS, and probably SIOC (for some of the stuff Zotero will need).
> So there's not a whole lot of what we're doing that isn't building on
> existing knowledge; it just doesn't happen to be MARC.
Good to hear this (you probably meant CIDOC)!
> > There are probably some clever people from the library world at the
> > NGC4LIB mailing list that could help. It would be a pitty to have yet
> > another bibliographic format created independently!
>
> Quite the contrary: this is the point! The library world has shown no
> history of creating the kinds of formats we feel we need, and a general
> hostility (that is now changing) to RDF and the semantic web.
On the one hand you are right but on the other I have to confirm your
assumption: The Semantic Web and RDF at was first proposed by TBL is
bullshit. XML-representation of RDF was crap from the beginning,
reasoning and inference is just the zombie of hard AI and most example
ontologies only work in theory. The real world is build of not logics
but very fuzzy (see my Wikimania presentation
http://www.slideshare.net/NCurse/jakob-voss-wikipedia2007/). Most
practical stuff came from outside the core SW community, for instance
Microformats and SKOS.
> But here's the funny thing: I know a few library people who would agree
> with me, and at least some of them are on our dev list ;-)
>
> Feel free to join us!
Thanks! I with there were more of those library people. Most of my
colleagues wish the whole "Web 2.0" stuff and library software would
just be a product they could buy for not to think about it
themselves :-(
P.S: Most of the time I have to spent in explaining what I do or what
happens on the web and how it affects libraries. To come back to the
Bibliographic Ontology: Please document and talk about it as much as
possible! Go to conferences, write papers, explain again etc. People
need time to understand. I will have a look at it and try to explain
my German colleagues (don't underestimate the language barrier!)
Andrew Ashton
P.S: Most of the time I have to spent in explaining what I do or what
happens on the web and how it affects libraries. To come back to the
Bibliographic Ontology: Please document and talk about it as much as
possible! Go to conferences, write papers, explain again etc. People
need time to understand. I will have a look at it and try to explain
my German colleagues (don't underestimate the language barrier!)
If you or your colleagues interested, I have a forthcoming article using Zotero as an example of one way to leverage library metadata (in this case MODS records embedded in RSS). My hope is that it serves as one concrete example of the sorts of services we could be exploring in the short term while we move toward more open SOA models for bib data. Abstract is here: http://www.lib.jmu.edu/org/jwl/volume2_issue1.html </shamelessPlug>
Bruce D'Arcus
>
> On 9 Nov., 15:29, Bruce D'Arcus <bdar...@gmail.com> wrote:
>
> > jakob.v...@gbv.de wrote:
> > > Uh, this looks very interesting, but I must urge you too have a look
> > > into MARC and FRBR before finishing such an important specification!
> >
> > I'm a little bothered by your presumption that we don't know the
> > existing state of knowledge in this area. Why have you made this
> > assumption?
>
> My assumption was that the initiative is mainly driven by computer
> scientists and my experience with computer scientist is, that they
> frequently ignore research outside their domain and have a very
> limited concept of the complexity of bibliographic data. The mistake
> that every book has an
> ISBN and ISBN uniquely identifies editions is just one example.
> (Disclaimer: I am both a library scientists and a computer
> scientist ;-)
Right, fair enough. Fred is a computer scientist with expertise in
RDF, I'm a publishing scholar who understands the domain, so it's a
good balance I think.
...
> > OTOH, I think FRBR is quite sound, which is why our ontology is
> > explicitly designed to fit into a FRBR worldview (the primary
> > bibo:Document class, for example, is a subclass of frbr:Manifestation).
> > That might not be apparent on first glance, but it's nevertheless true.
> > I also had some hand in the FRBR RDF vocabulary that we reference.
>
> Oh, that's you, nice to meet you. It's a shame that IFLA still has not
> published an official a RDF representation of FRBR. In my opinion FRBR
> is a nice example of how good ideas coming out of the library world
> are hindered by dinosaurs (people and and institutions).
A funny story about why we didn't feel comfortable using the
documentation from the IFLA report: the organization was really weird
about licensing. So we just left it out!
> > And, of course, we also reference other widely used vocabularies such as
> > FOAF, DC, SKOS, and probably SIOC (for some of the stuff Zotero will need).
> > So there's not a whole lot of what we're doing that isn't building on
> > existing knowledge; it just doesn't happen to be MARC.
>
> Good to hear this (you probably meant CIDOC)!
No, SiOC, for online communities (which Zotero will be dealing with
soon enough).
> > > There are probably some clever people from the library world at the
> > > NGC4LIB mailing list that could help. It would be a pitty to have yet
> > > another bibliographic format created independently!
> >
> > Quite the contrary: this is the point! The library world has shown no
> > history of creating the kinds of formats we feel we need, and a general
> > hostility (that is now changing) to RDF and the semantic web.
>
> On the one hand you are right but on the other I have to confirm your
> assumption: The Semantic Web and RDF at was first proposed by TBL is
> bullshit. XML-representation of RDF was crap from the beginning,
> reasoning and inference is just the zombie of hard AI and most example
> ontologies only work in theory. The real world is build of not logics
> but very fuzzy (see my Wikimania presentation
> http://www.slideshare.net/NCurse/jakob-voss-wikipedia2007/). Most
> practical stuff came from outside the core SW community, for instance
> Microformats and SKOS.
Have a little faith; what we're all doing here is eminently practical :-)
> > But here's the funny thing: I know a few library people who would agree
> > with me, and at least some of them are on our dev list ;-)
> >
> > Feel free to join us!
>
> Thanks! I with there were more of those library people. Most of my
> colleagues wish the whole "Web 2.0" stuff and library software would
> just be a product they could buy for not to think about it
> themselves :-(
>
> P.S: Most of the time I have to spent in explaining what I do or what
> happens on the web and how it affects libraries. To come back to the
> Bibliographic Ontology: Please document and talk about it as much as
> possible! Go to conferences, write papers, explain again etc.
I'm hoping someone in the group will be able to do this, like Fred.
But I'm a professional scholar whose career is based on publishing
papers and giving conference talks on subjects that have nothing to do
with these.
> People need time to understand. I will have a look at it and try to explain
> my German colleagues (don't underestimate the language barrier!)
Right, though you can of course help localize the ontology ;-)
Bruce
Dan Stillman
> I need an overview generated from the actual database because we
> started a project to use (or evaluate) Zotero for library catalouging
> in Germany. We probably need to define new item formats and fields
> because library records are more complex and the current formats are
> very English-centric (for instance the "bill", "case", "hearing" and
> "statute" are just ridiculous if you consider non-US jurisdictions).
OK, but as you note yourself on the data model page, modifying the types
and fields would basically break future upgrade possibility. It'd be
better to wait for (or help work towards) custom item type
functionality. See the "custom item types" thread from this list
(http://groups.google.com/group/zotero-dev/browse_thread/thread/2a4e376e0bdc9566/281de1d5eaf8703f)
for a proposed solution and some tricky related issues that, given your
project's needs, you might be able to comment on.
The legal types are undoubtedly insufficient, but I don't know if it
makes more sense to deal with those as custom types or to try to extend
the built-in types to handle other legal systems (keeping in mind that
users will eventually be able to hide fields they don't need).
Elena Razlogova
I looked at the new CSL files here:
https://www.zotero.org/trac/ticket/632
And it looks like none of these are set up for citing archival
sources (manuscripts, letters, interviews) or even presentations. I
tried to add these to the existing CSLs, but it doesn't seem to be
possible right now.
CSL schema does include such cs-types as "interview," "manuscript,"
and "personal_communication". At the same time it looks like the
schema doesn't define "recipient," "interviewer," "location in
archive," and "repository" (or whatever you wish to call these in
CSL)--all variables necessary to cite these types correctly. ("Type"
for manuscripts and letters and "Medium" for interviews are also
necessary in some cases).
http://xbiblio.svn.sourceforge.net/viewvc/xbiblio/csl/schema/branches/
csl.rnc?view=markup
Bruce, can you add these variables? A style that only cites books,
articles, and theses is not complete. Even Endnote can do better.
Best,
Elena
Bruce D'Arcus
First issue is, any objection to me splitting the terms and types lists
into separate -- more easily maintained -- schemas?
Moving on ...
I've explained more than once that types are de-emphasized in CSL, and
that the core types -- article, book, and chapter -- serve also as
generic fallbacks.
The reason they are de-emphasized so that formatting can work for
particular types of resources even in the absence of explicit
definitions for them; e.g. so that a formatting engine does not break
when encountering the diversity of sources out there in the wild.
So with that out of the way, clearly the attributes or properties *are*
critical to be able to capture. So let me take one of the styles Julian
posted and see if I can find a better way (if these were in a publicly
accessible repository, I would edit them directly of course, but since
they're not ...).
Let's focus on the chicago note example.
On the citation, I think this is wrong:
<else-if type="chapter book">
<group class="container" prefix=". ">
<text term="in" text-transform="lowercase"/>
<text variable="container-title" font-style="italic"
prefix=" " suffix=","/>
<text variable="collection-title" prefix=" " suffix=","/>
</group>
<text macro="editor-translator-short"/>
<group prefix=" (" suffix=")" delimiter=", ">
<text macro="publisher"/>
<date variable="issued">
<date-part name="year"/>
</date>
</group>
</else-if>
Should only have a type of "chapter"; right?
On the bibliography:
<layout suffix=".">
<text macro="author" suffix="."/>
<choose>
Good: you use a richly defined author macro that applies to all types of
resources.
Bad: is that the ONLY formatting that is so general? What about "title"?
But to solve Elena's examples, I'd suggest we need:
1) a "medium" variable. Already there.
2) I can indeed add "interviewer" and "recipient"
3) Archival documents. Here's two examples from Chicago:
Alvin Johnson, memorandum, 1937, file 36, Horace Kellen Papers, YIYO
Institute, New York.
James Oglethorpe to the Trustees, 13 January 1733, Phillips Collection
of Egmont Manuscripts, 14200:13, University of Georgia Library.
So we've got:
- authors
- probably a plain text description or note (though I would store
"memorandum" as a title ATM)
- a recipient
- dates
- locators
- collection titles
- archive and location.
[Oh, and BTW, there are online archives these days, which will become
increasingly common, so one could imagine URLs too.]
So one could do something simple like this:
<text macro="author" suffix=" "/>
<group>
<text term="to" text-transform="lowercase" suffix=" "/>
<names variable="recipient"/>
</group>
<text macro="title"/> <!-- perhaps here the macro falls back to
"note"? -->
<text macro="date"/>
<text macro="locators"/> <!-- a sloppy short-cut -->
<text macro="collection-title"/>
So we're exploiting macros, and we are not using types.
With the group around recipient, IIRC, the formatting rules would say
the text "to" would only get printed if the recipient variable was
present. Is that your understanding Simon? If yes, we need to document
that in the schema.
As I'm suggesting, the title macro might well contain logic that falls
back to the note if the title is not present (though I'm avoiding media
issues here). If there's no note, nothing gets printed (as in the second
example; unless of course, one encodes that information in the title,
which I often do).
The only thing we're really missing above is the archive and its
location. Unless I'm missing something obvious, I guess we probably do
need to add a couple of variables. I suggest they mirror "publisher" and
"publisher-place". The obvious option is "archive."
But is that too specific? What about those cases where, say, an
individual holds a copy of an item? That might suggest a more generic
"owner" or "holder"? Or maybe that's orthogonal.
4) note to Simon: I'm finding myself confused by the "page" variable. It
sounds awkward for page ranges, and I'm not clear now how cited pages fit.
Bruce
Julian Onions
On the bibliography:
<layout suffix=".">
<text macro="author" suffix="."/>
<choose>
Good: you use a richly defined author macro that applies to all types of
resources.
The reason author is a macro is that its a reuseable type that occurs in different formats. It is nearly always the same across types, and its complex enough to format that its useful to have it separate.
Bad: is that the ONLY formatting that is so general? What about "title"?
Undoubtably others could be macros, and they might well benefit from it. However title is not often a good example. First its not complex - the difference between
<text variable="title"/>
and
<text macro="title"/> is minimal, compared to the author setup.
Second, titles often vary. It may be in italics in a book, but plain in an journal article, it may be surrounded by () or quotes in a book. So you either have a macro with a large if/elseif section or just include the variable with its decoration as appropriate.
The benefits of making it a macro, which have a small disadvantage as you have to scroll around the document to see what its definition contains, are lost.
So we're exploiting macros, and we are not using types.
I've tried formatting without types, but I find its just not possible. book/chapter/journal are pretty much the minimum you can get away with testing. The location and format of the container tends to move around too much. A thesis usually has its own weird rules too, and newspapers and journals like to have dates added onto the end. I think types are here to stay!
Simon Kornblith
> On the citation, I think this is wrong:
>
> <else-if type="chapter book">
> <group class="container" prefix=". ">
> <text term="in" text-transform="lowercase"/>
> <text variable="container-title" font-style="italic"
> prefix=" " suffix=","/>
> <text variable="collection-title" prefix=" "
> suffix=","/>
> </group>
> <text macro="editor-translator-short"/>
> <group prefix=" (" suffix=")" delimiter=", ">
> <text macro="publisher"/>
> <date variable="issued">
> <date-part name="year"/>
> </date>
> </group>
> </else-if>
>
> Should only have a type of "chapter"; right?
I think so. Does this work? It's not supposed to; by default, a
conditional has match="all", and there shouldn't be any item types
with a type of both "chapter" and "book."
[...]
> With the group around recipient, IIRC, the formatting rules would say
> the text "to" would only get printed if the recipient variable was
> present. Is that your understanding Simon? If yes, we need to document
> that in the schema
Yes.
> As I'm suggesting, the title macro might well contain logic that falls
> back to the note if the title is not present (though I'm avoiding
> media
> issues here). If there's no note, nothing gets printed (as in the
> second
> example; unless of course, one encodes that information in the title,
> which I often do).
>
> The only thing we're really missing above is the archive and its
> location. Unless I'm missing something obvious, I guess we probably do
> need to add a couple of variables. I suggest they mirror "publisher"
> and
> "publisher-place". The obvious option is "archive."
>
> But is that too specific? What about those cases where, say, an
> individual holds a copy of an item? That might suggest a more generic
> "owner" or "holder"? Or maybe that's orthogonal.
>
> 4) note to Simon: I'm finding myself confused by the "page"
> variable. It
> sounds awkward for page ranges, and I'm not clear now how cited
> pages fit.
At least in Zotero, the "page" variable includes the entire page range
of a chapter or journal article. While cited pages are locators, this
is the page range that appears in the bibliography. We could use
<locator> and format the citation and bibliography with different page
ranges, but I'm not sure that would be much clearer.
Simon
Bruce D'Arcus
>
> >
> > On the bibliography:
> >
> > <layout suffix=".">
> > <text macro="author" suffix="."/>
> > <choose>
> >
> > Good: you use a richly defined author macro that applies to all types of
> > resources.
>
> The reason author is a macro is that its a reuseable type that occurs in
> different formats. It is nearly always the same across types, and its
> complex enough to format that its useful to have it separate.
I'd so far as to say all styles should have an author macro.
> > Bad: is that the ONLY formatting that is so general? What about "title"?
>
> Undoubtably others could be macros, and they might well benefit from it.
> However title is not often a good example. First its not complex - the
> difference between
> <text variable="title"/>
> and
> <text macro="title"/> is minimal, compared to the author setup.
> Second, titles often vary. It may be in italics in a book, but plain in an
> journal article, it may be surrounded by () or quotes in a book. So you
> either have a macro with a large if/elseif section or just include the
> variable with its decoration as appropriate.
> The benefits of making it a macro, which have a small disadvantage as you
> have to scroll around the document to see what its definition contains, are
> lost.
I'm saying that duplication in general is bad because it leads to
errors, missing definitions, etc., and that in this style there's too
much of it.
It's not a huge thing to worry about now, and we should all be
grateful for your work. But I do suggest you experiment with my
suggestions on any new styles you might try.
> > So we're exploiting macros, and we are not using types.
>
> I've tried formatting without types, but I find its just not possible.
> book/chapter/journal are pretty much the minimum you can get away with
> testing. The location and format of the container tends to move around too
> much. A thesis usually has its own weird rules too, and newspapers and
> journals like to have dates added onto the end. I think types are here to
> stay!
I'm not saying don't use types at all; I'm saying only use them as a
last resort. There's a lot of power in the macros and condfitionals
(say tied to varaibles).
Also, keep in mind the fallbacks. In this style, you have no template
for "article" (the fallback) but you do for the more specific
"article-journal" and so forth.
Bruce
Elena Razlogova
Bruce, many thanks for adding "recipient" and "interviewer"
>> With the group around recipient, IIRC, the formatting rules would say
>> the text "to" would only get printed if the recipient variable was
>> present. Is that your understanding Simon? If yes, we need to
>> document
>> that in the schema
>
> Yes.
a similar rule should apply to interviewer--the result should print
", interview by " only if interviewer is present
However, if there is no interviewer, the citation should still say
"interview," i.e. if interviewer is known:
Hunt, Horace [pseud.]. 1976. Interview by Ronald Schatz. Tape
recording. May 16. Pennsylvania Historical and Museum Commission,
Harrisburg.
if interviewer is not known (which happens often enough):
Hunt, Horace [pseud.]. 1976. Interview. Tape recording. May 16.
Pennsylvania Historical and Museum Commission, Harrisburg.
One way this can be done without using the "interview" type is to add
"interview with" and set ", interview" to appear only if "interview
with" is present, and " by" only if "interviewer" is present.
But perhaps there is an easier way to do this.
>> As I'm suggesting, the title macro might well contain logic that
>> falls
>> back to the note if the title is not present (though I'm avoiding
>> media
>> issues here). If there's no note, nothing gets printed (as in the
>> second
>> example; unless of course, one encodes that information in the title,
>> which I often do).
Bruce--if you include this information in the title, wouldn't it come
out in quotation marks in the citation (which would be incorrect)?
In many cases, both the title and "note" need to be included, i.e. if
no title:
Alvin Johnson, memorandum, 1937, file 36, Horace Kallen Papers, YIVO
Institute, New York.
If with title:
Alvin Johnson, "Whatever Title," memorandum, 1937, file 36, Horace
Kallen Papers, YIVO Institute, New York.
So ideally in CSL, "note" would follow "title" if the title exists,
and still be present if the title field is empty.
Simon--did you just map Zotero "extra" field to "note"? In this case
Zotero manusciript "type" field needs to be mapped to CSL "note"--
this may need to be resolved for correct formatting. I believe
"extra" was mapped to "note" to create annotated bibliographies--this
is not going to work if you use "note" for descriptions of
manuscripts--would a dedicated CSL attribute such as "description"
make more sense? (or another dedicated attribute for the "extra" field)
>> The only thing we're really missing above is the archive and its
>> location.
Would you need to define a specific "locator" for archives to display
box numbers, etc. (especially if you don't want to use cs-types to
define this? I may be missing something--but I couldn't find anything
specific enough in this markup, to map Zotero "location in archive"
field:
## Locators
157 cs-terms.locator =
158 "book"
159 | "chapter"
160 | "column"
161 | "figure"
162 | "folio"
163 | "issue"
164 | "line"
165 | "note"
166 | "opus"
167 | "page"
168 | "paragraph"
169 | "part"
170 | "section"
171 | "volume"
172 | "verse"
>> Unless I'm missing something obvious, I guess we probably do
>> need to add a couple of variables. I suggest they mirror "publisher"
>> and
>> "publisher-place". The obvious option is "archive."
Yes
>> But is that too specific? What about those cases where, say, an
>> individual holds a copy of an item? That might suggest a more generic
>> "owner" or "holder"? Or maybe that's orthogonal.
The easiest solution I think would be to put "manuscript in author's
possession" or "manuscript in possession of John Doe" into "note" and
leave "archive" for depositories.
Elena
Bruce D'Arcus
> Bruce and Simon--
>
> Bruce, many thanks for adding "recipient" and "interviewer"
>
>>> With the group around recipient, IIRC, the formatting rules would say
>>> the text "to" would only get printed if the recipient variable was
>>> present. Is that your understanding Simon? If yes, we need to document
>>> that in the schema
>>
>> Yes.
>
> a similar rule should apply to interviewer--the result should print ",
> interview by " only if interviewer is present
>
> However, if there is no interviewer, the citation should still say
> "interview," i.e. if interviewer is known:
>
> Hunt, Horace [pseud.]. 1976. Interview by Ronald Schatz. Tape recording.
> May 16. Pennsylvania Historical and Museum Commission, Harrisburg.
>
> if interviewer is not known (which happens often enough):
>
> Hunt, Horace [pseud.]. 1976. Interview. Tape recording. May 16.
> Pennsylvania Historical and Museum Commission, Harrisburg.
>
> One way this can be done without using the "interview" type is to add
> "interview with" and set ", interview" to appear only if "interview
> with" is present, and " by" only if "interviewer" is present.
>
> But perhaps there is an easier way to do this.
Maybe.
>>> As I'm suggesting, the title macro might well contain logic that falls
>>> back to the note if the title is not present (though I'm avoiding
>>> media
>>> issues here). If there's no note, nothing gets printed (as in the
>>> second
>>> example; unless of course, one encodes that information in the title,
>>> which I often do).
>
> Bruce--if you include this information in the title, wouldn't it come
> out in quotation marks in the citation (which would be incorrect)?
No. If there's no template for interview, the processor would fallback
to the formatting rules for a "book."
> In many cases, both the title and "note" need to be included, i.e. if no
> title:
>
> Alvin Johnson, memorandum, 1937, file 36, Horace Kallen Papers, YIVO
> Institute, New York.
>
> If with title:
>
> Alvin Johnson, "Whatever Title," memorandum, 1937, file 36, Horace
> Kallen Papers, YIVO Institute, New York.
>
> So ideally in CSL, "note" would follow "title" if the title exists, and
> still be present if the title field is empty.
Right, which is even easier.
> Simon--did you just map Zotero "extra" field to "note"? In this case
> Zotero manusciript "type" field needs to be mapped to CSL "note"--this
> may need to be resolved for correct formatting. I believe "extra" was
> mapped to "note" to create annotated bibliographies--this is not going
> to work if you use "note" for descriptions of manuscripts--would a
> dedicated CSL attribute such as "description" make more sense? (or
> another dedicated attribute for the "extra" field)
I'm not going to add "extra" to CSL, unless someone acn explain to me
what it means, and how it's different than "note" (not "annote").
>>> The only thing we're really missing above is the archive and its
>>> location.
>
> Would you need to define a specific "locator" for archives to display
> box numbers, etc. (especially if you don't want to use cs-types to
> define this?
Right now, we are presuming "box", "folder", etc., etc. would not get
encoded in a structured way, but would be a simple string. For that
reason, I'm not sure we need a dedicated locator term?
Note: I'm honestly not clear why we have the whole list below. I think
Simon added those, and am not sure why.
That's fine with me.
Bruce
Elena Razlogova
> I'm not going to add "extra" to CSL, unless someone acn explain to
> me what it means, and how it's different than "note" (not "annote").
It looks like simon mapped Zotero "type" to CSL "genre" which will do
just fine.
>>>> The only thing we're really missing above is the archive and its
>>>> location.
>> Would you need to define a specific "locator" for archives to
>> display box numbers, etc. (especially if you don't want to use cs-
>> types to define this?
>
> Right now, we are presuming "box", "folder", etc., etc. would not
> get encoded in a structured way, but would be a simple string. For
> that reason, I'm not sure we need a dedicated locator term?
Yes, it is a string in Zotero field "location in archive," which
right now is not mapped to anything, and the default locatorType is
"page." It doesn't look like I can use "location in archive" in the
citation if there is no matching attribute in CSL. It does need to be
placed after the date and before the archive.
>>>> Unless I'm missing something obvious, I guess we probably do
>>>> need to add a couple of variables. I suggest they mirror
>>>> "publisher"
>>>> and
>>>> "publisher-place". The obvious option is "archive."
>> Yes
Could you add "archive" as an attribute?
Thank you,
Elena
Rob Hudson
Does CSL provide an annotation field in which I can write notes about
a source in such a way that Zotero can display the field in
bibliography output?
I understand that the changes I made to cite.js are non-standard, but
the need to create annotated bibs surely can't be isolated to just me.
I don't want to have to buy Endnote solely for the annotated bib
feature.
To recap: I tried using the "annote" variable to pull the contents of
my Zotero note, which didn't work. I then made a change to the mapping
in cite.js and used the "extra" field in Zotero to populate my
bibliography with an annotation.
Rob
Bruce D'Arcus
Rob Hudson wrote:
> To recap: I tried using the "annote" variable to pull the contents of
> my Zotero note, which didn't work. I then made a change to the mapping
> in cite.js and used the "extra" field in Zotero to populate my
> bibliography with an annotation.
To repeat for the third or fourth time: Zotero cannot yet map notes to
*any* CSL variable.
You're just going to have to be patient.
If you REALLY cannot wait, then you might consider trying some hack like:
1) export notes with report feature
2) generate bibliography using the style you want
3) write a script or XSLT to swap the output of 2 for the summary in 1
Note: I don't know if even this is possible (to script Zotero in this
way), and to me it'd be a waste of time, but it's the only thing I can
think of.
Bruce
Elena Razlogova
Zotero "extra" is now mapped to CSL "note," so if you use "note" to
place whatever text you have in the "extra" field it should work in
the Zotero dev version.
elena
Rob Hudson
issue has been addressed.
I'm sorry if I seem repetitive, but I have trouble determining exactly
who is who, and who does what.
Can someone point me to a list of people who commonly post on the dev
list and how they are related to Zotero?
I'm an annoying PhD student who uses Zotero for reference management
in my Healthcare Communications, User Manuals, and Foundations of
Technical Communication class. I'm also a former software developer,
which can often get in the way of my questions.
--
Rob Hudson
PhD Student, Technical Comm. and Rhetoric
Composition Assessment Software Developer
Texas Tech University
www.iteachwriting.com
Rob Hudson
me a sample csl entry that will pull the note or extra field from
Zotero? I'm a little confused.
--