Exactly what is the difference between "guerrilla DC" and
"extensibility," which is supposed to be one of the major features of
DC?
Also, once DC has calmed down and is accepted, we'll all have to face it
that each developer will use it in his/her own way. Whatever guidelines
we come up with will have little to do with what goes in there.
Corporate sites will do whatever they can to hock their wares, porno
sites will use it to their own advantage, nihilist groups such as the
"Trench-Coat Mafia" will also use it. And they all realize that if their
site isn't in the top 40-50 results, it may as well not exist. I'm sure
that these clever people will come up with uses for the Dublin Core that
we can't even dream about right now.
This will be the reality of the situation. In libraries, the catalog has
been tightly controlled by responsible people, but on the web, this
cannot even be hoped for. If we make our own search engines with our own
rules and procedures, there may be a chance.
Jim Weinheimer
Princeton University
[log in to unmask]
[log in to unmask] wrote:
>
> I'm concerned about this whole business of "guerrilla DC". I don't know how
> enforceable this whole thing is, but it seems to me to be unacceptable to
> have specialist groups unilaterally appropriating the DC prefix. (Although
> I guess you could argue that "DC-CHEM" is a completely separate namespace
> from "DC" [or "dc"] and that it doesn't imply official DC endorsement.)
> It seems to me to be legitimate to use a DC prefix only when one is
> proposing a local subelement to an already-established DC element, e.g.
> DC.Title.Alternative or DC.Date.Modified. If one wants to use a local
> extension that doesn't seem to fall within the DC set, the namespace
> identifier (for want of a better term) should not be blessed with DC - for
> example, GEM.cataloging, GEM.grade, GEM.audience, IMS.Concepts,
> IMS.Granularity. (You could of course also argue that all of these could be
> dealt with as subelements to a DC element, falling back on DC.Description
> if nothing else, but this isn't what GEM and IMS have done.)
>
> In what way is DC-CHEM a Dublin Core set? Most of the fields seem to fall
> within DC.Subject subelement extensions.
>
> We can't have everyone claiming every metadata set to be DC - it makes a
> nonsense of its "coreness".
>
> If DC (or dc) becomes a registered namespace, does that mean we can have
> some say in who else uses DC in any sort of prefix, or is this tilting at
> windmills?
>
> Cliff Morgan
> Publishing Technologies Director
> John Wiley & Sons Ltd
> Chichester, UK
>
> "R. Wendler" <[log in to unmask]> on 10/05/99 21:18:10
>
> Please respond to [log in to unmask]
>
> To: [log in to unmask]
> cc: (bcc: Cliff Morgan/Chichester/Wiley)
> Subject: Re: DC-Chem
>
> Is there any movement toward registering these topical DC "expansion
> packs" someplace central to reduce redundant wheel design? The
> projecy registry on the DC home page is a nod in that direction, but
> doesn't quite get it. (Yeah, I know this isn't a new topic... I've
> just lost track of it.)
>
> Thanks,
> --Robin
>
> On Mon, 10 May 1999, Frank A. Roos wrote:
>
> > FYI.
> >
> > I came across these slides on the
> > Web:http://krypton.ch.ic.ac.uk/alan/work.html and
> > http://krypton.ch.ic.ac.uk/alan/work1.html
> >
> > The use of DC is analysed against using DC-Chem (not surprisingly a
> > proposed chemical extension to the DC) against not using any metadata
> > and against using both metadata sets.
> >
> > This work has apparently been done by the Dept. of Chemistry at the
> > Imperial College in London.
> >
> > --
> >
> > Frank A. Roos
> >
> >
> >
> >
>
> Robin Wendler ........................ work (617) 495-3724
> Office for Information Systems ....... fax (617) 495-0491
> Harvard University Library ........... [log in to unmask]
> Cambridge, MA, USA 02138 .............
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|