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