On Fri, 29 Nov 1996, John Kunze wrote:
> Again, I didn't see this on the meta2 list so I'm replying to you.
> Feel free to forward to the list.
OK, I have done.
> > From [log in to unmask] Thu Nov 28 16:12 PST 1996
> > On Thu, 28 Nov 1996, John Kunze wrote:
> > > 1. An element is an instance of its type, not named after its type.
> > >[...]
> > > Back to the DC, "Identifier" suggests that the element is the sole
> > > repository of things of type Identifier.
> >
> > That's exactly what its for though; its there to hold identifiers that
> > help us name and/or locate the resource. Things like URIs, FPIs, etc. As
> > you've already suggested ditching the identifier qualifier which nobody
> > was using anyway there isn't a clash.
>
> I think you may have missed the key word, "sole". If I take what you say
> literally, that the Identifier element is the only element in a DC record
> that can hold things of type "identifier", it has rather devastating
> consequences.
Ah, I never even noticed "sole" in there. I must admit that it never
occured to me that just because we have an element called Identifier which
we use for identifying the resource that it would imply that we couldn't
have identifiers for relationships or whatever in other elements. I can't
see a problem with that at all. Doesn't it seems strange that we've
lasted this long without really confusing anyone?
> For example, this prohibits the Relation element from holding identifiers;
> its main purpose thus denied, I'd expect a general cry to drop it.
We've been through this loop already and the general cry appeared (to me
at least) to be to keep it.
> Similarly, a central tenet of the Warwick Framework would have to be
> dropped, since the WF calls for referencing (via URIs) a variety of
> objects from a variety of elements.
Er, no. Warwick Framework _isn't_ Dublin Core. Warwick Framework can
_contain_ Dublin Core but its doesn't require Dublin Core (or any other
metadata it carries) to support external references. If they do then
that's fine, but WF doesn't rely on it. Of course WF may _itself_ refer
to external metadata packages but that's none of Dublin Core's business.
> > > 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.
> >
> > To my mind Identifier is so name because it hold one (or more) identifiers
> > to help us name and/or locate the resource. Simple as that. I can't see
> > what the problem is.
>
> The problem is not that this element holds identifiers, or that it holds
> only identifiers. But that it appears to be the only element in the whole
> record that can hold identifiers. This is what its name suggests.
Not to me it doesn't.
> > > 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.
> >
> > That doesn't sound very simple to me. What's wrong with the current
> > default of:
> >
> > Identifier: http://www.roads.lut.ac.uk/Metadata/DC-SubElements.html
> >
> > Now that does seem simple and the element is doing what it says its doing.
> > Resource could mean that the string is the actual resource (as is
> > possible in SOIF templates). Not a good path to go down IMHO.
> >
> > > 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.
> >
> > Er, how exactly does being able to include the document with in the
> > metedata (which could then be included in the metadata recursively ad
> > infinitum) help layout records? Sorry, but this sounds hugely bogus to
> > me.
>
> You refer to a very fringe application. The flexibility that savvy
> metaloguers can leverage applies much less to the Resource element
> than to elements that vary between medium weight and heavy weight,
> where indirection counts, eg, with an Abstract, or Copyright element.
Er, I didn't refer to an application, fringe or otherwise. I asked how
being to embed documents within the metadata (which is what you originally
proposed) helps the metadata providers. I can't see that it does.
Inserting a full abstract or copyright statement is a completely different
thing (for one thing they're very often likely to be _much_ smaller than
the full document). So once again; how does being able to embed the
document within its metadata (with associated nasty recursive issues) help
metadata providers layout their records. I don't think it does.
> > > 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.
> >
> > Lots of legacy systems have claims to Date and Language and Title as well.
> > The point is that when legacy systems interact via DC they do so using
> > translators that will map from their internal structures to DC structures
> > where possible. So it doesn't matter what its called in DC as long as the
> > guys writing the translators understand the semantics involved. So this
> > argument doesn't seem to stand up to me.
>
> Names are important psychological and political symbols. The mappings
> you describe are trivial technical problems, but consensus and buy-in
> present difficult, non-deterministic problems.
If we start letting psychological and political issues influence us too
much we're headed for ISO territory and stagnation. Every name we choose
is going to step on someone's toes. Are we going to ditch Date and
Language and Title and all the other 13 elements as well? I think that if
we can demonstate significant advantages in providing DC metadata and
trivial mapping algorithms then hopefully lots of people will use 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 can't see Medline or SCI or anyone else with an existing, high quality,
> > specialised set of metadata search entry points being too interested in
> > DC. Why? Because DC is a lowest common demoninator and they'll probably
> > already have all the metadata elements from DC plus more besides. And
> > anyway, Medline's "Unique Identifier" could just become a Scheme qualifier
> > value in DC if they really wanted to export it to other service via DC.
>
> That may be. Several large vendors have shown interest in providing dumbed-
> down search interfaces to their data. If we make it hard, I'd hope we have
> a good reason.
I don't see that having an element called Identifier is making it hard at
all, either for the providers, the searchers or the indexers. If all the
indexers start using DC for "dumbed down" search interfaces then they'll
probably use wildcards for the qualifiers anyway so you'd get your Medline
"Unique Identifiers" back out OK still.
Tatty bye,
Jim'll
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Jon "Jim'll" Knight, Researcher, Sysop and General Dogsbody, Dept. Computer
Studies, Loughborough University of Technology, Leics., ENGLAND. LE11 3TU.
* I've found I now dream in Perl. More worryingly, I enjoy those dreams. *
|
