|
Paul Walk
07/18/2008
|
I tend to agree with Rachel's proposition.
Regarding Chris's definition: "a repository is a managed, persistent way of making R, L and T content with continuing value discoverable and accessible"
I think I could live with this.... :-)
|
|
Paul Walk
07/17/2008
|
I'm aware of some scenarios where the user's workflow is already fairly well systematised - in which cases this would make sense.
However, I suspect that in the majority of case this is not the case, so I think that in the general case the it isn't particularly helpful to make the user explicitly aware of the repository. Why should they be made to care?
|
|
Paul Walk
07/17/2008
|
Chris, More like the Web - yes! Like Slideshare - no!
I expanded on this a little in my comment on your previous idea (http://jiscrepository.ideascale.com/akira/dtd/2273-784)
Paul Walk
|
|
Paul Walk
07/17/2008
|
Chris, This is the one I really disagree with I think!
The repository should be able to participate in an interactive Web. It should be entirely possible for someone else to build a remote Web 2.0 service around resource exposed in my repository. This does not preclude me building such a service - if I think I have sufficient mass of interested users etc. but if I *need* to do this because only I can, then I have probably just built another silo.
This is what I meant by my assertion that, in general, Technorati offers us a better model than Slideshare. Someone can build a better, more focussed, domain specific etc. version of Technorati if there is demand for this, without needing to move or copy the resources in their 'source repositories' (blogs, in this case).
Paul Walk
|
|
Paul Walk
07/17/2008
|
Chris, Responding to this particular idea - actually two ideas: persistence and what I interpret as 'offline synchronisation'.
I agree that persistence, more or less as you define it here, should be a core property of what I think of as a 'source repository'. In terms of ease of use: read, or 'get' access should be simple and should be provided through HTTP unless there is a very good reason not to. We should aspire to ease of use in terms of ingest and administrative activities.
In terms of synchronisation with offline storage (unless I have misunderstood your point): this is an interesting area, but I'm not sure it is a fundamental or universal function of 'the repository'. I think we are going to see a strange race between the development of mechanisms to do this (e.g. GoogleGears) and the progress in us all becoming so ubiquitously and permanently connected that we don't need this any more.....
Paul Walk
|