On Tue, Dec 2, 2008 at 3:54 PM, Prue Deacon <[log in to unmask]> wrote:
>
> I welcomed the original Dublin Core because of the simple framework and the
> straightforward DC dot notation for embedded metadata in HTML pages. As
> well as being machine-readable (our system has no trouble harvesting DC
> dot), it was also concise and human-readable. This made it easy for me to
> explain the coding to people in our partner organisations - the people who
> create and update metadata records for us range from highly experienced
> cataloguers down to administration officers - simplicity is vital.
And the big challenge for all metadata is to balance the inherent
complexity of the information with the need for simplicity; simplicity
for metadata creators as well as for the users. I wasn't involved in
the early development of DC, but I suspect that the complexity of
library metadata had sent many running in the opposite direction.
Perhaps too far.
>
> Dublin Core has become far more complex with the move towards more
> semantically-correct coding and RDF. I can see that this might be useful
> for some communities within Dublin Core but for me it is horrible. I do not
> understand much of the documentation (eg the DCMI Abstract Model) and I do
> not have time to undertake the study required to interpret it. The changes
> in terminology (eg element, description) are particularly confusing. The
> DCAP document is more readable but I do not think I will need to create a
> HealthInsite application profile because we follow AGLS.
I hadn't known about AGLS, so I had a look and it's interesting how
close it is to DC. Close, but... which is part of the motivation
behind application profiles: that no matter how carefully you design
YOUR metadata, no one else is going to have exactly the same needs. So
in a sense, all metadata schemes end up being profiles for a
particular set of needs. What I think we gain with the DC application
profile standard is that it gives us a structure within which we each
can define OUR metadata. That will include some engineering aspects,
but it must also include what many of us call "cataloging rules." I
think that lack of cataloging rules is what caused difficulties for
the original DC 15. Sure, anyone could use their own rules, but there
wasn't a good way to let people know what your rules were. A general
standard for laying out our various metadata choices is definitely
needed. DCAP goes in that direction.
I agree with your assessment that the purely formal, structural
aspects of RDF will do little for us if there is no quality control
over the metadata content. Somehow we need to marry those two. You
might have seen that we are experimenting with creating a formalized
version (I don't know what else to call it) of the data elements of
the upcoming cataloging rules, RDA. You can see a bit how this looks
by going to: http://metadataregistry.org/schemaprop/list/schema_id/1.html
and looking at some of the entries, many of which should look
familiar, like "Title." Behind the scenes there is an RDF record, but
there's no reason anyone should see that except a computer
application. We are working to link these formal definitions right
into the cataloging rules (which will be presented online). In this
way we hope to get both the formal structure and the rules for data
quality together. We are basing our work around actual cataloging
situations (http://dublincore.org/dcmirdataskgroup/Scenarios) -- which
we are building up as we go.
It's all quite experimental at this point. But it's starting to look
more real to me. I'm hoping that we can hide the difficult details
behind nice interfaces. Admittedly, much of it is pretty unattractive
at this stage of the game.
>
> I would be interested to know if there are other sites using legacy
> implementations of DC.
>
From what I understand, there is a pretty broad use of DC both in
libraries and in non-library situations. DC is used, for example, in
the Creative Commons licenses. It is also used heavily in academic
institutions that have digital repositories and use the OAI-PMH
protocol to exchange metadata. Others here may have a more
quantitative assessment of its use, but it seems to me to be quite
diffuse.
kc
--
-- ---
Karen Coyle / Digital Library Consultant
[log in to unmask] http://www.kcoyle.net
ph.: 510-540-7596 skype: kcoylenet
mo.: 510-435-8234
------------------------------------
|