RE: [Digir-dev] Question on DiGIR Darwin Core and uniqueness of Catalog Numbers

[Blum, S. <sb...@ca...>]

> -----Original Message-----
> From: Jim Croft [mailto:jr...@an...]=20
> Sent: Monday, May 10, 2004 6:11 PM
> To: Blum, Stan
> Cc: Donald Hobern; DiG...@li...
> Subject: RE: [Digir-dev] Question on DiGIR Darwin Core and=20
> uniqueness of Catalog Numbers

[snip]

> >Having multiple resources under a DiGIR provider creates a=20
> separation=20
> >of
> >the distributed query technology from the way people group=20
> their records=20
> >into resources; there doesn't need to be a one-to-one correspondence=20
> >between provider and resource.
>=20
> In that one provider can serve several resources, but not the=20
> other way around?

We spent a fair bit of time in Oaxaca talking about the many cases in =
which a
single resource is served by more than one provider.  Actually, these =
are
cases where several *copies* (not necessarily identical) of a resource =
are
being served by more than one provider.  We don't have a solution to =
this,
yet, as it seems to be a problem primarily for people who are interested =
to
know how many records we have on line.  (And the people anticipating =
that
different copies of the same resource are eventually going to give =
different
answers to a question.) =20

Even more to the point, there is nothing that prevents a single record =
from
being exposed/served through two or more resources (imagine a =
taxonomically
defined resource and a geographically defined resources from a single
provider).



> Is the one-to-one correspondence [between provider and resource] =
something
we should be=20
> striving for or at=20
> least recommending?

I don't know.  Does the simple web services approach say that a separate =
URx
should be available for every resource?  I think this is an important
question.


> >I also want to point out that a provider does not correspond to an
> >institution.  Many cases exist where an information resource=20
> is "provided"=20
> >(exposed via DiGIR) by a different organization than the one that=20
> >maintains it.
>=20
> This is both a good thing (in terms of providing access to=20
> data that might=20
> not be able to get there by more direct means), and a not so=20
> good thing (in=20
> that the identity and credit of the data maintainers seems to get=20
> downplayed in the DIGIR provision process).   I think there=20
> is still some=20
> work needed in this area as the data passes through several=20
> sets of hands=20
> on its way from source to destination.

I don't agree that it's a problem with DiGIR, but with the people who =
are
configuring DiGIR providers/resources.  Our view is that the technology
should be made as transparent as possible.  An end user should see a =
list of
resources in a DiGIR portal almost the same way they would keep a list =
of
addresses for written requests.  Resources should be identified =
primarily by
the custodians or owners of those resources.  The technical provider has =
done
something they shouldn't, the original resource manager needs to take =
that up
with the provider. =20

The more difficult problem is going to come with the Russian Doll model =
for
data, where a provider doesn't just make other peoples' resources =
available,
but "adds value" to them by doing things like "correcting" taxonomic =
names,
adding latitude-longitude, or converting lat-lon to a consistent map
projection.  This will come.  What problems will it create?

-Stan