I recall that meeting. Am having doubts that the time is right for national/public libraries to be actively involved with MACAR. Pity. Potential is huge for sharing info. But I've come to think that the unique dynamics in the research/academic/ed sectors are what made MACAR possible in the first place. Academics move around and it is vital for researchers to exchange data and publications etc etc. Sharing of efforts and coop projects would seem be a natural outgrowth of that environment. Nothing like that among national libraries, which are focused more on managing their own resources and serving their immediate constituencies. Their sheer size, too, means they have more legacy issues and systems to negotiate than the academic libraries with which I worked.

I suspect national libraries will only be in a position to embark on the sorts of sharing and coop found among the scholarly/research community when they become even more established in their various digital projects and reach till they reach a point where they can look around at others and say, "hey, look what we've got —- anyone want to share? you have similar? can we exchange?" Many snazzy things are being done, but there is still a long way to go, it seems, before they will reach that point.

Neil

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.

However we need a resource type that will cover the record for the actual collection which is a research output collected by our Research Management system.
The research outputs are:

1. Individual exhibition of original art; substantial collection of original works by an individual artist exhibited for the first time in a recognised gallery or museum.
2. Representation of original art: collection of at least three original works by an individual artist exhibited for the first time in a recognised gallery or museum.
3. Curatorship of major exhibition not featuring creative work by the curator, or production (including recording), selection, remastering supervision or booklet authoring of CD recordings.

The first 2 could be covered by 1 resource type, but I need a separate one for the 3rd output.

I can give more information if you require. Fiona

I will bring this up with ANDS.

Would someone like to comment on the possibility of establishing a new resource type, "field notes"? At Monash we are processing 4 sets of field notes and feel that none of the existing MACAR resource types fit. These notes are unpublished and informal.

I did a search in a number of repositories and compiled the following list of resource types used (MACAR resource types are asterisked). I'm wondering how complete the list is, and would people like to add to it, any resource types they are using or would like to use?

book chapter*
book*
cartographic material*
conference abstract
conference item*
conference paper*
conference poster
dataholding*
dataset*
discussion paper
draft
image
interactive resource*
journal article*
learning object
lecture
literary and artistic work
manual
moving image*
multimedia*
musical score*
newspaper article
non text media
other
patent*
preprint/postprint & refereed/nonrefereed report*
research paper/report
review*
rich media
scholarly text*
seminar lecture
small-sized dataset accompanying paper/article/report
software*
sound*
still image*
survey
technical report
text
thesis (PhD)
thesis*
website*
working paper*

Thanks

Julie

Definition: A collection of connected files or webpages, or a single webpage, along with integrally linked files such as graphics, sound and multimedia files, that can be accessed via a domain or subdomain on the internet.

Notes: If a website (and especially a webpage) possesses the characteristics of another resource type, prefer that resource type. For example, journal article, review, etc.

So we are looking at the concepts of technical FRBR manifestations that are not manifest, of resources that are not real, of resource entities that may not really exist — except as an xml datastream linking to a host of other uri's and a series of commands for certain software to display it in certain configurations — and even those display configurations may well be variable, never constant. For example, is an xml datastream might be viewable as pdf or html or other, and the user has the option of deciding this without ever actually seeing the "original document", which is the xml datastream.

The answer is not with us yet. We don't know what it will finally be. It may well be that RDF and ORE — and the Semantic Web — will force us into new ways of conceptualizing "resources" and "resource types".

In the meantime, I would think the safest option would be to store and describe etc webpages the way LOC's Minerva does (www.loc.gov/minerva/). And then be prepared to mark such collections with a sign, "Watch this space!"

Neil Godfrey

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?

welcome.

Foreclosed Homes

• image (still)
• image - still
• image:still
• image : still
• image/still
• still images
• images (still)
• images - still
• images:still
• images : still

The Vocabulary definitions for the two types are:

still image – A static visual representation.
Source of term: DCMI, ADS
Source of definition: DCMI
Note: Examples include photographs, paintings. drawings etc. Assign the type text to images of textual materials.

moving image - A series of visual representations imparting an impression of motion when shown in succession.
Source of term: DCMI
Source of definition: DCMI
Note: Examples include animations, movies, television programs, videos, zoetropes, or visual output from a simulation.

These two types do cover most images, with the exception that if it is an image of a map then you should use cartographic material. If it is an image of a musical score then you should use musical score.

The question about text is answered in the note for still image. If it is a scanned image of text, then use text. If it is an image included as part of an object with text and images, it will depend on the predominating type and whether you are treating it as one compound object. The notes on multimedia might help here:

multimedia - a complex resource expressed through multiple forms eg text, audio, and/or visual form.
Note: If a single media type predominates or is a substantial part of the resource use the single media type eg text, sound, moving or still image. If more than one type applies use multimedia.

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?

Any list is going to have its shortcomings. We are all too well aware of the issues in confusing type and format and genre and content and carrier. From our work though, and from what the NLA tells us about their harvesting, we see that inconsistency in terminology for resource types is rampant, and that this leads to problems in retrieving and presenting clustered results For harvesting/aggregation to really work well the solutions are: a) for the harvester to develop a multiplicity of scripts to map from all the variations and permutations out there to something consistent (which they are understandably reluctant to do), or b) for some consistency to be applied among the repositories.

We have a chance at this stage in repository development to have a stab at consistency. If there are types missing then we can add them, but we are trying to achieve consistency in terminology for the types that we have.

