John Kunze wrote:
| > From: Terry Allen <[log in to unmask]> > Date: Fri, 29 Nov 1996
| > I certainly want to retain Identifier, and even though I constantly
| > mistype it as "Indentifier" the name is not unclear to me, certainly
| > not in the context of a bibliographic record and if subclassed
| > as, e.g., Scheme=URN.
|
| The name Identifier is clear to me too. If you'd like to address my
| reasons for wanting to rename it, please see the original message below.
I find it unconvincing.
| To summarize, the name Identifier is naive. First, it suggests that all
| things of type identifier _in the entire record_ go here. But the
It doesn't suggest that to me. Have you found users to be confused
in this manner?
| Relation element also holds things of type identifier, as might a future
| RightsStatement or Abstract element, or any number of elements pointing
| to Warwick Framework packages. Second, large legacy systems already use
| the name Identifier for a very different purpose (ie, unique record key).
A different usage than the suggestion you made at the outset of the paragraph.
| Why create needless obstacles to their embracing the DC?
Relation uses the concept Identifier for a different purposes, and
as a qualifier, not as content. The Identifier element can be clearly
defined as an Identifier of the thing described by the DC record. It's
been used that way, too. If the problem is that there is no place in
DC for an identifier of the DC record, that's another matter. Do
you want to add an element for that purpose?
Medline's UI would be an Identifier with Scheme=Medline.UI. There is
no obstacle here; and you cannot entirely avoid using common semantics
that may mean somewhat different things in other systems. That
doesn't mean that DC:Identifier need be confused with Legacy:Identifier.
If the three uses of the concept "identifier" in DC are not in synch,
something needs to be renamed. But they don't seem to be. If renaming
is desired to avoid confusion among those uses, I would much prefer
RelationIdentifier, etc.
Regards,
Terry Allen
|
| =====================
| From [log in to unmask] Thu Nov 28 13:19 PST 1996
| From: John Kunze <[log in to unmask]>
| Date: Thu, 28 Nov 1996 13:19:26 -0800
| To: [log in to unmask]
| Subject: RENAME "IDENTIFIER" ELEMENT
|
| The element named "Identifier" has to be renamed. There are two reasons,
| each of which by itself is enough to make the current name untenable.
|
| 1. An element is an instance of its type, not named after its type.
| The C program equivalent is to have a variable named "integer", as in
|
| int integer, n; ... for (integer=0; integer<n; integer++) ...
|
| Technically legal, this bizarre name choice suggests that this variable
| is the sole repository of things of that type, which is highly unlikely.
|
| Back to the DC, "Identifier" suggests that the element is the sole
| repository of things of type Identifier. While this is highly unlikely
| in more generic situations, we know it is untrue in the DC. We've often
| spoken of the need to refer (via URIs, ISSNs, and other identifiers)
| _from_ a variety of elements _to_ a variety of data packages external
| to DC records. For example, if Identifier is so named because it holds
| an identifier, the Relation element should also be called Identifier,
| but I don't think anyone wants that.
|
| I propose that, like the more aptly named Relation element, the
| Identifier element be renamed "Resource" as in the User Guide; the
| fact that the resource will typically be represented indirectly (by
| an identifier) is flagged by a simple qualifier, having a default
| meaning that keeps the element syntax simple. The Relation element
| (among others) can leverage this concept to make it clearer when
| element content _is_ the data, or _points_ to the data. Savvy
| metaloguers can leverage this because it gives them more control and
| flexibility in laying out records. My inner nerd wants to close
| with a final C program analogy about elements and pointers to them:
|
| typedef struct { ... } Element;
| Element Author, Title, Subject; Element *Resource, *Relation;
|
|
| 2. The second reason that the name "Identifier" is untenable is that
| large legacy systems have a legitimate claim to it, even if they've
| not heard of the DC yet. In my experience, established providers of
| real information systems -- whom we cannot afford to alienate -- rely
| critically on a unique key element in each record that identifies the
| record itself. A conflict over this key element is almost certain as
| current mainstream providers consider buying in to the DC.
|
| Generally this element is given a name having the word Identifier in it.
| Not uncommonly, it is made externally visible as an important search
| access point. An example is the Unique Identifier (UI) element of the
| Medline biomedical literature database, the world's largest citation
| and abstract database in any single domain of knowledge, and the main
| resource for all health science research. Let's not give providers of
| this kind of resource reason to keep clear of the DC if we can help it.
|
| I propose we change the name "Identifier" to "Resource".
|
| -John
|
|
