Re: Storage locations again
Daniel O'Donnell <[email protected]> Mon, 22 Jan 2007 05:24:16 -0700
| Newsgroups | gmane.text.refdb.devel |
|---|---|
| Organization | University of Lethbridge |
| Message-ID | <1169468656.5659.5.camel@caedmon> |
On Mon, 2007-01-22 at 11:28 +0100, Markus Hoenicka wrote: > Daniel O'Donnell <[email protected]> was heard to say: > > > Looking of the Reference Manager Spec, I'd say it looks like the L > > series is what we want, though I'm not sure we need their level of > > granularity (i.e. distinguishing between specifically PDF files vs. > > specifically full text bu not PDF vs. images). That would leave AV > > solely for physical location, though as you say refdb itself would need > > for reasons of backward compatability to look for PATH on the AV field. > > > > I agree. The PATH: kludge was actually introduced before the L1-L4 fields were > available in RIS, so it is about time to abandon it. The PHP form should allow > to enter either a full path (file:///path/to/pdf.pdf) or a relative path > (path/to/pdf.pdf), as the latter would allow to use the pdfroot setting with > all its advantages (move your PDF repository without breaking your database, > access your repository from a remote computer via NFS and so on). > > > It's crucial for me--my library is organised by call numbers--and > > probably a number of humanists. I've always recorded call number data > > (sometimes multiple CNs) for books I use a lot, even before I began > > LoCing my home library. What if I took the last U--U5--on the assumption > > that would be least likely to conflict with any existing data? > > > > Come to think of it, wouldn't the AV field be a natural match for call numbers > once we've moved the links to PDFs out of the way? Or do you need to store a > call number *and* a physical location? I can see both: a call number and information about reading room, home or office, etc. Also what about a chapter from a collection: the book has a call number (so I can get it again to see the other chapters), and the chapter I photocopied has a physical location. If we can have multiple AVs, I suppose it is not a great problem. Hard to disentangle, though if we decide to have a CN field later. Lying awake thinking about this (!), I began to wonder is M was not better than U: strictly speaking we are talking about agreeing on a miscellaneous field, not adding a user-defined one. > > regards, > Markus > -- Daniel Paul O'Donnell, PhD Department Chair and Associate Professor of English Director, Digital Medievalist Project http://www.digitalmedievalist.org/ Chair, Text Encoding Initiative http://www.tei-c.org/ Department of English University of Lethbridge Lethbridge AB T1K 3M4 Vox +1 403 329-2377 Fax +1 403 382-7191 Email: [email protected] WWW: http://people.uleth.ca/~daniel.odonnell/ ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV