It might be useful for MACAR also to make it clear to those interested in using this list that using it does not preclude them from using other "type" vocabularies as well.

Indeed, DCMI recommends that multiple "type" vocabularies be used when a resource consists of multiple mixed types then multiple "type" terms be used. In particular, for the sake of interoperability, these multiple types should include a standard DCMI Type.

The DC Usage Guide says of the DCMI Type term:

4.4. Type

Label: Resource Type

Element Description: The nature or genre of the content of the resource. Type includes terms describing general categories, functions, genres, or aggregation levels for content. Recommended best practice is to select a value from a controlled vocabulary (for example, the DCMIType vocabulary ). To describe the physical or digital manifestation of the resource, use the FORMAT element.

Guidelines for content creation:

If the resource is composed of multiple mixed types then multiple or repeated Type elements should be used to describe the main components.

Because different communities or domains are expected to use a variety of type vocabularies, best practice to ensure interoperability is to include at least one general type term from the DCMIType vocabulary in addition to the domain specific type term(s), in separate Type element iterations.

Examples:

Type="Image"
Type="Sound"
Type="Text"
Type="simulation"

Note: The first three values are taken from the DCMI Type Vocabulary, and follow the capitalization conventions for that vocabulary. The last value is a term from an unspecified source.

The item described is an Electronic art exhibition catalog:

Type="Image"
Type="Text"
Type="Exhibition catalog"

Note: The first two values are taken from the DCMI Type Vocabulary, and follow the capitalization conventions for that vocabulary. The last value is a term from an unspecified source.

The item described is a Multimedia educational program with interactive assignments:

Type="Image"
Type="Text"
Type="Software"
Type="InteractiveResource"

Note: All values in this example are taken from the DCMI Type Vocabulary, and follow the capitalization conventions for that vocabulary.

UK's Scholarly Works Application Profile takes care of this OAI interoperability requirement by declaring all of its scholarly text vocabulary terms to be subtypes of the DCMI Type, 'Text'.

So when one uses the MACAR type "cartographic material", it is also a good idea (even "best practice") to additionally use the DCMI Type term "image" or "still image". Similarly the MACAR type "data holding" should be accompanied by the DCMI type "dataset".

The reason for including the DCMI vocabulary alongside the MACAR one is to maximize interoperability. Wherever the OAI protocol is found, there the "simple" DC terms will be understood and processed.

MACAR included non-academic library representatives but my memory tells me they were not as active as those from the academic scene.

Now I have joined the National Library Board of Singapore (NLB) and am making decisions affecting metadata across the entirety of Singapore's national and public libraries I have had to face up to just how limited in focus MACAR's past work has been. It is a pity the membership was not more evenly balanced between academic and public/state libraries. On the other hand, maybe progress is best happening when it is made a small step at a time.

At the NLB a preliminary list of resource types for the national and public library sectors has been prepared. It contains over 50 resource type terms. Some of those will almost certainly be merged, but the list will be a lot longer than the current MACAR list.

With some of the MACAR members now working with ANDS, and MACAR coming under the umbrella of CAUL, one might expect MACAR to be entrenched further with research and academic library requirements.

I wonder if there are any realistic chances of national libraries cooperating with each other and even with academic libraries, and if there are real benefits to be gained by their doing so. Since moving into the national and public library sector I think there are real potentials for users if it could happen. To expose and share the specialist heritage and wider cultural collections that such libraries house, especially alongside libraries dedicated to research and education, can only be A Good Thing.

I could use the MACAR website resource type, but I don't think its terminology or definition captures the fact that the objects I'm describing are entries or parts of something bigger.

Has anyone else encountered such material, and how have they dealt with it?

For Images - I should use 2 different resource types:

• still image
• moving image

Expressed as above, and not

• image (still)
• image (moving)

Use Still Images for : photographs, paintings, drawings, digital images (art), posters, postcards, etc
Use Moving Image for : movies, videos, TV program, animations, etc

Can you confirm that the these 2 resource types are the total number of types for images, i.e. that these 2 types should cover most things encountered at the moment?

And lastly, if I have images that are individual or mulitple pages from a manuscript (scanned/photographed) which resource type would you recommend? Does 'Still image' cover textual representation?

4.1.DEST category code

It was agreed that this code could be recorded and stored in a resource type or genre property and values could be assigned from a DEST category code vocabulary. Category code definitions should also be provided eg A1 – Book ; C1 – Journal article B1 - Book chapter etc

• MACAR recommendation: Use type/genre property/field. Best practice is to use a controlled vocabulary.
• MARC : 655 field – Index Term-Genre/Form subfield a and subfield 2
• Dublin Core: dcterms:type or dc:type in simple DC
• MACAR : macar:type

Are you actually meaning we need to include the code and type in the 655 field, e.g. $aA1 - Book?
We are coding the code into "A1" into 592 and the type "book" into 655.

I don't think having a resource type "A1 - Book" is very helpful for people who don't know DEST category codes. Even if you do want the 'A1' in the resource type, I would suggest you have at the end of the field 'Book - A1' so all the books file together. Users just want to know it is a book, they don't care it is an A1 book. What is the problem with continuing to use 592?

Any further info would be good.

Fiona

You may only want to pass on one identifier to a harvester. Cannot specify which repeat a harvester might want to get. So you could identify them separately but cluster them together under a DC 'cluster' in the xsd.

Any other dientifiers needed?

Katie.

Should the page information be changed since RUBRIC no longer exists, perhaps some else can take their place?