Hi Pete,
What a welcome to a Monday morning - you’ve really made me think! And maybe
it’s just me, but I feel quite confused now about what DC records would
need to be created and how many too. So at the risk of exposing my
ignorance these are my latest thoughts on implementing the DC collections
schema.
Are you suggesting that my CLD Project is recognized as a collection worthy
of its own collection metadata record in DC? If so I would put DC.source as
“CLD Project EAD records” where the present resource (the collection
description record for the CLD Project) is derived from the collection of
CLD Project EAD records. Is this right or should the DC.source reflect the
source of data for the EAD records which would be the collections data
itself? I would put DC.publisher as “The Natural History Museum” as the
“entity responsible for making the resource available.”
For each one of my EAD records describing a collection within the museum I
anticipated creating a DC record by mapping the EAD data to DC elements.
Perhaps an incorrect assumption? If so then DC.source would be the
department (and institution) providing the collection data and DC.publisher
as “The Natural History Museum”.
Do I finally have a handle on this or am I still way off the mark?
BTW, you’re right about Owner - my mistake I meant cld.Administrator being
a sub-property of DC.publisher. I still think “publisher”, as a term is a
little strange though…
Thanks,
Rachel
At 08:28 PM 7/19/02 +0100, you wrote:
>Hi Rachel,
>
> > Sorry about the delay in responding - I worked at home
> > yesterday to avoid the Tube strike commuting chaos...
>
>... and I had to come to London yesterday just to participate in the
>Tube strike commuting chaos... :-(
>
> > I don't see it as being a problem in not making the
> > distinction but wonder if the schema definition should be changed
>accordingly? When
> > developing the EAD data entry template at The NHM I consciously
>sought to
> > map the EAD elements to RSLP and DC and would be interested in seeing
>the
> > proposed definitions extended to include the distinct EAD elements to
>clarify
> > mapping of the elements.
>
>OK... I'm not sure about explicitly referencing the EAD elements in the
>definition of the terms in this schema, but I'll look at the definitions
>of the EAD elements and see if the definitions in this schema can be
>phrased so that their "scope" is clear.
>
>Also we did say in the workplan we'd do some work on mapping/crosswalks
>and I had EAD (amongst other schemas) in mind there, so I think maybe
>these issues should be addressed there (and in the supporting
>guidelines).
>
> > BTW, are these repeatable or would it be better to
> > put everything into one element? I have collection
> > descriptions that have multiple associated collections you see :-)
>
>Yes, all properties are repeatable - though in practice it probably
>makes more sense to repeat some than others. We could tighten that up in
>the description of the application profile, if required.
>
>cld:hasAssociation should certainly be repeated if you want to indicate
>multiple associations, as the idea with dc:relation is that the value of
>the property is the identifier of exactly one related resource.
>
> > And is it just me or is it strange that the DC term to which Owner
>will map is Publisher?!
>
>Errr, not just you.... it sounds strange to me too.... ;-)
>
>Where does it say this? Looking at
>
>http://homes.ukoln.ac.uk/~lispj/dc-cd/rslpcd.html
>
>I see the term cld:owner defined without any relationship to
>dc:publisher?
>
>[Pete]
> > Are you thinking of a digital collection of items which are
> > representations of physical items which also form a collection?
>
>[Rachel]
> > Yes that plus I was also thinking of when data was
> > repurposed. For example I create collection level description records
>for The NHM
> > project but if repurposing the data for DC-Collection schema purposes
>would consider
> > recording source as CLD Project. But maybe I have misunderstood this?
>
>Taking the first case i.e.
>
>my digital collection -- dc:source --> my physical collection
>
>I'm not sure about that one..... Basically, it's not in the schema as
>proposed (though with the more general definition of hasAssociation it
>could be a recorded there as a non-specific association with another
>collection). I think really that dc:source relation is at the item
>level.
>
>Taking the second case, I think it would be incorrect to use dc:source
>like that in your CLD. Firstly, a CLD metadata record is describing a
>collection, whereas I think you are actually describing an attribute of
>the CLD itself. i.e "this collection-level description was originally
>prepared by CLD project".
>
>So you'd need to make this statement in a separate metadata record about
>your CLD, not as part of the CLD itself. You could create a DC-based
>metadata record for this purpose, but I'm afraid even then dc:source
>wouldn't work quite the way you suggest.
>
>dc:source is defined as "a reference to a resource from which the
>present resource is derived" [1].
>
>So the dc:source of your new CLD would be your earlier EAD document, and
>you might say something like:
>
>my DC Collections CLD -- dc:source --> my EAD document
>my DC Collections CLD -- dc:publisher --> my new CLD project
>
>And in a third metadata record about your EAD document:
>
>my EAD CLD -- dc:publisher --> my original CLD project
>
>It's a bit laborious, but I think it illustrates this fundamental
>principle that a DC metadata record should describe exactly one
>resource. In the case of a CLD, that resource would be an aggregate but
>it's still one resource.
>
>Once you start bending that rule things quite quickly fall apart, I
>think! ;-)
>
>Cheers
>
>Pete
>
>[1] http://dublincore.org/documents/1999/07/02/dces/
***************************************************************************************************
Rachel Perkins
Collection Level Description Officer
Department of Library and Information Systems
The Natural History Museum
Cromwell Road, London, UK
SW7 5BD
020 7942 5646
[log in to unmask]
|
