<objectType> to be > a valid child of <objectDesc>

[yf227]

For the consolidated special collection schema, we need to use <objectDesc> with @type and @function nested in <objectDesc>.

This is not currently valid TEI. Can it be incorporated, please?

[martindholmes]

@yf227 Could you give us a full example of the kind of encoding you're proposing?

<objectType> is a simple inline element containing a simple word or phrase; it can appear inside (for example) <p>, so that's how I would expect it to be used in the context of an <objectDesc>. It can point using @ref to an <object> element that includes a complete description of an object, including @type and @subtype. I do think it would be worth proposing @function as an addition to the <object> element, perhaps.

[okarapasia]

To clarify, our request is specifically to make the existing TEI element <objectType> a valid, repeatable child of <objectDesc>. The aim is to encode object type structurally within itself, rather than only within prose in <p>.

Summary of proposal:

Element: <objectType>
Definition: contains a word or phrase describing the semantic, functional, or bibliographic type of the item being described.
Recommended position: immediately after the opening <objectDesc> and before <supportDesc>.
Display label: Type.
Repeatability: multiple <objectType> may be used where more than one type or classification is required.

The @form on <objectDesc> should be used to indicate the general physical format of the item, such as "codex", "sheet", or "roll".

The proposed <objectType> child would then provide a structured way to record the semantic, functional, or bibliographic type of the item. It may also further define or specify the physical format or bibliographic classification where needed.

For example, this allows us to distinguish between different types of codex:

<objectDesc form="codex"> 
<objectType source="#aat" key="300028569">manuscript</objectType> 
<supportDesc material="parchment"> 
<support> 
<material source="#aat" key="300011851">Parchment</material> 
</support> 
<! -- additional metadata -->   
</supportDesc> 
</objectDesc>

<objectDesc form="codex"> 
<objectType source="#aat" key="300028051">book</objectType> 
<supportDesc material="paper"> 
<support> 
<material source="#aat" key="300014109">Paper</material> 
</support> 
<! -- additional metadata -->   
  </supportDesc> 
</objectDesc>

<objectDesc form="codex"> 
<objectType source="#aat" key="300027341">scrapbook</objectType> 
<supportDesc material="paper"> 
<support> 
<material source="#aat" key="300014109">Paper</material> 
</support> 
<! -- additional metadata -->   
</supportDesc>  
</objectDesc>

This structure maintains a clear separation of concerns: <objectDesc @form> expresses the physical format of the item, while <objectType> identifies the semantic, functional, or bibliographic type of the item within its material context.

The repeatability of <objectType> is particularly useful, for example, in printed book descriptions in which both the semantic type of the item and its bibliographic format may need to be encoded:

<objectDesc form="codex"> 
<objectType source="#aat" key="300055021">incunabulum (book)</objectType> 
<objectType source="#aat" key="300265438">folio (fo)</objectType> 
<supportDesc material="paper"> 
<support> 
<material type="paper" subtype="royal" source="#aat" key="300265462">Royal paper</material> 
</support>  
<! -- additional metadata --> 
</supportDesc> 
</objectDesc>

In this example, the second <objectType> further defines the bibliographic format of the codex.

The semantic or functional type of the item should be recorded using <objectType>. Where applicable, it should include both @source and @key.

In our implementation, source="#aat" indicates that the identifier recorded in @key is drawn from the Getty Art & Architecture Thesaurus (AAT), declared in the TEI header as:

<taxonomy xml:id="aat"> 
<bibl><ref target="https://www.getty.edu/research/tools/vocabularies/aat">Getty Art &amp; Architecture Thesaurus® (AAT)</ref> 
</bibl> 
</taxonomy>

The prefix # indicates a reference to an identifier defined elsewhere in the same TEI file. This value can also be selected from a controlled dropdown list during metadata entry and does not need to be typed manually.

For consistency with controlled vocabulary practice, the textual value of <objectType> should normally be entered in lowercase, unless the term is a proper noun or the authorised vocabulary form requires capitalisation. This keeps the encoded value distinct from display formatting. Any required capitalisation for presentation, such as displaying manuscript as Type: Manuscript, should be handled by the XSLT transformation or display layer rather than entered manually in the TEI.

Further examples include:

<objectDesc form="sheet">  
<objectType source="#aat" key="300026879">letter (correspondence)</objectType>  
<supportDesc material="paper">  
<support>  
<material source="#aat" key="300014109">Paper</material>  
</support>  
<! -- additional metadata -->   
</supportDesc>  
</objectDesc>

<objectDesc form="sheet"> 
<objectType source="#aat" key="300028094">map</objectType> 
<supportDesc material="paper"> 
<support> 
<material source="#aat" key="300014109">Paper</material> 
</support> 
<! -- additional metadata --> 
</supportDesc> 
</objectDesc>

<objectDesc form="fragment"> 
<objectType source="#aat" key="300266585">amulet</objectType> 
<supportDesc material="parchment"> 
<support> 
<material source="#aat" key="300011851">Parchment</material> 
</support> 
<! -- additional metadata --> 
</supportDesc> 
</objectDesc>

We have also considered the suggestion about @function, but we think this requires further thought before it is introduced here.

TEI defines @function as characterising the function of a segment. In the TEI P5 Customization and Encoding Guidelines for Manuscript Description, @function is also used on <material> to describe the function or use of the material in relation to the object as a whole. Sample values include binding, endband, slipcase, support, and tie.

This is a different modelling problem from the one we are trying to solve with <objectType>. Our proposal concerns the semantic, functional, or bibliographic type of the object as a whole, not the function of a material component within the object.

Within Manchester Digital Collections (MDC), functional purpose is currently sometimes recorded using local <note type="function"> values, especially in the Gaster Amulets project, for purposes such as protection, healing, commemoration, exchange, personal adornment, or ritual intent. These uses are provisional and have not yet been tested across the wider MDC schema.

For example:

<msItem> 
<!-- additional metadata --> 
<note type="function">Protection and prosperity.</note> 
<!-- additional metadata --> 
</msItem>

The forthcoming introduction of <object> may provide more appropriate TEI structures for recording this type of information in future. When implemented, the use of local note types such as <note type="function"> may need to be reviewed and potentially replaced by more suitable elements.

For these reasons, we do not want to make @function part of the immediate proposal. It may be useful in future, perhaps in relation to <object> or even <objectType>, but it needs fuller definition first so that semantic object type, bibliographic classification, material function, and cultural or ritual purpose are not conflated.

Our immediate request is therefore narrower and more practical: to permit the existing <objectType> as a valid, repeatable child of <objectDesc>, where applicable including both @source and @key.

[jamescummings]

The forthcoming introduction of <object> may provide more appropriate TEI structures for recording this type of information in future.

<object> already exists. What it is still missing is <objectContents> which I hope to submit this summer.