On Wed, May 15, 2002 at 12:43:52PM +0200, Theo van Veen wrote:
> I do want a single concept of "title" and I encourage the use of
> qualifiers as in Dublin Core (with its "dumb down" rule), but
> qualifiers and namespace prefixes are different things!
I may have used the word 'qualifier' at times when I meant 'CQL prefix'.
(ie - qualify an index name with dc.). I had not meant to refer to
the dumb down rules of Dublin Core at all because it does not
map onto Z39.50 (Z39.50 has no dumb down rule).
> With respect to your 3 solutions I would like to add a 4th solution.
> Try to stay in line as much as possible with Dublin Core names (and
> available application profiles) and allow qualifiers (indicating
> refinements or encoding schemes) that sometimes - but not always - can
> be neglected (dumb down). Avoid namespace prefixes as they really are a
> pain. Use explain to relate index names to attribute sets (optional).
It is a valid 4th option. But it would not satisfy my needs.
Dublin Core is not sufficient for all the index names I want
to support. It may be because I use Z39.50 daily for all sorts
of collections of data, and only occasionally bibliographic data.
As I understand the Dublin Core philosophy, they have defined a
set of standard access points that are common to lots of situations.
But they certainly do not cover all concepts. That is why groups
then extend Dublin Core for their own needs. To avoid ambiguity,
labels (I will avoid 'prefix' and 'qualifier' :-) are used to group
names. For example, in <META> tags of a HTML page, you do not use
"title" but rather "dc.title". I believe this was intensionally
done by the Dublin Core group as an acknowledgement that their set
of names is only one of many such sets.
I guess this is just an area we have different goals in. I think
you want to try to limit CQL to the Dublin Core domain where there
is a limited set of concepts. I want to use CQL for any domain
where domains extend over time.
> I will encourage both usage U1 and U2: 1) sending a query to
> multiple servers with agreed index names and 2) sending queries to
> local systems with specific locally known index names. I encourage the
> use of explain for advertising these local index names.
Yep, we agree here completely.
> I do not know the expectation of a user when he searches for "author"
> and I do not know an unambiguous way to find out. But I do know that
> the introducrion of attributes sets will not solve this problem. Each
> server has to offer indexes that intuitively best match to the index
> names (with optional qualifiers but without namespace prefixes)
I think attribute sets *do* provide an unambiguous definition of a
concept - well, at least as good as the attribute set writer makes
the definition anyway! Also I am not sure exactly what you mean by
'intuitively' here - I want to map a CQL query onto a Z39.50 query.
That is the purpose to me of SRW. So I need a computer algorithm.
I am not sure how to write one query, send it to lots of databases,
and then have the server 'intuitively' massage the query into the
correct semantics for that server. I have probably missed your point here.
For distributed searches, I think formally agreed to semantics of
index names are critical for the results to be meaningful.
> In general we should not mix up namespace prefixes, qualifiers and
> attribute sets. I always assumed that attribute sets were intended to
> agree on the minimum set of attributes that servers should support and
> clients could rely on. I never knew that they were intended to modify
> the meaning of attributes.
To me an attribute set includes a set of access points and defines
the semantics of those access points. The semantics should be unambiguous.
I am not quite sure what you meant by "modify the meaning of attributes".
Sorry if I muddied the water with a previous post.
> With respect to the second point in your summery:
> Local index names should not need Explain but may make use of
> Explain. In my view it is sufficient when applications can use the
> information in Explain to present a list of (extra) index names with
> their meaning. I do not know what the added value of a URI would be for
> that purpose.
I think the question I had was what information should be in
the explain record to identify the semantics of an index name.
I *think* your opinion is the name alone should be enough to
identify the semantics (by trying to limit applications to
Dublin Core, or some set of well known names).
Since I am trying to not limit CQL to a particular domain but
rather be able to use it in a wide range of domains, our requirements
> With respect to the third point in your summery:
> In general it may be good to have a flag indicating the different
> types of responses or behaviour but we should only introduce such flags
> if it can not be solved by flexibility of the client or the server. I
> mean for example: we should not use flags to prevent the server sending
> fields that could also easily be ignored by the client.
> In your example I prefer to return a tag indicating that an index
> name does not exist or - when the error message is that important - the
> client should check Explain first.
That is certainly a valid option - that is evaluate the query in
whatever way the server likes (such as ignore undefined index names),
but respond with saying 'I ignored theses index names because I did
not understand them'.
I would rather tighten it up though and say either
(1) servers should always ignore unknown index names and return which
ones it ignored, or
(2) report an error for unknown index names (and list which names were
I can see the logic in both. But I dislike a server being able to choose
whatever it wants to do. Consistency is a good thing.
Bottom line: correct me if I misrepresent you, but I think you want a
single space of meaningful names that describe the concepts in their
own right on the assumption that if two databases have a index called
"title", they will both be the same sort of concept. The Dublin Core
elements are a good basis for this.
I on the other hand want to use CQL (SRW anyway) in a wide range
of application domains. I can almost guarantee the same unprefixed index
name (such as "title") would be given different semantics in different
databases. This is why I agree with the Dublin Core practice of using
"dc.title" in HTML <meta> tags, not "title" to qualify (oops, scope?)
the meaning of "title" to the Dublin Core semantics.
I do think its too prescriptive to require all index names to have
a prefix in front - hence the idea of local index names.
Hence I stick by the proposal of allowing index names to include an
prefix where there are a set of registered prefixes with
agreed to semantics (such as "dc" for Dublin Core and "bath" for Bath
queries - the actual prefixes need to be defined though!).
Local index names without prefixes are also permitted, but the
semantics are not agreed to in a formal way.
Theo can simply choose not use prefixes in databases he defines.
Others can use prefixes once they are registered with defined
semantics. Is it time to vote on this one and put it to bed?
ps: I quite like the word 'scope' instead of 'prefix' in CQL -
because it does not collide with XML namespaces, or with 'qualifier'
in Dublin Core. No big deal.