workofart-brainstorming: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
(Moved Samantha Orme's excellent proposal to Proposals →‎Proposals)
m (Reverted edits by Drive (Talk) to last version by Ebukva)
 
(30 intermediate revisions by 10 users not shown)
Line 10: Line 10:
* [[User:TimG| Tim Gambell]]
* [[User:TimG| Tim Gambell]]
* Samantha Orme
* Samantha Orme
* [[User:Ebukva|Emir Bukva]]


== The Problem ==
== 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.
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 ==
== 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?
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 ===
=== The Metamuseum ===


A work of art microformat turns the art on museum websites into the building blocks of a "metamuseum" -- an interface to the works of art in all museums.
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) ===
=== 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   
"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 [http://microformats.org/discuss/mail/microformats-discuss/2006-March/003422.html this post] on the microformats [http://microformats.org/mailman/listinfo/microformats-discuss/ discuss list]
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 [http://microformats.org/discuss/mail/microformats-discuss/2006-March/003422.html this post] on the microformats [http://microformats.org/mailman/listinfo/microformats-discuss/ discuss list]
 


=== Research (and Publicity for Smaller Collections?) ===
=== 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 [http://microformats.org/discuss/mail/microformats-discuss/2006-March/003422.html this post] on the microformats [http://microformats.org/mailman/listinfo/microformats-discuss/ discuss list]
"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 [http://microformats.org/discuss/mail/microformats-discuss/2006-March/003422.html this post] on the microformats [http://microformats.org/mailman/listinfo/microformats-discuss/ discuss list]


== Discussion ==


=== What should this be based on? ===
=== Galleries ===


* What is the best of the existing metadata schema to use as the basis for the work of art microformat?
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).


=== 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?
== Discussion ==


=== What about [[citation]]? ===


* Ryan Cannon proposes that work-of-art could be produced as a special case of the [[citation]] microformat.
=== What should work of art be based on? ===


* 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. [ [http://www.19clicks.com Samantha Orme] ]
* What is the best of the existing metadata schema to use as the basis for the work of art microformat?


** 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)? -- [[User:TimG|Tim]]
** Consensus seems to be building around using [[citation]] for the basic terms. See the discussion below. -- [[User:TimG | Tim]]


*** The existence of [[existing-classes]] suggests that we're supposed to reuse existing microformats first, before referring to purpose built formats. -- [[User:TimG|Tim]]


*** 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? -- [[User:TimG|Tim]]
=== Integration of other microformats ===


** 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? -- [[User:TimG|Tim]]
* 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?


* 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 [http://www.getty.edu/research/conducting_research/standards/intrometadata/3_crosswalks/crosswalk1.html Metadata Standards Crosswalk]  was also taken into consideration.  Feedback is welcome.


* Questions:
=== What about [[citation]]? ===
** 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. -- [[User:TimG|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? -- [[User:TimG|Tim]]
*** We ought to follow the discussion over at [[hresume|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? -- [[User:TimG|Tim]]


{| border="1" cellpadding="3" cellspacing="2"
* [[User:RCanine|Ryan Cannon]] proposes that work-of-art could be produced as a special case of the [[citation]] microformat.
| '''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) || [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 -- geo?) || [Current Location-Repository Location]
|-
| language || ||
|-
| rights || (copyright information) ||  [Copyright/Restrictions]
|-
| provenance || || [Ownership/Collecting History-Description]
|-
| series || (connect artworks that are part of a series) || [Related Works]
|}


* 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 [http://www.getty.edu/research/conducting_research/standards/cdwa/ 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. [ [http://www.19clicks.com 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)? -- [[User:TimG|Tim]]
*** The existence of [[existing-classes]] suggests that we're supposed to reuse existing microformats first, before referring to purpose built formats. -- [[User:TimG|Tim]]
**** That's correct Tim, reuse existing microformats first. This is explained more thoroughly as  [http://microformats.org/wiki/naming-principles#Reuse_Microformats_First.2C_Other_Standards_Second 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? -- [[User:TimG|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! [[User:FrankieRoberto|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? -- [[User:TimG|Tim]]


[ [http://www.19clicks.com Samantha Orme] ]
== Proposals ==


== Proposals ==


=== [[citation]] + [http://dublincore.org/documents/dcmi-terms/ Dublin Core] Strawman ===
=== [[citation]] + [http://dublincore.org/documents/dcmi-terms/ Dublin Core] Strawman ===
Line 121: Line 83:
** 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.
** 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? -- [[User:TimG|Tim]]
*** 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? -- [[User:TimG|Tim]]
*** We ought to follow the discussion over at [[hresume|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? -- [[User:TimG|Tim]]
*** We ought to follow the discussion over at [[hresume|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? -- [[User:TimG|Tim]]
 


{| border="1" cellpadding="3" cellspacing="2"
{| border="1" cellpadding="3" cellspacing="2"
Line 128: Line 91:
| title ||  || [Title or Names]
| title ||  || [Title or Names]
|-  
|-  
| creator || (hCard) || [Creation-Creator]
| creator || [[hCard|(hCard)]] || [Creation-Creator]
|-  
|-  
| creator-dates || (dates) || [vitalDatesCreator]
| creator-dates || (dates) || [vitalDatesCreator]
Line 136: Line 99:
| creator-role || || [roleCreator]
| creator-role || || [roleCreator]
|-
|-
| subject || (keywords) || [Subject Matter]
| subject || keywords (using [[rel-tag]]?) || [Subject Matter]
|-  
|-  
| description || || [Descriptive Note]
| description || || [Descriptive Note]
Line 154: Line 117:
| source || (current repository) || [Current Location-Repository Name]  
| source || (current repository) || [Current Location-Repository Name]  
|-  
|-  
| source-location || (current repository location -- geo?) || [Current Location-Repository Location]
| source-location || (current repository location -- [[adr]] or [[geo]]?) || [Current Location-Repository Location]
|-
|-
| language || ||
| language || ||
|-  
|-  
| rights || (copyright information) ||  [Copyright/Restrictions]  
| rights || (copyright information) / [[rel-license]]? ||  [Copyright/Restrictions]  
|-
|-
| provenance || || [Ownership/Collecting History-Description]
| provenance || || [Ownership/Collecting History-Description]
Line 164: Line 127:
| series || (connect artworks that are part of a series) || [Related Works]
| series || (connect artworks that are part of a series) || [Related Works]
|}
|}


[ [http://www.19clicks.com Samantha Orme] ]
[ [http://www.19clicks.com Samantha Orme] ]


=== [http://www.getty.edu/research/conducting_research/standards/cdwa/cdwalite/index.html CDWA Lite] Strawman ===
=== [http://www.getty.edu/research/conducting_research/standards/cdwa/cdwalite/index.html CDWA Lite] Strawman ===


[http://microformats.org/wiki/class-design-pattern Use class names] based on the [http://www.getty.edu/research/conducting_research/standards/cdwa/cdwalite/index.html CDWA Lite 0.9 Work in Progress XML Schema].
[http://microformats.org/wiki/class-design-pattern Use class names] based on the [http://www.getty.edu/research/conducting_research/standards/cdwa/cdwalite.html CDWA Lite 1.1 XML Schema].


This example is based on [http://www.getty.edu/research/conducting_research/standards/cdwa/3_cataloging_examples/examples/04_watercolor_turner.html a CDWA example]
This example is based on [http://www.getty.edu/research/conducting_research/standards/cdwa/3_cataloging_examples/examples/04_watercolor_turner.html a CDWA example]
Line 181: Line 141:
     <span class="objectWorkTypeWrap">
     <span class="objectWorkTypeWrap">
         <span class="objectWorkType">watercolor</span>
         <span class="objectWorkType">watercolor</span>
    </span>
    <span class="titleWrap">
        <span class="titleSet">
            <span class="title">Conway Castle, North Wales</span>
        </span>
     </span>
     </span>
     <span class="titleWrap">
     <span class="titleWrap">
Line 200: Line 155:
     <span class="descriptiveNoteWrap">
     <span class="descriptiveNoteWrap">
         <span class="descriptiveNoteSet">
         <span class="descriptiveNoteSet">
             <span class="descriptiveNote">This is the largest of Turner's four extant watercolors of this medieval castle on the northern coast of Wales. Turner portrays the landscape and ocean in a dramatic fashion, using angry clouds, sunshine, and roiling waves to animate the scene and emphasize the struggle of the fishermen...</span>
             <span class="descriptiveNote">This is the largest of Turner's four extant watercolors of this medieval...</span>
         </span>
         </span>
     </span>
     </span>
Line 217: Line 172:
* Is the markup prohibitively complicated?
* Is the markup prohibitively complicated?
* Are wrap tags (such as "objectWorkTypeWrap", "titleWrap" etc) necessary?
* Are wrap tags (such as "objectWorkTypeWrap", "titleWrap" etc) necessary?
* Are display tags (such as "displayCreator") preferable to indexing tags? (See the [http://www.getty.edu/research/conducting_research/standards/cdwa/cdwalite/index.html CDWA Lite XML Schema] for a list of display and indexing tags.)
* Are display tags (such as "displayCreator") preferable to indexing tags? (See the [http://www.getty.edu/research/conducting_research/standards/cdwa/cdwalite.html 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=")?
* What is the best way to deal with attributes on xml tags (such as "type=", "termsource=" and "termsourceID=")?

Latest revision as of 09:09, 22 September 2010

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

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=")?