Skip to content

Latest Additions

You are here: Home > Events > Stakeholders' Meeting, 26 June 2003 > Summary of metadata discussions

Summary of metadata discussions

Stakeholders' Meeting

26 June 2003

Need to clarify semantics of rights/license/access elements.

(Mirror Service) Problem when items within collection have varying license conditions e.g. software. Any statement made at collection-level may need to state explicitly that item-level metadata specifies terms for each item.

Agent details - drop postal address/postcode.

Where digital collections described in the IESR are collections of metadata recs (catalogues) describing physical items (e.g. library catalogues) the physical location of that physical collection may be important for the selection of the digital catalogue.

Use domain name rather than Athens prefix to describe availability of service.

Need to consider mechanism for making bulk edits to IESR metadata e.g. if institutions merge. (Consider distributed model in future?)

For Collection, require rslpcd:contentsDateRange as well as dcterms:temporal.

Need to permit use of other subject schemes e.g. RDN Faculty List (PJ - Is that the name for it?), JACS.

Also allow use of dc:subject without scheme for "keyword".

It would be useful if every CLD had a term from a single common scheme. It seemed as if JACS was the most likely candidate, but I don't think we had a definite decision on that.

Collection/rslpcd:associatedPublication - tighten up definition? What sort of publication? Help for use/interpretation of collection?

Also need attribute for pointer to human-readable document about Service. (PJ - I suggest rslpcd:seeAlso is fine for this?)

Educational level - an educator may want access to resources intended for other audiences (e.g. a teacher wants to access resources labelled for school children). Also may be more difficult to assign at collection-level than at item-level.

General point - avoid "none of the above"/"other" options in controlled vocabularies.

Long discussion about "customisation" - what services might do with metadata records obtained from the registry. Particularly broker services?

(Yes, need "global" policy re use of IESR metadata records.)

  • Filtering according to access rights of service users.
  • Extending e.g. providing more precise subject classification for known resources, so that more useful to service users.
  • Integrity issues? Creators of IESR metadata record may want to ensure that some elements of their metadata are not "customised"?
  • Provenance - may be important to signal what metadata elements provided by IESR record, what metadata elements provided "locally" by presentation service.
  • How to merge local metadata with updated IESR data. (SFX model? Does it work in practice???)
  • Different descriptions for different audiences (Resource Guides)? (Andy's point about a service downloading records and transforming them for use by e.g. a library portal package would also come in here.)

Events Sections