Sorry, but it seems I've been unsubscribed from the list for the past
few days (long story). Anyway, to reply to Martha's questions (which I
got from the archive):
Thanks much for the update! I had been wondering and within a
heartbeat
of dropping the project,
As were David and I!
but this encouragement is keeping me active.
Ditto.
How do you think RSS will impact the user interface? For example, a
section in one of the links you provided indicates that RSS could
impact
the search and retrieval functionality:
A few points:
1) While the Nature and Ingenta people are making their bib metadata
available as RSS/RDF, I'm not necessarily saying that's exactly how we
would do it. Indeed, while Ingenta itself is moving to an RDF backend,
I doubt they're actually storing their metadata as RSS.
I will be having a conference call in early October about these issues
with the Nature group, and with Leigh Dodds at Ingenta and a guy who's
working with BioMed Central. I think part of that call will be
figuring out a way to standardize this stuff more.
2) It probably would not impact the GUI at all. It'd really just be a
slightly different way to transport data. Whether we're dealing with
RDF (say something like PRISM + DC) or plain XML (a la MODS) we still
need to figure out similar issues.
I will say that there is one caveat to the above, which is that I've
been advising on the recently-released RDF ontology for the FRBR. If
we decided on adopting some of that, more complex, structure, then that
could have GUI consequences. For example, let's say you want to store
two things: the 1980 edition of Marx's Capital, Volume 1, and the
original 1866 (these dates are made up; I don't remember them!). If
you were to base a GUI on a more PRISM+DC (or indeed MODS) view of the
world, you'd have two separate records, with the possibility to link
them (to say one is the original of the other). You would duplicate a
lot of data in that approach.
In an FRBR-inspired view, both the original and the later English
language edition would be two different expressions of the same work.
That would suggest a different kind of GUI.
The OCLC has done some protoyping with this, BTW (google for
FictionFinder).
One barrier to do a more FBRR interface may well be that the vast
amount of infrastructure -- technical and otherwise -- is built around
an older (more limited) view of bib metadata. For example, if you
search the LoC catalog with its web services, you cannot query for
"works". You basically query for frbr manifestations (two levels below
the work!).
Any comments? And given the issues for implementation, is the intended
functionality stable enough to move ahead with some UI design?
I think there's a lot to do, and that we know enough to do a chunk of
that.
I think we need to figure out how the basic pieces would fit together.
For example, if we say we're moving to a plug-in, what GUI details are
OOoBib specific, and what for third-parties?
In any case we'll need a good (better) interface for citation handling.
So we need to redesign the mechanism that allows users to insert and
edit citations.
I think we also ought to rethink the design for the bibliographic
insertion and formatting in lieu of citeproc and csl. I will press on
the OpenDocument TC on my end on this to see if we can get a commitment
at the file format level that they'll support the CSL style language in
particular. Once we get that commitment, it becomes easier to be
confident that that'll in OOo itself.
I'm of the opinion formatting should remain more firmly a part of OOo,
in other words. It makes it much easier for third-party developers,
and ensure openness and consistency in OOo (and indeed beyond, because
defined as part of the OD file format!).
One open question is about the record entry and editing GUI. It needs
to be completely redone, but the question is, should it be our
responsibility, or should we leave that to third-parties? If the
latter, should we provide a default (at least if we get programmers
willing to do code it)?
Bruce
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
