Re: Replication of UR* resources and Privacy

Mark Madsen (msm@ansa.co.uk)
Fri, 7 Jul 95 12:26:11 BST


From: Mark Madsen <msm@ansa.co.uk>
Message-Id: <9507071126.AA23140@euclid.ansa.co.uk>
Subject: Re: Replication of UR* resources and Privacy
To: weibel@oclc.org
Date: Fri, 7 Jul 95 12:26:11 BST
Cc: uri@bunyip.com
In-Reply-To: <199507061634.MAA01476@ws02-00.rsch.oclc.org>; from "weibel@oclc.org" at Jul 6, 95 12:34 (noon)

I wrote:
> > Let me answer this with a question.  Can you think of an example of a
> > service that should _in_principle_, *not* be replicable?

Note the in principle bit.  I think this was missed in the heat of the
response.

Stu wrote:
> An example from RL (tm):
> 
>    OCLC is a cooperative membership organization, supported by access
> fees to a database of library resources (some 33 million records
> pointing to smoething over half a billion objects).   Our Online Union
> Catalog, built by our membership,  is one of the major assets of the
> cooperative, and represents an enormous investment of time and expense
> on the part of our membership.

Thanks for citing a Real-World (TM) example, because it does help to
make things more concrete.

> We are bound to protect that investment, as we will be when there
> are large numbers of Internet resources cataloged in that or similar
> databases.

Right.

> Access to such databases may or may not appear free to end
> users... there are various economic models that can be applied, but
> make no mistake that value added resource discovery systems will be
> protected from arbitrary wholesale replication.

I think you really mean from the consequences of UNAUTHORISED copying.
But even so, your emphatic response brings up a number of points for
me to hammer on again:

* In my example, I explicitly put the replication procedure in the
MANAGEMENT interface, and I really hope that no-one reading this even
knows anyone who has a cousin who had a dog that would be stupid
enough to give general access to the management interface of a service
for which they are responsible.

* In order to manage the resource in the long term, you will NEED to
be able to replicate the service in a controlled and appropriately
authorised fashion.  Think of all those NASA tapes corresponding to
BILLIONS'n'BILLIONS (as Carl Sagan might say ;-) of $$$$ of tax money
that are no longer usable, because they did not have a replication
method.  (Yes, I know they were pre-object management times, but
that's why we can think up better ways to manage data/services/objects
now.)

* In my example I explicitly put DIFFERENT procedures in DIFFERENT
interfaces so that the distinction between "replicate the service" and
"copy the service's internal reference table data" would be made
clear.  Take another look at it.

>   As for privacy issues, this may be in part a function of what is in
> the DB.  Web walkers that indiscriminantly scoop up  web pages may in
> fact violate some privacy laws or standards.  Objects that are selected
> by catalogers are more likely to be "published" in some sense of the
> term; we don't normally think there are privacy issues for making such
> objects more visible in catalogs.  

The levels and granularities at which access, authorisation, and
security are controlled will vary from case to case.  I said nothing
in my example in favour of any standard that would restrict your
ability to defend and control your resources as you see fit.  The
problem posed by the webwalkers you mention is to give you the option
of keeping things like robots off your system if you so wish.  We need
this ability, but we also need replication capabilities because they
are useful too.

> Privacy concerning who has accessed them, however, is considered a
> hot button issue for librarians.  Odd that this has received so
> little attention on the Web (ooooh, but we love those transaction
> logs!)

Mobile agents will solve this problem.  However, I'm unclear at the
moment whether the resource issues relating to agents are considered
to be part of the material for consideration by the URI working group.

Mark.

--
________________________________________________________________________
Mark Madsen: <msm@ansa.co.uk> <URL:http://www.ansa.co.uk/Staff/msm.html>
Information Services Framework, The ANSA Project, APM Ltd., Castle Park,
Cambridge CB3 0RD, U.K.  <URL:http://www.ansa.co.uk/>;  <apm@ansa.co.uk>
Voice: +44-1223-568934; Reception: +44-1223-515010; Fax: +44-1223-359779