workofart-brainstorming

Work of Art Brainstorming

This page is for brainstorming about ideas, proposals, constraints, and requirements for a work of art microformat.

This is part of a community effort to create a work-of-art microformat. (See also: workofart-examples, workofart-formats.)

Participants

• Tim Gambell
• Samantha Orme
• Emir Bukva

The Problem

Many art museums use metadata to describe the works of art in their collections. However, the presentation of works of art on the web often does not benefit from that formalized categorization work. We'd like to develop a xhtml markup standard for the presentation of works of art on the web.

Use Cases

Why bother with a microformat for works of art? What problems will it enable us able to solve? What new tools will it enable us to build?

The Metamuseum

A work of art microformat turns the art on museum websites into the building blocks of a web based "metamuseum" -- an interface to the works of art on the web.

The Work of Art Aggregator (+ XSLT = Flash Cards)

"I'm a college student who takes art history courses. At many times I have been presented with the problem of creating flash cards for the exams in these courses. How much time I could have saved with a work-of-art aggregator, and an xslt sheet which could produce printable flashcards automatically from the wide range of art sites out in the wild." -- from this post on the microformats discuss list

Research (and Publicity for Smaller Collections?)

"I mentioned previously that I would be shortly redesigning an art gallery's website making heavy use of microformats. I was just informed that they want to reproduce photographs of all the art and sculpture from each artist for the purposes of working with clientelle in making an informed decision about the purchase of art work. With a microformat as a guide to "best practices" such a catalogue could easily be collected into a searchable database." -- from this post on the microformats discuss list

Galleries

I'd guess that it's more common for multiple works of art to be viewed on a single web page than it is for a single work to be viewed on a single page. In real life, multiple works of art can be combined to make a gallery. The work of art microformat should be designed so that it's easy to combine multiple xhtml works of art into an xhtml gallery (perhaps using something like the hAtom format to tie the pieces together).

Discussion

What should work of art be based on?

• What is the best of the existing metadata schema to use as the basis for the work of art microformat?

• • Consensus seems to be building around using citation for the basic terms. See the discussion below. -- Tim

Integration of other microformats

• What is the best way to integrate existing microformats into the work of art microformat? For example, would it be appropriate to use the hCard microformat to identify the artist? To identify the work of art's location?

What about citation?

• Ryan Cannon proposes that work-of-art could be produced as a special case of the citation microformat.

