Pete,

Sorry about the delay in responding - I worked at home yesterday to avoid 
the Tube strike commuting chaos...

At 08:42 PM 7/17/02 +0100, you wrote:
>Rachel,
>
> > Looking a little more carefully at the list of elements in the RSLP
>schema
> > I recognize that some of them may well have been influenced by EAD?
>
>Probably more by ISADG than EAD, I suspect. See
>
>http://www.ukoln.ac.uk/metadata/rslp/isadg/
>
>but yes, by archival approaches to description certainly.
>
> > Given that
> > and the bias created by my experience with EAD I offer the following
>comments.
>
> > 1.      cld.custodialHistory  Am I correct in assuming that there is
>no
> > distinction between “immediate source of acquisition” and the history
>of
> > acquisition, a distinction that occurs in EAD as <acqinfo> and
><custodhistory>?
> > Is it necessary to make that distinction in RSLP or amalgamate all
>such data?
>
>You are correct. The schema proposed here (and the RSLP CD Schema on
>which it was based) does not make that distinction.
>

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.

> > 2.      cld.accessControl  Similarly, in EAD, there are two separate
>elements
> > for <accessrestrict> (“conditions affecting the availability of the
>materials
> > being described”) and <userestrict> (“conditions that affect use of
>the described
> > materials after access has been granted”). In the RSLP schema, is it
>necessary
> > to create a separate element for <userestrict> data or can both types
>of data be
> > recorded in cld.accessControl or should <userestrictions> be ignored
>(although not
> > an option I favour)?
>
>Again the schema proposed here does not make the finer grained
>distinction which is present in EAD. I think I'd suggest that if you
>were mapping from EAD to this schema both ead:accessrestrict and
>ead:userestrict would map to cld:accessControl.

Here again I would suggest extending the schema definition.

>This (and the point above) means a reverse mapping doesn't work, of
>course.
>
>I don't think it's a _requirement_ to replicate exactly the descriptive
>capability of EAD in this schema, but finer-grained properties could be
>defined if required.

Replicating EAD would be a unnecessary. I think pragmatically extending 
some of the collection schema definitions would be beneficial though in 
some cases to aid mapping from other schemas.

> > 3.      cld.hasAssociation  According to the RSLP definition, data
>captured
> > in the EAD element <relatedmaterial> (“material not physically /
>logically
> > included in material being described” but associated in some way)
>would not
> > be captured in this field. Data captured in the EAD element
><separatedmaterial>
> > (“materials associated by provenance …but physically separated”)
>however would be.
> > In the RSLP schema, is it necessary to create a separate element for
><relatedmaterial>
> > data or can both types of data be recorded in cld. hasAssociation or
>should
> > <relatedmaterial> be ignored (again not an option I favour)?
>
>Urgh. I think that in the RSLP CD Schema that property was inherited
>from the 1993 version of ISAD(G) which distinguished between "Related
>units of description" in the same repository, and "Associated material"
>associated by provenance, and it looks as if it is the latter which was
>implemented in the RSLP CD property associatedCollection. (The most
>recent version of ISAD(G) just talks about generically associated
>"Related Units of Description".)
>
>The Heaney model identifies a more general has-Association relationship
>with another collection, and I think what is what is needed here,
>especially given that we want to describe collections not defined by
>provenance?
>
>So I propose that the definition of the associatedCollection property in
>the proposed schema should be changed to something more generic along
>the lines of:
>
>"The identifier or name of a second collection that is associated with
>the current collection."

Sounds like a good idea. 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 :-)

>With this definition, both ead:relatedmaterial and ead:separatedmaterial
>would map to cld:hasAssociation.
>
> > 4.      cld.Owner  Thinking back on my experiences in archaeology
> > in Canada I wonder if the term “Repository” would be more politically
> > correct than “Owner”? For archaeological remains of the First Peoples,
> > the Canadian Museum of Civilization was one of the repositories for
> > such material, not the owner. Anticipating international use of the
> > RSLP schema and still not having lost that Canadian pc perspective
> > despite being here for four years now I wonder if “Owner” would cause
> > offence.
>
>I take your point. But in the proposed schema there _is_ an explicit
>distinction between the repository (the location of the collection) and
>the owner. It's not assumed these are the same.
>
>So taking your example the Canadian Museum of Civilisation would not (in
>a politically correct metadata instance record) be described as the
>owner of the collection, it would be recorded as the location of the
>collection (or perhaps strictly speaking the Museum-as-institution is
>the agent who administers the location of the collection - but the
>schema as it stands is limited to properties of the collection).
>
>Of course another less politically correct instance creator might choose
>to say the Museum _was_ the owner... ;-)
>
>Does that answer your question, Rachel? Or are you suggesting that the
>schema shouldn't represent the "ownership" of a collection at all? The
>RSLP model does have a library/archive basais, I think, but ownership
>will be significant for some classes of collection, I think?

Users will expect "ownership" to appear. Admittedly the distinction is made 
primarily by the professionals.  Being from a museum and archaeology 
background I tend to think of museums as "caretakers" rather than "owners" 
hence my suggestion of using the term "repository". And is it just me or is 
it strange that the DC term to which Owner will map is Publisher?!


> > 5.      Perhaps it’s just me but I don’t seem to be able to find the
> > DC.source in the RSLP schema. I can think of instances where capturing
> > DC.source information would be useful.
>
>I'm not quite sure what the dc:source of a collection would be? Could
>you give an example of what you have in mind? Are you thinking of a
>digital collection of items which are representations of physical items
>which also form a collection?

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?

>Thanks
>
>Pete


Regards,

Rachel



***************************************************************************************************

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]