On Mar 11, 2008, at 7:22 AM, Bruce D'Arcus wrote:
> Daniel Cohen wrote:
>> It might help me respond better if in the
>> meantime everyone can ask some more specific questions that I might
>> be
>> able to answer--i.e., about whether particular functionality will be
>> included, will that functionality exist on the client or server, etc.
>> Or provide hypotheticals or use cases.
> Well, I was asking you to document *your* "hypotheticals or use
> cases."
> I know about some of them, but I think it's fair to say this project
> remains thin on details. I don't really know how you can develop the
> sort of (developer, in particular) community I'm sure you'd like to
> develop if you aren't more open about plans so that people can see how
> they fit within them (or not).
A brief overview that might be helpful. When you look at our plans for
the server (feeds, groups, APIs, etc) you realize that almost all of
the heavy lifting is in getting all of the clients synched to the
server. Once that's done, we can, e.g., export in whatever formats
(RSS, Atom, SWORD, whatever) the community thinks would be most
helpful. I suspect given that it was helpful for the client to provide
multiple in/out methods, the server will be similar, but we're open to
suggestions/discussion over the right forms for this.
The sync is no small feat. Dan and the dev team have been working on
it for months, doing a number of different tests that, while it might
seem like smoke filled back-room dealing, really is just to make sure
we don't release something that's not ready for prime time (think of
the scale of all of the transactions the server will deal with) and
has lots of people pounding away at it while Dan et al are working on
it. A couple of quick notes: 1) re: standards like Atom for the sync:
besides being problematically much more verbose than we would like
(we're instead using a tight XML transmission), the sync is more about
a diff and really needs the client and server on each side (note the
potential for problems, e.g., if a deletion occurs on either side); 2)
remember that a good bit of the server will, in effect, reside in the
client (i.e., a communications/sync layer), and so that can be
hijacked/reused by other developers. This will open up the possibility
for better plugins, two-way syncs to other services, etc.
> My use cases?
> 1) Just as I can easily add a link roll from delicious or magnolia
> to a
> weblog or site, I'd like to do the same with items in Zotero (as I
> think
> about it, a citation is just a special kind of "link" or "bookmark"
> after all).
You can do this now with the client's contextual drag and drop, or
with a plugin that uses the client API. But you'll also be able to
pull citations from the server for reuse elsewhere.
> 2) I'm not sure about this yet, but I might like to be able to
> integrate
> (public) notes as well into something like a tumbelog
Again, doable in multiple ways.
> 3) To be able to integrate full citation processing into any web
> application.
This would be nice. But probably a big side project that should
involve Simon and a few others. We have been contacted by Adobe
Buzzword, among others, so maybe a working group could be put together.
> 4) every user has a profile page that can also incorporate some of the
> above, as well as their publications; sort of like a dynamic CV, and
> accessible as FOAF data
> http://zotero.org/user/doej
Yes, in the plan. We're also exploring the possibility of additionally
using another group's dedicated web app for the CV functionality
(i.e., universities could deploy a dedicated dynamic CV app for their
faculty and students).
> All of the above are really about the data and API story, of course.
> #1
> could be easily implemented even with feeds (I'd vote Atom and//or RSS
> 1.0), as perhaps could #2. #3 is a little more tricky.
> But I'm hoping these kind of web-oriented use cases are guiding the
> design.
> Zotero 1.0 was about pulling the web into the desktop. I'd like for
> Zotero 2.0 to be about pulling the desktop back out onto the web.
> Moreover, ANY feature or improvement that gets added should be
> consistent with this goal. So, for example, 1980s-era rich text is out
> unless it can be made to work with 21st century web standards and best
> practices (e.g. @rel and @class at minimum).
Agreed.
> On the details, I'm also unclear on the place of technology like:
> - identity and authentication (will Zotero 2.0 support openid?)
OpenID, yes. We're looking at authentication but have promised
plugable auth to our funders.
> - search (SPARQL? OpenSearch? both?)
Not sure yet; open to suggestions.
> - Dan S. mentioned exposing RDF; handled via content-negotiation?
We saw RDF as another feed type; maybe you can explain further what
you're looking for here.
> That's all for now.
> Bruce
> PS - I was looking again at Open Library. It's pretty damned cool
> that I
> can add/edit data about me and my book there! I've mentioned this
> before, but I think Zotero 2.0 ought to learn from OL. They've also
> got
> a full open source technology stack underneath of course.
As part of the Zotero-IA partnership we plan to do a tight integration
with OL (indeed, beginning next week). So that will be another way for
people in import/export/change data.
