On Mon, 2006-04-03 at 22:24 -0400, Bruce D'Arcus wrote:
> On Apr 3, 2006, at 9:55 PM, Matt Price wrote:
>
> > Looking over the tasks you laid out ("what needs to be done?") it
> > seems that very little can be accomplished on this front until the
> > database design is finalized. Is the design of this database actually
> > something under the control of the bibliographic project?
>
> It's hosted at my xbib project site.
>
> > Or would it have to be approved by a central committee or even OASIS
> > first?
>
> No, because it has little to do with the file format. That said, I am
> designing it with mapping to/from RDF in mind, which is the likely
> technology ODF will be using for enhanced metadata support in ODF. We
> have tentatively scheduled that for inclusion in an interim release of
> ODF early next year.
hmm. but as I understand it a xml-ized version of a .odt document's
"library" would be saved as part of that document. Are such add-ons
permitted under the .odt spec?
I mainly ask because it seems important that .odt's be openable and
usable by Koffice & whatever other compatible suites exist. But perhaps
this is a misplaced concern.
>
> > On the organization of the bibliographic database:
> > - I see there are no keywords. Is it assumed that keywords will
> > become a kind of note?
>
> Right now, it's covered with the trendy term for the same thing: tags.
>
> > - unlike in refbase or refdb, there seems to be no way to associate a
> > set of references with a user (though notes are associated with
> > users). Is this a design decision?
>
> No, it's not done yet. It seems, however, in our case we can't assume
> multi-user systems, and the more common case will be single-user.
>
absolutely. But if multi-user cases are possible, perhaps that shold be
worked into the data model?
> > - is there any way at all to harmonize this database design effort
> > with one or more of the many FLOSS bibliographic projects? For
> > instance, as I understand it Refbase is considering mivng to a
> > non-flat DB, and I think even RefDB is looking at changing its DB
> > structure (again!). It would be so great to have input and support
> > from projects of that nature...
>
> Anyone is free to contribute, but I don't have the energy to recruit
> support for this, and to worry about accommodating legacy concerns. I
> think Markus (of RefDB) and I, for example, have a different set of
> concerns and priorities that partially reflect the fact that we come
> from different parts of the research world; he a life scientist, and I
> closer to the humanities.
fair enough
>
> My concern is creating a forward-looking design that also will work
> with an RDF serialization. Ideally we'd be able to use some native RDF
> store -- and who knows, that may be possible at some point -- but for
> now it'd be nice to have something we could use with the existing OOo
> RDBMS support.
>
> So probably the approach will be to get it to a stage where we --
> non-experts in database design but who know what we need in a data
> model -- are happy with it, and then to have a database expert or two
> go over it with fine-toothed comb. That would give the best mesh of
> domain knowledge and technical expertise.
>
what do you think about trying to set some road maps for this? So that
for instance if there's a Summer of Code 2006 we can be in a position to
benefit from it?
> > Overall, it seemsto me that a complex and flexible structure of this
> > kind necessitates some further elaboration of record types, so that
> > an OOo bibliographic db, when crated, could never be empty; instead,
> > there would have to be a well-populated set of
> > reference/relation/collection/event types from the get go.
>
> Yes, I agree. It's worth noting that my RDF schema is designed to cover
> just this:
>
> <http://purl.org/net/biblio>
>
> In fact, I just wrote a little script that turns that schema into Ruby
> classes and subclasses :-)
>
> So I'm thinking of trying to harmonize (using your word) the data model
> and the input/output format so that it not only works well for us, but
> also fits with the direction that we are helping to push ODF towards
> (e.g. the initiative comes from others, but I'm encouraging it in ways
> that will help us).
>
your rdf looks excellent. I suppose the trick now would be to translate
your ruby script into python or some otherl anguage that OOo
understands, and/or create a schema to translate from rdf to sql. BUt I
suppose also that the db definition really ought to be finalized
first...
Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
