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?

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