LISTSERV mailing list manager LISTSERV 16.0

Help for ZNG Archives


ZNG Archives

ZNG Archives


[email protected]


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

ZNG Home

ZNG Home

ZNG  May 2002

ZNG May 2002

Subject:

Re: Betr.: Ralph's Premises

From:

Reply-To:

Z39.50 Next-Generation Initiative

Date:

Wed, 15 May 2002 21:52:57 +1000

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (155 lines)

On Wed, May 15, 2002 at 12:43:52PM +0200, Theo van Veen wrote:
> 1.
> 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).

> 2.
> 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.

> 3.
> 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.

> 4.
> 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.

> 5.
> 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.

> 6.
> 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
differ here.

> 7.
> 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
    not known).
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.

> Theo


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?

Alan

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.

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

July 2017
October 2016
July 2016
August 2014
February 2014
December 2013
November 2013
October 2013
February 2013
January 2013
October 2012
August 2012
April 2012
January 2012
October 2011
May 2011
April 2011
November 2010
October 2010
September 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
October 2009
September 2009
August 2009
July 2009
May 2009
April 2009
March 2009
February 2009
December 2008
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
January 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
December 2005
November 2005
October 2005
September 2005
August 2005
July 2005
June 2005
May 2005
April 2005
March 2005
February 2005
January 2005
December 2004
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
May 2004
April 2004
March 2004
February 2004
January 2004
December 2003
November 2003
October 2003
September 2003
August 2003
July 2003
June 2003
May 2003
April 2003
March 2003
February 2003
January 2003
December 2002
November 2002
October 2002
September 2002
August 2002
July 2002
June 2002
May 2002
April 2002
March 2002
February 2002
January 2002
December 2001
November 2001
October 2001
September 2001
August 2001
July 2001

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager