Re: Storage locations again

On Sat, 2007-01-20 at 23:23 +0100, Markus Hoenicka wrote:
> [ I've cc'ed and reply-to'ed the refdb devel list. A few others might
> be interested too ]
> 
> Daniel O'Donnell writes:
>  > Hi Markus,
>  > 
>  > I'm thinking about how to handle the AV field, and especially what to do
>  > about digital and physical locations for the same copy. Related to this
>  > is call numbers.
>  > 
>  > Currently, in your implementation of RIS an object can't have both a
>  > physical and a virtual AV, right? Do you think I should require users to
>  > specify which they mean? I.e. check a box to say "computer file" vs.
>  > "physical copy"? Or we could move one of the fields off to a U or M.
>  > 
> 
> As usual, the RIS spec is not very clear about this, but I wonder
> whether we should use the L1/L2 fields for storing paths to electronic
> copies. Each dataset can have an unlimited number of L1 and L2 entries
> so this would not collide with an URL to the original location of a
> PDF. The only difference would be a local path, something like
> file:///path/to/file.pdf, instead of an URL. We'd have to figure out
> something to keep the pdfroot mechanism alive though. refdbc, or a web
> frontend would then have to check both the AV and the L1/L2 fields for
> matching entries if the RP field claims the item is in file.

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.

> 
>  > Same thing with Call numbers, which are covered anywhere in RIS.
>  > Refworks actually uses ER  - to store them!?! We discussed this earlier
>  > and for my personal use I was just going to choose one of the U or M
>  > fields, but a PHP form is going to enforce the choice on whoever uses
>  > it. Any suggestions for where that ought to go?
>  > 
> 
> If at all, we should settle on one of the U fields. Frankly, I don't
> have a better suggestion right now if we want to be able to export all
> data to RIS. We'll have to decide whether this is indeed an important
> goal, or if we should move ahead and officially support more data than
> RIS can store.

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?

> 
>  > Given your own work on a better storage and transport language, I think
>  > we should be looking for solutions to these that are easily undone so
>  > data entered into RIS using this form can be converted easily to
>  > whatever comes next. I wouldn't mind being on the same page with you on
>  > this.
>  > 
> 
> I have no idea what your data entry code looks like right now. I
> assume you have some internal representation of the data that you
> receive as input, and you map that representation to either RIS or
> risx. I guess that only that mapping is going to change if RefDB moves
> to a richer storage model.

Basically the PHP entry form is using fields corresponding to the refdb
use of RIS: so the value a user places on article title is assigned to
T1 if the type is an article. The output of the form is an RIS dataset
that is fed directly to refdb of addition to the database. The only
internal datamodelling at the moment involves elements for which fields
can repeat (e.g. like authors); in the PHP form you enter them all in
one line separated by colons.

It seems to me best to do as little internal modelling in the PHP as
possible: the goal is to make a web-based front end for refdb.

> 
> regards,
> Markus
> 
-- 
Daniel Paul O'Donnell, PhD
Director, Digital Medievalist Project http://www.digitalmedievalist.org/
Associate Professor and Chair, Department of English
University of Lethbridge
Lethbridge AB T1K 3M4
Canada
Vox: +1 403 329-2378
Fax: +1 403 382-7191


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