meta2: NAMES OF ELEMENTS
This discussion has made clear to me that there is not a fundamental problem
here, as in some of the other discussions (e.g. teasing apart the potential
elements of the Author field). But it also makes clear that some attention
needs to be given to the potential confusions surrounding names such as
Resource, Identifier, and Type. There seem to me to be two broad solutions
possible:
1. Make the intent and usage extremely clear in the specifications,
which they certainly now are not.
2. Change the names.
While the former is a good idea in any case, I prefer the latter solution. I
hear the arguments about how others use these terms and we shouldn't get in
their way. I'm more concerned about human usage and about using generic
terms for specific intentions. Terms such as Type and Identifier are
inherently ambiguious because intentionally non-specific.
The solution I would prefer would be to change these names to keep their
generic quality but with a label that indicates something about use.
Variations on names might include such as
InfoResource
ResourceIdentifier
ResourceDate (the present "Date" is in fact very ambiguous)
RelationType (as Terry Allen has suggested)
ResourceType (better than both ObjectType and Type, John)
ElementType (I mean this as an instance, not as a name)
or AuthorType
or DateType
or CoverageType etc etc
Generics are inherently confusing the closer they are used to actual
specifications.
I repeat that there is not a problem requiring solution here; this is a
marginal matter. As such the present terminology can go forward into 1.1 as
we talk about it more. --pg
Peter Graham [log in to unmask] Rutgers University Libraries
169 College Ave., New Brunswick, NJ 08903 (908)445-5908; fax(908)445-5888
<URL:http://aultnis.rutgers.edu/pghome.html>
|