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  November 2004

ZNG November 2004

Subject:

Re: GILS Context Set

From:

Mike Taylor <[log in to unmask]>

Reply-To:

Z39.50 Next-Generation Initiative

Date:

Fri, 5 Nov 2004 11:05:52 GMT

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (88 lines)

> Date: Fri, 5 Nov 2004 05:22:20 -0500
> From: Eliot Christian <[log in to unmask]>
>
>>> So, should the CQL context set list "dc.author" as an alias for
>>> "dc.creator"?
>>
>> This particular mistake may now be so widespread that we'd do
>> better to bend with the wind rather than breaking.
>
> I agree that it would be folly to emit an error message on receipt
> of "dc.author".
>
> Perhaps what we have here is a philosophical issue: Does a context
> set *reflect* the manner in which a community labels its indexes, or
> does a context set *dictate* the manner in which a community labels
> its indexes?

Well, I would argue that the context set should be created by the
community anyway, so the putative conflict between the community and
the context-set authors doesn't arise.  Clearly only the community can
say what indexes it needs to search; it should then be encouraged to
write a context-set definition that provides one and only one way to
express each such search.  Some communities may have very strong
reasons for violating this guideline, and I think the widespread abuse
of "author" in Dublin Core is a case in point.  (I make this mistake
myself all the time: I made it, by implication, in a presentation on
CQL that I was writing only yesterday).  But such exceptions should
_be_ exceptions, and I really don't think we should go about creating
aliases lightly.

> I am wondering about the rules on inheriting from one context set to
> another.

A clarification: there is NO "inheritance" of context sets.  This
paradigm is a holdover from Z39.50 version 2, when all the attributes
in a Type-1 query had to be taken from the same attribute set, with
ugly results such as the GILS and CIMI sets both importing BIB-1
wholesale.  But in Z39.50 version 3, and of course in SRW/U, there is
no such limitation: indexes from different context sets can be freely
mixed, so there should ideally be _no_ duplication of indexes between
context sets.

And now, on to your specific query:

> For instance, the index named "identifier" occurs in the Record
> Metadata http://srw.cheshire3.org/contextSets/rec/1.1/ as "A unique
> local identifier for the record within the current context".  This
> is quite general and similar to Dublin Core, where it is defined as
> "An unambiguous reference to the resource within a given context."

Aha -- not quite!  The Dublin Core identifier element is the
identifier of the resource you're describing, whereas the Rec set's
identifier is that of the record that's describing it.  If this seems
like an esoteric distinction, then consider this example.  I have a
database of records that describe books, each record contains a title,
author, ISBN and my own comments on the book.  Each of my records also
has a local-ID field that identifies it with my database.  Now you
would search ISBN with dc.identifier, and local-ID with
rec.identifier.

Hope that's helpful.  For a slower, more patronising discussion of
this subject, I recommend my informal paper _One Man's Ceiling is
Another Man's Floor -- or -- Why your data may not be as meta as you
think it is_, which is available at
        http://www.miketaylor.org.uk/tech/metadata.html

> So, should the practice be to have rec inherit this index from dc or
> should dc inherit from rec. (My sense is that DCMI insists on dc
> being the "uber set" and admits no supersets.)

Neither: in this case the issue doesn't arise because the two elements
really are different.  But if a new application profile, say the
Fruitbat profile, needs to include record-identifier searching, then
the correct approach is not to have the Fruitbat context set "inherit"
the identifier index from the Rec set, but just to have the Fruitbat
profile say "we use fruitbat.wingNumber and rec.identifier".  For a
fine example of how this should be done, see the in-progress GILS
attribute set, by ... er ... wait ...  :-)

 _/|_    _______________________________________________________________
/o ) \/  Mike Taylor  <[log in to unmask]>  http://www.miketaylor.org.uk
)_v__/\  "Shut up, be happy.  The conveniences you demanded are now
         mandatory" -- Jello Biafra.

--
Listen to free demos of soundtrack music for film, TV and radio
        http://www.pipedreaming.org.uk/soundtrack/

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