Sometime ago we had some discussion on collections and services. I
proposed to make the base address of a service that gives access to the
object descriptions, a part of the collection description. The main
objection was that there could be more services giving access to the
same collection and that a single service may give access to the
description of several collections.

Although the term "collection description" may not apply to the type of
description that I need, both types of descriptions may serve the same
purpose. What I need is descriptions of "seachable targets". These
targets contain the descriptions of objects that may be from different
collections. The object descriptions should contain the link (URL, URN
or OpenURL) to the actual digitized object or the service giving access
to an object (e.g. document delivery). The object description should
also contain information on the collection it is being part of.
Sometimes we have that information, sometimes not.
Having found such an object we might want to locate more objects from
that collection. The key element to do that is to know an address where
to look for more objects of that collection. So we need the address of
the collection description and from that collection description we
should find out the services giving access to search and retrieval of
the object descriptions. As Ann pointed out there can be different
access methods, so we need to identify these access methods separately.

In The European Library project we use <dc:identifier> with several
encoding schemes (SRUbaseURL, URL,  Ztarget) for this purpose with the
tel namespace.

I have two questions:
1) For what purpose will collection descriptions be used if one cannot
figure out the services for search and retrieval from the collection
description?
2) Does it make sense to try to keep aligned with the collection
description name space for this purpose or should I just leave these
encosing schemes part of the "tel" namespace. This  question has to do
with a more fundamental problem. Trying to introduce terms in a
namespace when these are needed for providing some functionality and
then finding out that other namespaces have adopted the same term also.


To avoid the problems like mentioned in the second question we need a
generic schema DCX (Dublin Core eXtended)  and perhaps a generic
namespace (dcx). DCX means that records may contain terms from other
namespaces when they could not - within reason - be expressed by terms
from the dc and dcterms namespaces. Applications are supposed to use the
terms they know and ignore the terms they don't know. When we put these
extra terms in the dcx namespace they can be shared more easily,
avoiding records containing more namespace declarations than actual data
and avoiding changing namespaces for terms that are already in use. The
use of the DCX schema avoids the need to know all schemas that almost
pure DC but have only a few extensions.

Theo