• I propose that work-of-art should be (more specifically) an extension of the citation microformat. I propose that the goal of work-of-art be to create a simplified version of CDWA, whose core components are those parts of CDWA that are most commonly used when representing a work of art online. However, work-of-art should be extensible such that any work of art may be accomodated. Essentially, work-of-art should strongly encourage the use of its core components (for consistency), but allow additional elements for those cases in which they are strictly necessary. Opinions on the utility and/or drawbacks of being all-inclusive are requested. [ Samantha Orme ]
  • One of the core principles behind microformats is the reuse of existing standards. hCard, for example, is almost a 1:1 reimplimentation of the vcard standard. The proposal that we base this format on citation raises the question: is it better to reuse an existing microformat or to reuse some purpose built format (like CDWA)? -- Tim
    • The existence of existing-classes suggests that we're supposed to reuse existing microformats first, before referring to purpose built formats. -- Tim
      • That's correct Tim, reuse existing microformats first. This is explained more thoroughly as part of naming-principles - Tantek
  • Are museums more likely to adopt a standard that is easy to understand and read or one based on an existing standard designed for museums? -- Tim
    • I think it all depends on the complexity and ease of use. Microformats out-do existing legacy formats (even when based on those legacy formats!) purely because they are simpler to author, and provide a much lower barrier to entry and understanding. - Tantek
    • Simpler to author and understand is always better. The shorter the spec, the more likely it is to be implemented! FrankieRoberto (Science Museum, which holds more works of art than you'd think)
  • I'm not exactly sure what you mean by extensions. If you mean informal extensions, I think we're better off not sanctioning them. The only fields that are going to be really useful (from a readers/parsers point of view) are the ones that are consistenly applied (the core components you propose). However, if you mean extensions like this microformat is an extension of the citation microformat (that is, developed using the microformats process), I agree completely. Your thoughts? -- Tim

Proposals

citation + Dublin Core Strawman

• A suggested starting point for the core components of work-of-art. Components are, where possible, either similar to those that are under consideration for inclusion in citation, or part of the Dublin Core. The Getty's Metadata Standards Crosswalk was also taken into consideration. Feedback is welcome.

• Questions:
  • Is some loss of semantic granularity an acceptable trade-off for microformat clarity? (i.e. should we combine components that would be distinct in a CDWA-based schema?)
    • I think the trade off is acceptable. In a nod toward this issue, CDWA makes a distinction between fields intended for indexing (more granular) and fields intended for display (more human friendly). In the CDWA strawman, I opted to use the human friendly/ less granular "display" fields. -- Tim
  • Should creater information rely on an hCard extension for historical figures? It seems as though hCard with the addition of nationality, vital dates, gender, and role have utility in alternative contexts.
    • I think creator information should rely on hCard to the extent that hCard can already handle it. An hCard extension for historical figures would be very useful for us here, but I'd argue it's outside the scope of this microformat. What do you think? -- Tim
    • We ought to follow the discussion over at hResume. Their approach combines hCard with hCalendar. With the addition of nationality, vital dates, and gender it would provide a framework for the bio files many museums keep on the artists in their collections. hBio anyone? -- Tim

Component	Notes	Approximate CDWA equivalent
title		[Title or Names]
creator	(hCard)	[Creation-Creator]
creator-dates	(dates)	[vitalDatesCreator]
creator-nationality		[nationalityCreator]
creator-role		[roleCreator]
subject	keywords (using rel-tag?)	[Subject Matter]
description		[Descriptive Note]
date	(date created OR earliest date)	[Creation-Date]
latest-date	(latest date)	[Creation-Date-Latest Date]
type	(genre/style)	[Classification] [Styles/Periods] [Object/Work Type]
format	(dimensions)	[Measurements]
medium	(media / techniques)	[Materials and Techniques]
identifier	(repository number / accession number)	[Current Location-Repository Numbers]
source	(current repository)	[Current Location-Repository Name]
source-location	(current repository location -- adr or geo?)	[Current Location-Repository Location]
language
rights	(copyright information) / rel-license?	[Copyright/Restrictions]
provenance		[Ownership/Collecting History-Description]
series	(connect artworks that are part of a series)	[Related Works]

[ Samantha Orme ]

CDWA Lite Strawman

Use class names based on the CDWA Lite 1.1 XML Schema.

This example is based on a CDWA example

<span class="cdwalite">
    <span class="objectWorkTypeWrap">
        <span class="objectWorkType">watercolor</span>
    </span>
    <span class="titleWrap">
        <span class="titleSet">
            <span class="title">Conway Castle, North Wales</span>
        </span>
    </span>
    <span class="displayCreator">Joseph Mallord William Turner (British painter, 1775-1851)</span>
    <span class="displayMeasurements">53.6 x 76.7 cm (21 1/8 in. x 30 1/8 in.)</span>
    <span class="displayMaterialsTech">Watercolor and gum arabic with graphite underdrawing</span>
    <span class="styleWrap">
        <span class="style">Romanticism</span>
    </span>
    <span class="descriptiveNoteWrap">
        <span class="descriptiveNoteSet">
            <span class="descriptiveNote">This is the largest of Turner's four extant watercolors of this medieval...</span>
        </span>
    </span>
    <span class="locationWrap"> 
        <span class="locationSet">
            <span class="locationName currentRepository">J. Paul Getty Museum (New York, New York, USA)</span>
            <span class="locationName repositoryLocation">Los Angeles (California, USA)</span>
            <span class="locationName repositoryNumbers">95.GC.10.</span>
        </span>
    </span> 
</span>

Unresolved issues in CDWA Lite Strawman:

• Is the markup prohibitively complicated?
• Are wrap tags (such as "objectWorkTypeWrap", "titleWrap" etc) necessary?
• Are display tags (such as "displayCreator") preferable to indexing tags? (See the CDWA Lite XML Schema for a list of display and indexing tags.)
• What is the best way to deal with attributes on xml tags (such as "type=", "termsource=" and "termsourceID=")?