Hi!
I don't resist to transcribe in the end of this email part of one of the
last messages from Carl.
PLEASE READ IT AGAIN!
It illustrates very well a position with which I agree 100%, and I think
that it deserves to be discussed as an issue.
I don't agree with the idea of promoting a "DC-centric culture" for metadata
approach, selling DC as the "top schema", or as "THE schema" (let's say,
like MARC is/was for library's catalogues). And probably 99,9% of you agree
with me... I must say that I never saw this seriously proposed in the DCMI
(or at least I didn't notice it...), so why am I raising it here?
Because this is the perception that LOTS of people have of the DCMES. There
is a message going around that DCMES is THE metadata format. You can hear it
always when DC is raised in workshops and meetings, and you find it very
frequently in papers and project's proposals
IMHO, it is a wrong perspective. And I'd like to hear from you how strong
should be our feelings about this... This is the issue I'd like to raise.
For example, I'm afraid that the concept of "application profiles" will
promote this misunderstanding! I think that a metadata problem has two
perspectives, that should be addressed in different contexts:
=====
A - You are in a project, you have resources that need to be described, so
you need metadata. What to do? My advise:
A1 - Specify your requirements very well!
A2 - Look around, and try to discover if there is any metadata schema
already defined that fits your requirements.
A21 - Does it exist? Good! Adopt it, as also all the tools you can already
developed for it! You're lucky!!!
A22 - It doesn't exist? Well, how much money do you have and how much strict
do you want/need to keep with your requirements? Can you afford to develop
your own metadata schema and the tools you need to process it (creation,
maintenance and usage)?
A222 - No? I'm sorry, but you really must down your requirements and GOTO to
A21...
A221 - Yes? Good! So lets do it... Solve your problem the best you can do,
with the perfect solution for you!!!!
=====
B - Interoperability! You want to give your metadata to other systems, you
want to import metadata from other systems, you want other systems to query
you!! What to do? Well, identify these systems/schemas with which you
want/need to interoperate and simply follow Carl's example (GOTO to the end
of this email!!!).
=====
So, what was the result of this? Happy clients, with the perfect solutions
for their problems. Which is the opposite of the actual scenario, where we
have LOTS of people all over the world saying "Dublin Core... yes... but it
is a pity... I need to answer to this X detail (choose your preferred
qualification here), and I can not express it in the DC schema..."
Some issues raised by Rachel in her paper about "application profiles" are
very relevant! So what happened to them here? If I am not wrong, the only
positive aspect that I can get from "application profiles" proposal is that
they "will assist collaboration amongst namespace managers". Well, this can
also be addressed here both in context B and in A21.
But why not to consider the potential benefice of a framework to support
"application profiles" in step A21? Well, what will be your added value from
that? You could be lucky and find the perfect combination of elements for
your requirements, but you'd end with a messy syntax, at least... And what
for? For nothing, I'm afraid...
So, don't we need registries? Yes, we need them! But to support mappings and
to make it possible to develop the functions to support the "GOTO to the end
of this email!!!"
So, finally, for those of you that survived until here, what is it my point,
after all?
I think that the DCMI should CLEARLY develop the DCMES (with DCq and all the
stuff we'll find useful) not to promote it as THE metadata schema, bus as I
always understood it: has a (meta-?)metadata schema to promote
interoperability, in order to make it possible, if necessary, a two-step
resource discovery process:
1 - Make it possible to any system's resource to reply to questions like
"show me the Dublin Core record for xxx" knowing that most likely the
system(s) that I am querying is/are internally richer than DCMES. Please
note the plurals in my statement. My requirement is to send these questions
to a lot of systems on the same time -like I'd like to do with Z39.50,
btw...:-)
2 - Once I choose the resource(s) I might be interested, "jump" to their
specific systems and explore them in all of their potential and glory (being
them MARC, FGDC, MPEG7, xpto...). After all, this is simply the 3-tier model
for 21century information systems that everyone has been selling... answers
came with beautiful links, with URLs, URNs, PURLS, ISSBNs, ISSNs, authors
names, etc., whatever each system was able to give me in the 15 DC
elements... I just need to click! After all, it is THE WEB!!!
And it was all folks (uf, I wrote a lot...)
Regards,
Jose Borbinha
PS: AH, please don't forget to read Carl's text in the end...
_______________________________________
José Luis Borbinha <[log in to unmask]>
Biblioteca Nacional (National Library of Portugal)
Direcção de Serviços de Inovação e Desenvolvimento
(Direction of Services for Innovation and Development)
Campo Grande, 83 - 1749-081 Lisboa - PORTUGAL
Tel./Fax: (+351) 217 982 083 / 217 982 123
----- Original Message -----
From: "Carl Lagoze" <[log in to unmask]>
Sent: Terça-feira, 22 de Agosto de 2000 12:38
Subject: RE: Applications profiles
> ...
> In my original comment on the applications profile paper [3] I offered
> an alternative to the "jigsaw puzzle" that entails thinking of DC record
> as a rather pure projection or view of a more complex description. Such
> a model distinguishes between the actual descriptions stored by
> providers, which will ultimately be more complex than those that can be
> formed with qualifying of DC elements or even with the types of
> applications profiles proposed by Rachel, ,and the views available by
> clients.
>
> This is the type of thing we are trying to do in the Open Archives
> initiative [4]. In this model we have a harvesting protocol that
> permits a dialog between a client and server such as:
>
> [client] tell me what metadata vocabularies you support?
> [service] Dublin Core, FGDC, MARC
> [client] show me the Dublin Core record for document xxx
> [service] <dcRecord>
>
> Under the covers the server may do all sorts of transformations from
> internal descriptive models to the dc record; the client is relieved of
> any burden and can consume simple dc records. Such a model similar
> allows services to support individual community needs by projecting
> other "metadata records" that conform to community requirements.
>
> In closing, I find that the discussion returns to the issue of whether
> DCES should be thought of as the foundation for native descriptions or
> as a projection and interchange format to facilitate cross-domain
> discovery. As I say here and in [2], increasing complexity (e.g.
> intermixing dc elements with others in various ways in so-called
> applications profiles or qualifying with highly structurred values) will
> interfere with the latter goal.
>
> Carl
>
>
>
> [1] http://www.mailbase.ac.uk/lists/dc-general/2000-08/0000.html
> [2] http://www.mailbase.ac.uk/lists/dc-general/2000-08/0018.html
> [3] http://www.mailbase.ac.uk/lists/dc-general/2000-08/0028.html
> [4] http://www.openarchives.org (note that the content of these pages is
> subject to revision after an Open Archives technical meeting in early
> September. Of particular interest is the revisioin of the open archives
> core metadata record to be conformant with DCES).
> ...
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
