I’ve checked in a patch that extends and modifies the display
attribute values, as discussed with Bruce. The patch includes
commentary that explains the new values in presentational terms. To
keep things more strictly presentational, I changed the name of "body"
to “right-inline”. Seems like this one is getting close.
The patch view:
http://xbiblio.svn.sourceforge.net/viewvc/xbiblio/csl/schema/branches/split/csl.rnc?r1=1114&r2=1113&pathrev=1114
Frank
We’ve started a planning document for the API to access Frank’s
citeproc-js engine server-side. If you would like to contribute/edit,
please feel free to contact me and to invite others if you already
have access. Many thanks.
Best regards,
Sean Takats
Assistant Professor of History
Director of Research Projects
Center for History and New Media, George Mason University
@Sean_Takats | http://chnm.gmu.edu | 703 993 927
Thanks Sean.
FWIW, I think it’s probably time that we start figuring out a standard
API for this stuff, and this is a good opportunity to do that.
Also, I started a wiki page on trac while back to brainstorm on this.
https://sourceforge.net/apps/trac/xbiblio/wiki/ApiDesign
Bruce
One major (and one more minor) issue that is unclear to me (which I
noted on this doc) is the basic inputs and outputs for the API.
Let’s say such a service allows people to add citations to blog
entries. How would a user encode a citation reference in their post,
what would get sent to the service, and what would get returned?
I still can’t seem to get away from the conclusion that citation
references should be identified by URI. Maybe the answer is as simple
as sending a list of either URIs, or URI + locator tuples? So either:
info:doi:10/1234.r324&page=22
… or:
( “info:doi:10/1234.r324”, { “page”: 22 } )
The practical PITA is not so much the bibliography, but the individual
citation groups.
Bruce
I’ve added some comments to the API doc which might address some
aspect of your question. Moreover, users that want to draw on Zotero-
server-hosted bibliographic data will be able simply to drag
references from the Zotero client into the blog editing pane. The
Zotero client generates a URI. We already have this working with
ScholarPress (scholarpress.org). What you’re proposing is somewhat
different, however, since you’re talking about canonical data. In its
present iteration, the cite.zotero.org service is aimed at formatting
user data, not canonical data. We’re very close to offering something
that will more or less serve as de facto canonical data, and when it’s
available that service will not require any major changes to the
architecture I’ve outlined.
I’ve added some comments to the API doc which might address some
aspect of your question. Moreover, users that want to draw on Zotero-
server-hosted bibliographic data will be able simply to drag
references from the Zotero client into the blog editing pane. The
Zotero client generates a URI. We already have this working with
ScholarPress (scholarpress.org). What you’re proposing is somewhat
different, however, since you’re talking about canonical data. In its
present iteration, the cite.zotero.org service is aimed at formatting
user data, not canonical data.
Yeah, this is what I was worried about 
I think this notion of “canonical vs. user data” may be confusing things.
Why not instead think that there are sources (with identities), and
users simply collect, annotates, etc., those sources. The purpose of
the URI is only to identify the source.
So the question of the source data (what actually gets run through the
service) is a question of thinking in terms of a hierarchy of trusted
sources, where the pinnacle may well be my zotero (or other) user
account, and google scholar may be somewhere down that list.
So, for example if I send the service “info:doi:10/12132.1234” then
the service might be able to know to first look in my user account
(and maybe related groups I subscribe to) for the item with the doi
“10/12132.1234” and then fall back to other options as needed.
Yes, I know, there are all kinds of hairy details, but this is the
only way I see to decouple citations from particular data sources,
which is a big limitation in the current landscape.
We’re very close to offering something
that will more or less serve as de facto canonical data, and when it’s
available that service will not require any major changes to the
architecture I’ve outlined.
OK, good. But while I might be wrong, but I still think the
canonical/user data distinction may obscure the issues here?
Bruce