On Thu, 9 Aug 2001, Diane I. Hillmann wrote:
> At the very least, I hope it will provoke some discussion (which I'll read
> when I get back) ... ;-)
FWIW, I tend to agree with all of Diane's comments. In particular, I very
much endorse the comments about the proposed role, type and attributes
qualifiers for Contributor which seem to be totally broken to me.
Andy.
> 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]
> *~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*
>
Andy
--
Distributed Systems and Services
UKOLN, University of Bath, Bath, BA2 7AY, UK [log in to unmask]
http://www.ukoln.ac.uk/ukoln/staff/a.powell Voice: +44 1225 323933
Resource Discovery Network http://www.rdn.ac.uk/ Fax: +44 1225 826838
|
