Re: Storage locations again

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?

regards,
Markus

-- 
Markus Hoenicka
[email protected]
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de


-------------------------------------------------------------------------
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