[Refdb-users] ref ID, user defined? + some plans (long)

[Paul B. <pbo...@sc...>]

Hi Markus & other developers,

Thanks for your refdb open source project, it appears to get most of the 
basic features we may need :-)

We want to implement a "distributed" system on top of a central 
repository (implemented with refdb) with the following properties:

- store all our organisations references centrally in refdb with a 
unique persistent ID
- provide a service to end-users to keep there existing reference 
applications (reference manager, endnote and bibtex) and word processors
- use the central repository of references also in a library portal and 
in the future also use them inside xml documents which will reside in 
different portals.

1) To reach this goal there are is one major issue:
We need both import and export from/to *existing* reference systems and 
databases ( these range from personal "databases" to groups who are 
using a common database/system.). To maintain backwards compatibility, 
the existing keys should be preserved in order not to break references 
in existing documents. I read in previous posts and the manual that user 
defined ID's are not supported or retained when importing.

Do you plan to integrate this in some way? Perhaps as an additional 
database field other than the default one and optionally coupled to the 
user? Of course this should be also an export option to select the key 
to use with a fall back to the refdb ID if no such key exists

A workaround for us could be to import/export them from refdb and use 
these databases only for new documents, but this is rather confusing and 
some users tend to define keys which hint to the contents of a certain 
reference (mainly latex users). Or do you think the use of U1..U5 and 
/or M1..M3 could already serve this purpose (in both directions) with 
additional filter stages / config options (for bibtex this seems to be 
the case, but what about the others)?

2) We will also develop a refdb SOAP service (in php, calling the refdb 
client utilities) which can be called by various applications (like the 
portals we plan to develop). Initially this will be a read-only service. 
I think other people may be interested in this as well (and we'll 
release the code of course).

I would welcome feedback, especially on the ID/key issues

Best regards

Paul