On Fri, 26 Sep 1997, Rachel Heery wrote:

> On Thu, 25 Sep 1997, Misha Wolf wrote:
> 
> > Consider a DC-savvy search interface which allows me to enter, against 
> > the field Contributor, the search string:
> > 
> >    Chris Smith Illustrator
> > 
> > A typical search engine will return all DC records where the Contributor 
> > field contains any of "Chris", "Smith" and "Illustrator".  That leaves us 
> > with a few questions:
> ......
> .......
> 
> But can we say there is a typical search engine for DC implementations? I
> would imagine many of the implementations would have search
> engines that allowed fielded searching.

In my view such as search engine should have a standardized mapping
between the fields, that is the Dublin Core Elements and their
qualifiers, and the search attribute. The Z39.50 protocol supports all
the elements, and a better part of the qualifiers. It _also_ provide
a mapping for most, if not all, of the elements in the socalled BIB-1
attribute set which is used for searching. .

[... snip ...]

> >    <contributor>
> >       <name>Chris Smith</name>
> >       <role>Illustrator</role>
> >       <affiliation>United Illustrators</affiliation>
> >    </contributor>
> > 
> > The other approach proposed just doesn't scale.  It was:
> > 
> >    <meta name="DC.contributor.illustrator" content="Chris Smith">

As far as the coding of records is concerned, Z39.50 provides
hierarchical database model that lends itself exellently to and XML
solution to the syntax problem. This model is called GRS-1, generic
record syntax (ask someone else about the "1")..

[... snip ...]
 

> But would your solution stop people doing that?? As you say later there
> would still need to be some way of imposing a finite list. 
> 
> Oh, and isn't there the issue of how search engines would deal with
> grouped, repeatable elements ... but I think that's another thread,
> something for DC5 maybe? 

Now, a lot of metadata is made available through Z39.50 servers, and
therefore I thing it would be logical to look there for that finite
list. If we do so, then we will be ensured that there is at least one
protocol that can support searching in a database of dublin core records.

> 
> Rachel
> 

Z39.50 does actually provide two such lists of basic elements and
qualifiers. It may or may not warm your heart that our 15 elements are
proposed for inclusion in one of these lists just before the DC4
meeting. The two lists are called tagsetg and tagsetm, and I have
included them in the way I have them installed on my "personal"
experimental Z39.50 installation (a zebra server from Indexdata in
Denmark).

Z39.50 community is using these elements "as parts of speech" in the
development of what is called "profiles" in Z39.50 jargon. I propose
that we take these two lists as the basis for our qualifiers.

There are a couple of good arguments for that:

	1. There will not be a standardized way of searching for something
	else in the near future anyway. We can fairly rapidly develop a
	search system for our metadata, using a record model supporting
	the hierarchical way of thinking about qualifiers that was
	adopted in Canberra.

	2. Even if we don't use Z39.50, the imtems on these lists are
	selected by other people seriously caring for metadata,
	although they didn't (not in the past at least) adhere to our
	"corish" philosophy.

	3. By doing this we might even exert some pressure upon the
	ZIG to adopt a more "corish" view on metadata, and to finally
	settle the issue of the inclusion of the DC elements in
	tagset-G.



The Canberra qualifiers must not breed like Australian rabbits.


Cheers



Sigfrid

 

------------------------

The Z39.50 tagsets M and G including the proposed extensions



name tagsetg
reference TagsetG
type 2

tag	1	title		string
tag	2	author		string
tag	3	publicationPlace string
tag	4	publicationDate	string
tag	5	documentId	string
tag	6	abstract	string
tag	7	name		string
tag	8	date		generalizedtime
tag	9	bodyOfDisplay	string
tag	10	organization	string
tag	11	postalAddress	string
tag	12	networkAddress	string
tag	13	eMailAddress	string
tag	14	phoneNumber/telephone	string
tag	15	faxNumber	string
tag	16	country		string
tag	17	description	string
tag	18	time		intunit
tag	19	documentcontent	octetstring
tag	20	language	string
tag	21	subject		string
tag	22	resourceType	string
tag	23	city		octetstring
tag	24	stateOrProvince	octetstring
tag	25	zipOrPostalCode	octetstring
tag	26	cost		octetstring
tag	27	format		string
tag	28	identifier	string
tag	29	rights		string
tag	30	relation	string
tag	31	publisher	string
tag	32	contributor	string
tag	33	source		string
tag	34	coverage	string
tag	35	private		


name tagsetm
reference TagsetM
type 1

tag	1	schemaIdentifier	oid
tag	2	elementsOrdered		bool
tag	3	elementOrdering		int
tag	4	defaultTagType		int
tag	5	defaultVariantSetId	oid
tag	6	defaultVariantSpec	structured
tag	7	processingInstructions	string
tag	8	recordUsage		int
tag	9	restriction		string
tag	10	rank			int
tag	11	userMessage		string
tag	12	url			string
tag	13	record			structured
tag	14	local-control-number	string
tag	15	creation-date		generalizedtime
tag	16	dateOfLastModification/lastModified generalizedtime
tag	17	dateOfLastReview	generalizedtime
tag	18	score			int
tag	19	wellKnown		string
tag	20	recordWrapper		structured
tag	21	defaultTagSetId		oid
tag	22	languageOfRecord	string
tag	23	type			octetstring
tag	24	Scheme			octetstring
tag	25	costInfo		octetstring
tag	26	costFlag		bool