Daniel O'Donnell <daniel.odonnell@xxxxxxxx> was heard to say:
> 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.
>
I see. Multiple AVs or a new CN field (or do you need more than one?) are of
course doable in the database. We just have to figure out ways to export these
data to RIS. We could concatenate the values with a separator, as the AV field
is of unlimited size as per the spec. risx could be amended to allow several AV
fields (in fact, it already supports one AV per user).
> 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.
>
The thing is, there is no M field which is unused in all reference types. You'll
always face conflicts with particular reference types no matter which M field
you pick. The M fields are a leftover of the record-based schema that the
original incarnations of Reference Manager apparently used, as I've discussed
here:
http://www.mhoenicka.de/system-cgi/blog/index.php?itemid=515
regards,
Markus
--
Markus Hoenicka
markus.hoenicka@xxxxxxx
(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
|