Of course there are some repositories which already contain data that has non-MACAR resource types. Should they be changed? In VITAL repositories those values could be changed using the FABULOUS. Or the data could be left as is, and perhaps some mapping tools developed.

Is there a need? We think so. Are there gaps? We know so. Should we keep going? We think so, and will take all suggestions very gratefully.

It should include terms that are sufficiently granular and yet not be so long that it is unwieldy and difficult to apply.
It should include terms for content (e.g. "moving image") and also terms for different types of scholarly text (e.g. "conference paper") that are commonly used to describe research output.
It should be interoperable with other metadata schema, e.g. DCMI.
It should be flat list and not hierarchical as the terms are easier to record in the metadata record.

The MACAR group took a practical approach rather than a purely logical one. We felt that other levels in a hierarchy and other concepts (e.g. genre) can be recorded in the metadata.

It's interesting to note that institutions responding to the survey on use of the MACAR list have said that they intend to apply it in their repositories.

If the purpose of "type" is accurate description of an item, then some of these types are too broad to be useful. Although I will allow that there is a hierarchy of possible types, and a broad term is sometimes the best we can do. You don't have any of these, but I think a reasonable subset of any hierarchy, by way of example, should be Creative work -> Novel/Short story/Musical composition/Musical performance/etc. We have all of these and more in our repository. If you want accuracy in the metadata, then you need types which include that level of detail.

Secondly, you are confusing type with format to some extent. "Sound", "Still image" and "moving image" are all formats, in a broad sense. (And again, there is a clear hierarchy in format from, e.g. "image" to "jpeg" etc.) Sound is particularly useless. Is it a voice recording? Music? Bird song? A recording of a musical performance would be better to have a type of "musical performance" rather than sound, since the performance is the thing described, and the recording format somewhat incidental.

Given that we have a music school here, we need a number of types relating to music: composition, score, performance, … Other repositories are going to have different needs, depending on their collections. So I think attempting a definitive list of types is possibly doomed, or at least destined to be a much longer list than yours.

What would be useful. perhaps, is for repository systems to allow for multiple types to be added to an item, reflecting a hierarchy and a variety of needs.

Apologies for the length here. Hope it's useful.

• J1 and J2 Creative work
• J3 and J4 Exhibition
• J5 Exhibition Curatorship

I don't think multimedia would meet our needs for Exhibitions.

Simon Porter said:

…. the DEST category code could be derived from other metadata against the record at reporting time. This would be a nontrivial exercise, but it would be an alternative to essentially translating information that is already in the record at data entry time.

One of the reasons that deriving DEST category codes might be a good idea if you were considering using a repository for HERDC reporting is that in most publication reporting systems, the attribution of DEST categories to publications is highly controlled and audited. One of the reasons for this is that these DEST codes have an impact on the amount of funding that is returned to a University. The assignation of DEST category codes is often entered by administrators, and then signed off on by heads of department. (This at least is the University of Melbourne experience). If this sort of workflow is difficult to implement in a repository, then deriving the DEST category codes from publication metadata using established business rules might be a more appropriate method of enforcing rigour around the reporting of DEST category codes.

Tom Ruthven replied:

UNSW uses a similar assignation of DEST codes as University of Melbourne (entered by administrators, and then signed off on by heads of department). However, as the codes are auditable information I’d prefer to store the code used for the DEST return rather than re-calculate it for an auditor. Initially the code could be calculated but I would prefer it to be stored as the code.

Angela Lang asked how the calculation might be done.

Katie Blake answered that it might be something along the lines of IF resource type=journal article AND type=peer-reviewed THEN DEST Category = A1

Simon Porter responded that

For journals it would probably end up being:

IF resource type=journal article and journal name belongs to a pre approved list THEN DEST category = Blah

The reason there might need to be a pre approved list is that in general the university is responsible for coordinating what it considers to be a peer reviewed journal. Having a pre approved list is another way of putting a control process around the process of deciding what is considered as peer reviewed for the purposes of DEST reporting. Up until 2006, DEST maintained a pre approved list…

I think the rules would get pretty tricky pretty quickly, but I raised it mostly to make the point that recording the code is probably the easy bit. It’s enforcing all the business processes around the recording of the codes that might make the use of a repository as a sole HERDC reporting device very challenging.

Tom raised auditing, which is a good point. After a head of department has signed off on the records, those records cannot be changed without an audit trail that results in a hod re approval step. I’m not sure how this would be managed purely in a repository environment. Happy to be told otherwise.

Tom Ruthven then came back with

Although this is not directly related to MACAR’s work I am not sure everything can be calculated using standard descriptive metadata.

For example, a B1 criteria (for book chapters) includes “must have been published by a commercial publisher”, where “For the purposes of these specifications, a commercial publisher is an entity for which the core business is producing books and distributing them for sale. If publishing is not the core business of an organisation but there is a distinct organisational entity devoted to commercial publication and its publications are not completely paid for or subsidised by the parent organisation or a third party, the publisher is acceptable as a commercial publisher.” Only the publisher name is generally recorded not whether it is a “commercial publisher”, e.g. Tom Ruthven Vainglorious Publishing Company does not tell me if it is a commercial publisher J

Joan

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

Thought you might be interested to know that we have an 'online exhibition' in our repository:

http://hdl.handle.net/1959.3/22042

A lot of the metadata was 'guessed' (and put together very quickly!) so we're suggesting that this is a perfect example.

As always, we welcome feedback from the community.

Helen Wolff

Do repository managers need to have a separate resource type for exhibitions?

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?

Is this a useful thing to do? Could it be seen as too prescriptive? Should we say something about them being suggestions only?