I sent this a few days ago, but inadvertently only to Eliot. I now
re-send to the whole list. Sorry for the delay.
--
> Date: Mon, 08 Nov 2004 16:38:07 -0500
> From: Eliot Christian <[log in to unmask]>
>
>> Sorry to be so dense, but I've lost the URL of the GILS
>> context-set, and it's too new for Google to know about it.
>> Please remind me.
>
> http://www.gils.net/context-set.html
Thanks, Eliot. Here are my belated comments on this work.
We've already been through the distinction between a profile and
context set. Actually this document preserves the distinction pretty
well, it just doesn't seem to _realise_ that that's what it's doing
:-) So really, it's a profile; and, like the Bath Profile at
http://zing.z3950.org/srw/bath/2.0/
it has the context-set embedded in it. It's just not as explicitly
drawn as it is in the Bath Profile -- something that I hope you'll fix
in the next release.
> This context set provides an SRW view of the GILS profile of ISO
> 23950.
A link to the Z39.50 GILS Profile would be helpful here. Is it
http://www.gils.net/prof_v2.html
?
> GILS requires only the implicit relations provided in the grammar of
> CQL: Less Than (<), Less Than or Equal (<=), Equal (=), Greater Than
> or Equal (>=), Greater Than (>), Not Equal (<>).
I've not heard these described as "implicit relations" before, and I'm
not sure the term is helpful.
> GILS does not require the default relations defined in CQL.
What is a "default relation"?
> This set encompasses three referents: resource (i.e., "information
> resource"), product (i.e., "information resource product"), and
> record (i.e., "locator record of the information resource"). The
> implicit referent is "resource".
It might be nice to explain a bit more about what there three things
are, and the distinctions between them, for the the benefit of those,
like me, who are not familiar with the Z39.50 GILS Profile. I was a
bit dismayed to find that not one of those three terms is defined in
the glossary in (what I assume is) that document.
> GILS requires that certain indexes be searchable, but only when
> content is present.
The "but only when" clause is problematical. Please could you expand
on its intent?
> Required Indexes
> GILS requires that certain indexes be searchable, but only when
> content is present. These indexes are: Identifier, Subject, Agency
> Creator, Title, and Publication Date.
This information would perhaps be better conveyed by a "mandatory?"
column in the table that follows.
In that table, I haven't bothered checking that your crosswalk with
Z39.50 attributes is correct. I trust you :-)
I really am not happy _at all_ about the profile's recommandation that
the following sets of index-names be treated as equivalent:
dc.title dc.name
dc.author dc.creator
dc.agencyCreator dc.corporateAuthor
dc.date dc.publicationDate
dc.rights dc.copyright dc.useConstraints
dc.publisher dc.distributor
dc.productLanguage dc.languageOfResource
gils.productIdentifier gils.linkage
gils.dispositionAuthority gils.scheduleNumber
rec.locationIdentifier rec.identifier
rec.creationAgentName rec.recordSource
Let me re-state this objection in less equivocal terms. I think that
in doing this, the GILS profile is acting against the explicit
specification and implicit intentions of CQL itself the Dublin Core
context set.
More specifically, an application profile such as this one is simply
not at liberty to add new elements to someone else's context set, as
you are trying to do here with the Dublin Core set (name, author,
agencyCreator, corporateAuthor, publicationDate, copyright,
useConstraints, distributor, productLanguage, languageOfResource).
These are not DC context-set indexes. The same applies to "
More generally, I strongly dislike this practice of deliberately
introducing synonymous indexes into a single set (and, for that
matter, into the world). We would never have deliberately defined
that BIB-1 access points 21 and 3867 both meant "subject"; neither
should be do so in CQL. To do so is to invite a lifetime of support
requests from users wanting to know the different between two (as it
turns out) identical indexes.
My concession on this is that "dc.author", which technically
incorrect, is in such wide use that there may be no point now in
trying to stop it. So for this one -- and this one only, because of
the weight of current practice -- I think we should _allow_ the
synonym, but discourage clients from using it.
So my recommendations on GILS use of the Dublin Core indexes are as
follows:
* title, creator, contributor, description, subject, identifier,
language, source, date, rights, publisher, format, type -- OK.
* author -- useful synonym: support it, but don't encourage it.
* name, publicationDate, copyright, useConstraints, distributor --
useless synonyms: discard.
* agencyCreator or corporateAuthor (choose one) -- not part of the DC
set, but useful. Is this the same thing as bath.corporateName? If
so, then use that; if not, then it needs to be added somewhere, but
where? It's not really GILS-specific. Suggestions are welcome.
* productLanguage or languageOfResource (choose one) -- these are not
part of the Dublin Core context set, but may be useful. If they are
distinct from dc.language, then _one_ of them should be supported
somewhere, and the other discarded. But since the use of dc.langauge
in the GILS profile is described as "The identifier of the language
of the information resource", it's not clear to me how
languageOfResource is different from that.
Similarly, rec.creationAgentName is OK, but "rec.recordSource" is both
ineligible and redundant, and should be discarded.
Regarding the pairs:
gils.productIdentifier vs. gils.linkage
gils.dispositionAuthority vs. gils.scheduleNumber
You should choose one index-name for each of these, and discard the
other.
The final pair of "synonymous" indexes listed in this profile are
rec.locationIdentifier and rec.identifier -- but the Rec context-set
definition makes it clear that these are not the same thing:
http://srw.cheshire3.org/contextSets/rec/1.1/
identifier A unique local identifier for the record
within the current context
locationIdentifer The location of a record (eg directory
structure, SQL table, recordStore
identifier)
I am not entirely clear on the intent of the latter (Rob?) but I think
it might mean a URI (i.e. a globally, as opposed to locally, unique
identifier). Since I am also not clear on the meaning of the GILS
definition corresponding to these names ("The identifier of the
location of the locator record of the information resource"), I
hesitate to recommend which one you should use :-)
I am assuming that your DC elements' descriptions are in according
with the DCMI's element-set document -- I haven't checked.
Aren't gils.creationDate, gils.modificationDate and some others the
same as some indexes in the Rec set?
How is gils.accessConstraints different from dc.rights?
How is gils.medium different from dc.type?
Is there really any point in providing gils.distributorName and
gils.distributorOrganization when (if I understand correctly),
dc.publisher searches both of these indexes? I understand that they
provide additional precision, but ... Does that buy us much?
Finally, having listed 98 indexes, it would be nice to have more than
one example :-)
Well, I am sorry to have had to be so critical, and even more sorry to
have taken so long over getting around to this hatchet-job; but I hope
you find it useful, and that better, stronger, purer GILS context set
eventually emerges from this critique.
_/|_ _______________________________________________________________
/o ) \/ Mike Taylor <[log in to unmask]> http://www.miketaylor.org.uk
)_v__/\ "[The cheese factory] beneath Covenant hung insubstantial,
lambent nacreous sepulchral vitriol ..." -- Mike Lessacher.
--
Listen to free demos of soundtrack music for film, TV and radio
http://www.pipedreaming.org.uk/soundtrack/
|
