Comments (new threads)

Minutes05 11 2008

Mon, 08 Dec 2008 05:38:12 +0000

Hi, I noticed from the minutes that a resource type for this type is being proposed. Whilst all the documentation is being written, could somebody tell me what actual wording is being proposed? We have some records waiting for publishing. Fiona

Website

Wed, 01 Oct 2008 23:43:43 +0000

I'm confronted with some examples of "online or web publications" that, in a printed environment, wouldn't be classifiable under any of the main MACAR resource types. It's the WWW that facilitates their existence, and their "format" is determined, usually, by the parent site to which they belong. In other words, these single pages, or even single entries on a page or site, have characteristics which are determined by their environment and don't conform to a traditional set of descriptive rules. Some of them might be classed under the DEST N category (Entry), but others are closer to journal articles or reviews, though the site where they're located isn't a journal - it's just a site.

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?

Resource Type

Wed, 11 Jun 2008 04:11:55 +0000

What MARCXML fields do you suggest we use for exhibitions? Would you include 'creative work' there too?

Herdc The Metadata Issues

Wed, 30 Apr 2008 04:13:50 +0000

In the latest Teleconference minutes, there is the following discussion:

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

Identifier

Thu, 17 Apr 2008 05:10:06 +0000

There are advantages in spliltting out the identifier to components such as ISSN or ISBN. this allows for more precise labelling in a display interface. Examples are ISBN, ISSN, Series number(s), DOI, handle, and others. Should we split them apart or leave them as repeatable elements under the one heading?

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.

Macar Terms Of Reference

Wed, 16 Apr 2008 04:33:30 +0000

RUBRIC

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