On Wed, 2006-09-27 at 09:48 +0200, Christophe Dupriez wrote:
> Sorry to arrive with comments not based on previous discussion
> as I am a newcomer to Zing.
First appearances are at least as important, if not more so, than the
comments of someone who has followed things all the way through :)
> 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.
Locking or other concurrent editing is profile dependent in this
context. For example, you could implement a locking system either by
setting a flag on the record's metadata before editing it as a user
action, the server could set a lock whenever any record is checked out,
or the user could request that the server set a lock using an
extraRequestData field.
Note that there is a diagnostic specifically pertaining to locking --
number 52. It's not that we haven't thought of it, it's that we can't
mandate it for all implementations, especially as there are (arguably
better) alternatives such as CVS like systems.
> 2) Versions: each document contains an history of its updates
Optionally. recordVersions is always optional in SRU Update because
some systems simply may not record any sort of history or versioning
information.
Versioning is also a simple way to avoid locking -- check that the
version of the record being submitted is the same as the version in the
server. If not, reject the submission.
> Suggestions:
> 1) Collaboration could be designed by analyzing best practices in the
> current workflow of institution.
Absolutely. We hope that once there are some implementations being
used, this sort of recommended best practice document will come out of
the community.
> * 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) ?
This seems like a use case rather than a protocol decision to me. It
also looks like a use case that is supported.
To take a java example, JSR170 has no real concept of 'record'. It
would be very easy to layer Update over JSR170 by using the path to the
node as the record identifier.
Equally, the record identifier could include an XPath to a node within
the record to be changed. Or in extraData.
> * 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) ?
The approval to change could be implemented using additional metadata
flags and/or versions. For example, you submit a proposed change and
the system creates a branch for the record. If the moderator approves
the change, then your branch becomes the main trunk.
> 2) Collaboration could be supported by different functions:
Yes, but these would be outside of the scope of the protocol which just
handles update.
> a) Users could subscribe to a record ("I would like to be advised if
> this record changes")
> b) Users could subscribe to a record for a given action
That seems like a search oriented task, rather than a maintenance task.
Perhaps an extension for SRU, where it could be tied to a search.
For example:
query: rec.identifier = 10245
extraData: setQueryAlert=email
(or something like that)
> c) Suggestions in terms of replacement, suppression or addition
> could be recorded
> for acceptance or rejection by record "masters".
I think this can be done already, as above.
Hope that helps :)
Rob
--
Dr Robert Sanderson
Dept of Computer Science, University of Liverpool
Home: http://www.csc.liv.ac.uk/~azaroth/
Cheshire: http://www.cheshire3.org/
