Folks:
As I'm leaving tomorrow on vacation and will not be back until just before
this meeting (which I'm not attending), I've written some quick and rather
brain-dumpish comments on the Library Application Profile.
At the very least, I hope it will provoke some discussion (which I'll read
when I get back) ... ;-)
Diane
++++++++++++++++++++++++++++++++++++++
Comments on DC-Library Application Profile
The introduction provides five possible uses for DC in library and related
applications. They all seem fairly reasonable (though I might quibble with
the third a bit), but none seem to explain the complexity of this profile
and the retention of a distinctly MARC-like view of the world.
At the very least, the creation of such an application profile should not
automatically assume the continuing importance of so many of the underlying
distinctions in MARC, and carry them over just because they have
traditionally been made in libraries. "Because it is there" may be a good
enough reason to climb Mt. Everest, but it should not cause us to continue
to categorize information in one way or another without sufficient
justification. In my view, for instance, the ability to map data
"round-trip" would not be sufficient justification to create and maintain a
distinction in a DC application. That being said, I'll comment below on
some specifics in the profile.
The use of separate qualifiers for uniform titles and translated titles
seems a MARC-ish sort of distinction. Alternate title should suffice to
allow indexing of these titles. Is there some thought here that some
library-like sort and display might be possible using these distinctions?
It concerns me that these kinds of expectations may be quite unrealistic,
since they imply a complex relationship between titles that is counter to
"simple resource description." On a more positive note, I completely agree
that an instruction to elminate initial articles is the way to go.
I see some laudable effort to come to grips with the Agent elements, with a
tilt toward using creator/contributor/publisher as role instead of element
(which I strongly support). I still think that the attempt to include
"type" for any agent is misguided (the type is really an attribute of the
agent itself and has nothing to do with the relationship to the resource)
and its continuing presence makes it difficult to maintain an appropriate
separation between what is an attribute of the agent and what isn't. Where
this shows up quite clearly is in the section which tries to make sense of
"Contributor | attributes" or "Contributor | role | attributes" and cannot
quite do so. This is where I think we would all be best advised to find
some common ground on role, treat the agent attributes as a separate
problem and exercise our patience while the Agent WG comes up with a
proposal (which at least gives some hope of everyone taking the same path).
In the area of Subject, I see some areas where "type" qualifiers seem to be
suggested (Keyword and Classification) which I think are similarly
attributes of the subject scheme, not the resource. If an application knows
enough to be able to interpret LCC, surely it knows that it is a
classification scheme? If it doesn't, a "type" qualifier would be of little
help. Similarly, an unqualified subject is likely to be treated by an
application as a Keyword "type" subject, as is any containing a scheme that
it does not recognize. Why then do we need to add these
qualifiers? Subject.Personal; Subject.Organization, etc. have the same
problems mentioned in the previous paragraph. They are unlikely to be
distinquished in most indexing for DC applications--why then maintain the
distinction? I suspect that most other DC applications are putting
geographic subjects in Coverage.Spatial, and I think it would be
detrimental for libraries to do otherwise.
As for the open questions, I would say NO, the subject element should not
be mandatory (how then would you use it for preliminary records or those
where the language is not understood?). And YES, subject should always be
allowable in unqualified form, to be available for simple keyword indexing
if nothing else.
Under subject encoding schemes there is a question about an additional
qualifier (identifier) to link to a registry where encoding schemes are
defined. Since any element can include a URI or a text string, a valid URI
should always be allowable. And, presumably, when linking to authority
files is possible it will be unlikely that the a separate element will be
needed for the link to the registry, as the URI representing the value
should include that already? Of course, I'm speculating, but as we all are
to some extent on this issue, doesn't that argue that a qualifier of this
kind is probably premature?
It seems confusing to me that there should be separate DC-Lib subject
encoding schemes when the DC Usage Board has already determined that there
will be registration available for most if not all useful encoding schemes
needed by users. Is there some other reason why these are here?
Description | review strikes me as ill-advised. A review of something is
related, and might usefully be linked via a the relation element, but it is
not necessarily a description of the item itself--and it quite clearly
violates the one-to-one rule.
I have no difficulty with the notion of creating a separate type list--this
is in fact what many communities are doing. I think there should, however,
be an instruction to use BOTH the DCMIType and the DC-Lib list, or if only
one, stick with DCMIType. This will vastly improve interoperability, for
very little cost.
I was concerned to see a variety of suggestions under Format that would
tend to introduce variations that would reduce interoperability for data
created under this profile. Why not use unqualified format for any format
notes (perfectly legal in unqualified DC), and leave Extent and Medium
essentially as they are? Not perfect, of course, but it is certainly
simpler and easier to explain.
I see no real point in an "invalid" qualifier for Identifier. Even if
invalid it identifies, and is indexed--and discovery is thereby served.
Including Holdings in here boggles my mind--how does this relate to the
discovery of the resource, or any of the possible uses described in this
document? This seems so far outside the scope of the other elements that I
question its presence at all. Surely we are not trying to recreate
bibliographic utilities with DC?
*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*
Diane I. Hillmann
Metadata Specialist
National Science Digital Library Project at Cornell
Department of Computer Science Voice: 607/255-5691
419 Rhodes Hall Fax: 607/255-4428
Ithaca, NY 14853 Email: [log in to unmask]
*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*
|
