Print

---

Dear Mr.Denenberg,

Sorry to arrive with comments not based on previous discussion
as I am a newcomer to Zing.

If I understand well:
1) Collaboration: the protocol does not provide a lock or a 
checkout/checkin system.
    I understand this kind of rigid system may not be suited to 
independant institutions
    working together.
2) Versions: each document contains an history of its updates

Suggestions:
1) Collaboration could be designed by analyzing best practices in the 
current workflow
    of institution. For example:
    a) cataloging identification information (often before buying the 
document)
    b) cataloging descriptive information
    c) indexation by authorities (collectivities, conferences, etc.)
    d) abstract
    e) indexation by subjects
 * Don't you think that the SRU Update should take into account the 
"additive" nature
   of indexation and abstracting (the record is not updated but enriched) ?
 * Don't you think that different stages could be implemented: addition 
or replacement
   proposal for a specific occurrence of a field, approval by the record 
owner(s) ?
2) Collaboration could be supported by different functions:
    a) Users could subscribe to a record ("I would like to be advised if 
this record changes")
        A special retrieval index would provide the list of subscribed 
record for a given user
       modified since...
    b) Users could subscribe to a record for a given action (update, 
adding or replacing
        specific occurrences in a field of a given record): any updater 
could check if
        someone is registered for an action on the record he(she) wants 
to update.
    c) Suggestions in terms of replacement, suppression or addition 
could be recorded
        for acceptance or rejection by record "masters".
 (from my point of view, it is clear that the concept of "User" and 
"Priviledge" have to
  be managed on the server side or in a collaborative mechanism like 
Athens that may
  be a nice complement to SRU.  So, for now, the updates privileges are 
set by
  the "masters of the server")

I am looking to all the aspects of the SRU protocols because I want to 
make it
the heart of the new Belgium Poison Center information systems: medical 
doctors
are answering to emergency calls and need to access information in 
multiple databases
in an unique and POWERFUL (I did not found any up to now: any suggestion?)
user interface.
The internal databases would be searched AND updated, so all aspect of SRU
are pertinent.

I would like only to insist on the fact that SRU is an application protocol.
It may not be too dependent of work flow practices but it must, at least,
take into account the support the good ones are needing now.

Wishing you a very nice day,

Christophe Dupriez

Ray Denenberg, Library of Congress a écrit :
> A new draft of the Record Update protocol has been developed by the SRU
> Editorial Board.
> http://www.loc.gov/standards/sru/record-update
>
> Please review and comment by October 12.
>
> --Ray Denenberg
>
>
>
>