UTK MODS/RDF Titles Examples

gistfile1.txt

For the various titles of an object, what elements, subelements, and attributes do the institutions of this group deal with?

titleInfo@type=[abbreviated | translated | alternative | uniform]/title
  - although discussion of following more title then alternativeTitle for rest is valid (and current approach in MODSRDF v1 from LoC)
  - uniform is good to have in theory but perhaps not much used in practice currently. Not currently represented in other RDF-modeled ontologies other than modsrdfv1 I think?
  - MODSRDFv1 from LoC currently models modsrdf:title as modsrdf:property with range madsrdf:Title
titleInfo[@authority | @authorityURI | @valueURI]/title
  - all captured by use of URIs for titles that will be taken from external authority
titleInfo@usage="primary"/title
  - will this be captured by having just 1 title property and rest alternativeTitle properties? 
  - otherwise, make titlePrimary property? (not a fan of this personally)
  - use of skos:prefLabel?
titleInfo@supplied="yes"/title
  - we have never used this, so neutral about trying to represent in MODSRDF. 
titleInfo@nameTitleGroup/title
  - we do not currently use this, so neutral about trying to represent in MODSRDF.
  - this is the type of information perhaps better modeled in new way of approaching name/title authorities
titleInfo@transliteration/title
  - we do capture that something is transcribed (with type="translated") but not how - which would be this attribute.
  - as such, neutral about keeping in MODSRDf.
titleInfo/subtitle
  - do we need to add a modsrdf subtitle property? would be subproperty of title?
  - can be helpful for display issues, but that should not be a reason for data modeling.
  - we do use where possible, but not often since most of our MODS is for digitized non-bibliographic materials that don't have subtitles. Can be used quite a bit for relatedItem/titleInfo though.
titleInfo/partNumber
  - we do use whenever there is relevant information, which is not too often. 
  - compare with use of part (top level element) and how to decide which to use when in MODSRDF
titleInfo/partName
  - we do use often, especially for digital objects that represent but a portion of a work (book. page 1 or album. 3rd photograph)
  - as with partNumber, compare with use of part (top level element) and how to decide which to use when in MODSRDF
titleInfo/nonSort
  - we use often.
  - MODSRDFv2 from LoC currently looking at making titleForSort property. Want to consider?
  
How do you use these elements / subelements / attributes?

titleInfo@type=[abbreviated | translated | alternative | uniform]
  - abbreviated: not used heavily, but primarily for series with abbreviated title forms found in journal/serials titles lists
  - translated: used heavily to represent title translations or transcriptions, usually from the resource itself. Don't often supply this value.
  - alternative: used as catch-all for alternative titles
  - uniform: used only if there is an LC authority record for a title. Not used often since most of our MODS deals with non-bibliographic items. Probably use uniform titles more often with subjectTitle.
titleInfo[@authorityURI | @valueURI]
  - we do use @authority to indicate the source, especially if the authority doesn't provide URIs or is a local controlled vocabulary we want to handle differently in indexing, display.
  - we do use @valueURI if available, primarily for uniform titles.
titleInfo/subtitle
  - we use where possible, but not often since most of our MODS is for digitized non-bibliographic materials that don't have subtitles. Can be used quite a bit for relatedItem/titleInfo though.
titleInfo/partNumber
  - we do use whenever there is relevant information.
titleInfo/partName
  - we do use often, especially for digital objects that represent but a portion of a work (book. page 1 or album. 3rd photograph)
titleInfo/nonSort
  - we use often.

Notes on anything special about an institutions use of these elements / subelements / attributes. (Unusual application logic, extremely complex combinations, potential weirdness in what data you put in it, etc).

I think the title/part and part application uses vary widely, but that is based off of anecdotes and revieiwng of various metadata sets.

An attempt by someone at that institution to map that element to RDF. Essentially: If they had to move that to RDF in Fedora 4 today, what would they chose to do with it?