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