Okay, I just want to make sure I'm on the same page: As a user, I will be able to enter footnote, endnote, or inline citations as I type. When I enter one of these citations, I can either select a work from a database I have access to, or I can enter the work myself. When I cite from this work again, I can easily select the same work and simply change the page (or whatever) cited.
Because these citations are dynamic, "Ibid.", first citation, and such will be handled automatically. I may also add my own text to the citations without confounding the system. At the end of the paper, essay, article, dissertation, or whatever, I can generate a bibliography or "works cited" page that will include one entry for each unique work that I cited, as well as uncited works that I wish to have in the bibliography. This bibliography can be updated as I continue to revise the document. Is this effectively how the user experience is supposed to work? The rest of what we are trying to do is allow users to grab all of their bibliographic data from existing databases, right? -Dane On 9/28/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Hi Bruce, > > My work on this was back in the late '80s, so I am writing this from old > memories. In 1988 at OCLC I defined my DIADEM project (Design of > Interfaces And Databases for Electronic Media), looking out about eight > years to when I expected anyone with a desktop computer to be able to > search, retrieve and see/hear the contents of any type of document owned > by a library. > > I put my team to work using an object-oriented environment because it > was the only thing that made sense for the future we were predicting > (first on the Mac in Hypercard for the prototype, then in X11R2). We > worked out a complete tree in SGML (because HTML did not yet exist) that > defined a DTD for the data and metadata of any type of multi-media > document a library could own -- we had to be able to handle all of it in > our database and then put in on the screen (a Sun SPARCstation) so that > the representation was as good as the printed document. Thus two of our > biggest problems were how to handle analytics and non-text > storage/retrieval/integration/display -- because our displayed pages > (missing only about an inch at the bottom that had to scroll) were as > good as the color pages in print chemistry journals while storing each > full-color chemistry graphic in only a 150K file (obviously the team > programmers had to define all our own compression and storage algorithms > -- this was in the 1980s!). Even then we were looking at Terrabytes for > a full system database by the year 2000. > > The key issue for work vs. manifestation is content vs. container -- > content always must be in a container to have a physical existence in > the real world! In addition, the definition of a work is subjective, > esoteric and controversial-- if I do a softcover, a hardcover, and > audiobooks on both tapes and CSs, then I must assign four ISBNs to the > one work-- but another person and I may differ on whether another book I > write with almost the same content but targeted to a slightly different > audience (e.g., college vs. corporate) is a different work or a derivative. > > Also, what about an edited book that contains a preface and summary by > the editor and 10 other chapters by different authors? Is the book the > editor's work that also contains the works of other authors? The > problem is even more complex when multi-media content is added to the > database -- what is the "work" for a song? -- the lyric, the melody, the > arrangement, some combination of them, etc. > > My team iterated through all three standard methods of container > representation for the database but none of them would support all the > functionality we needed in the GUI. Thus our fourth iteration defined > the fundamental object as simply a list of pointers to other objects -- > for example, I found some research that determined there are only 14 > ways documents can relate, so we used those relationships to take care > of analytics and all the other types of container-relationship > problems. Our focus was search/retrieval/display, so we were not > focused on how the user would input documents -- we first had to solve > the very difficult representation and output problems before we tackled > how a user rather than a librarian would add to the database. For > example, an analytic such as a chapter or journal article may have to be > associated with table of contents on many different levels (e.g., > journal volume, issue, internal to the article). > > I believe typical GUI users should never see the inner workings of the > database -- they only need to select what they want to input and then > the code takes care of how it is put into the database -- although users > should be able to import information directly into the database. Thus I > strongly believe we should treat any and all standard database/document > representations out there as import issues and do whatever we think is > best to support the users internally!! In addition, if we treat the > database as import issues, then the design will inherently be set up to > handle new standards created in the future. > > Thus the definition of "work" could be resolved in OOoBib as a > user-defined "cluster" of containers. I think the issue of "work" is so > inherently problematic that any standard that might come into existence > for "work" would mean that OOoBib would have to put in some way of > importing it into however we define a "cluster". > > As you can tell, my experience with DIADEM was as focused on database > design as it was user interfaces -- which is why my OOoBib UI > architectural document seemed so abstract to people expecting details > about the user interface -- no way can the UI be designed separately > from the database issues!!!!! > > Regards, > Martha > > > Bruce D'Arcus wrote: > > > On Sep 27, 2005, at 11:19 PM, [EMAIL PROTECTED] wrote: > > > >> For example, I am very familiar with the work approach, having > >> considered that for a database when I was an OCLC research > >> scientist. Your email really helped, but I still have such a sense > >> of being in the dark about included functionality -- > > > > > > Am still trying to get more info. It's a help that I am in contact > > with four engineers at Sun (three of whom are on the OpenDocument > > Technical Committee, one of them the chair of it), where they are now > > mostly initiating the conversations :-) > > > > Let's talk about FRBR. My worry about this model is actually > > precisely about the GUI, so perhaps you have some thoughts on that? > > > > In my experiments at the low-level RDF coding level, the complexity > > came in particular with analyticals, and linking from them to the > > proper levels of their hosts. Let's take an article, where the > > structure may be: > > > > Work > > expression > > type: Text > > language: english > > title: Whatever > > manifestation: > > type: Article > > volume: 2 > > issue: 1 > > pages: 23-45 > > isPartOf --> X (the journal; probably it's manifestation) > > > > Consider too that when you cite, you are citing pretty much at the > > manifestation level, rather than the work, in part because if you add > > page numbers, they only apply to a single manifestation. > > > > So as a GUI designer, how would you assess the trade-offs? The > > alternative is to flatten it. > > > > Bruce > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
