> Date: Wed, 15 May 2002 11:04:31 -0400
> From: "LeVan,Ralph" <[log in to unmask]>
> > My proposal is the following:
> >
> > 1) Allow local and global namespace prefixes.
> > 2) Let the server decide what to do with unprefixed index names.
> > 3) Let's try to define a list of unprefixed index names
> > (instead of dc.xxxx) just to standardize the names (ambiguity
> > is the clients risc).
> > 4) Make sure Explain specifies the servers behaviour unambiguously
> 1, 2 and 4 are great!
> I'm not at all happy with #3.  That's just Bib-1 all over again.
> The ZIG has no business defining access points for other
> communities.

I think Theo's point is that we're talking about access points that
don't belong to any community -- or, if you prefer, the "no community"
community.  I agree with him that we should provide a lax way for
talking about things things (and add that there can be no strict way,
for fundamental reasons.)

> Date: Wed, 15 May 2002 17:24:14 +0200
> From: Theo van Veen <[log in to unmask]>
> Ok, we are almost there.
> For #3:
> For unprefixed names let's use as much as possible the element and
> qualifier names from the available DCMI application profiles without
> the namespace prefix (ambiguity is the clients risc).

I think this is a neat compromise.  To state it more clearly (if I
may): when a server receives a search against an unqualified index
_for which is has no semantics of its own_, it is gently encouraged to
treat it as semantically similar to the same-named Dublic Core

(Insert additional obfuscatory prose according to taste.)

Next please!

> Date: Wed, 15 May 2002 16:01:42 +0100
> From: Robert Sanderson <[log in to unmask]>
> Here's my list of names.
> <#include "bib1.h">                       (many hundred)
> <#include "collectable_card_games.h">     (many thousands)
> <#include "email.h">                      (~100)
> <#include "zthes.h">                       ?
> <#include "network.h">                    (~10)
> <#include "tei.h">                        (many many thousands)
> <#include "archives.h">                   (see tei)
> <#include "CIMI.h">                       (see tei)
> <#include "artworld.h">                   (see tei)
> <#include "OMRAS.h">                      (see tei)
> <#include "lego.h">                       (see tei)
> <#include "userregistry.h">               (~100)

Way, way too many.  We couldn't possibly require -- or even encourage
-- servers to standardise semantics of that many access points.  I was
think more in terms of, ooh, let's say, about fifteen.

OK, nearly done ...

> Date: Wed, 15 May 2002 16:31:41 +0100
> From: Robert Sanderson <[log in to unmask]>
> What's the Dublin Core for collectable card rarity?

There isn't one.

> Or the name of the card set that it's from?

There isn't one.

> How about the DC for username? port number?  Music tempo?  How do
> you specify the name of the journal that an article is to be found
> in?

(I'm going to leave you to figure out the answers to these :-)

> Why is DC to be treated as superior to any other indexset?

Because it's there.  What we're talking about here is a set of
semi-standardised interpretations for access points which can be used
in cross-domain-like searches.  Seems daft to make some up when we
already have a perfectly sensible set lying around.

> If I have a default indexset in a collectable card database, then
> searching for unprefixed 'set' should not have to be interpreted as
> searching for a mathematical set or anything else.

No indeed -- servers would say: "Sorry, mate, got no idea what you're
talking about."

> I still disagree fundamentally.  BIB1 proves that This Does Not
> Work.

It proves that BIB1 doesn't work.  That's all.

 _/|_    _______________________________________________________________
/o ) \/  Mike Taylor   <[log in to unmask]>
)_v__/\  "Whole AND segments" -- Monty Python.