>> Primer
HOME

MODS RDF Ontology:

Primer

Updated:

  • March 18, 2013. minor edits and clarification, see Note .
  • June 7, 2013 minor corrections.

Abstract
This document describes MODS RDF, an RDF ontology for MODS, an XML format for bibliographic information. MODS RDF is an expression of MODS in RDF and may be used to create born-RDF MODS, or it may be used to create an RDF description corresponding to an existing MODS XML record.

Audience
This document is intended for those designing and implementing LIS technology systems.  It assumes the reader is familiar with MODS/XML, and with RDF, and has some familiarity with MADS RDF.


Contents

Introduction

                Namespaces

                Vocabularies

                Primary Design Goals

                Model

Summary of MODS RDF Classes and Properties

Basic Ontology Design Categories

Ontology Treatment of MODS Elements

          <abstract>

           <accessCondition>

          <classification>

          <genre>

           <identifier>

          <language>

          <location>

          <name>

          <note>

          <originInfo>

          <part>

          <physicalDescription>

          <recordInfo>

          <relatedItem>

          <subject>

          <tableOfContents>

          <targetAudience>

          <titleInfo>

          <typeOfResource>

Summary Tables for Element/Property Relationships

Interoperability with Dublin Core


Introduction

This document describes MODS RDF, an OWL/RDF ontology for MODS (Metadata Object Description Schema).
MODS is an XML schema for a bibliographic element set that may be used for the description of cultural and bibliographic resources used within the library and information science community, which includes museums, archives, and other cultural institutions.  MODS RDF is an expression of that element set in RDF. It may be used to create born-RDF MODS, or it may be used to create an RDF description corresponding to an existing MODS XML record.  The latter is discussed in MODS RDF Primer - Part 2: MODS XML to RDF.

Namespaces

The MODS/RDF namespace is: http://www.loc.gov/mods/modsrdf/v1#  

Other namespaces used by  the ontology are:

Namespace Prefix

Namespace URI

madsrdf

http://www.loc.gov/mads/rdf/v1#

owl

http://www.w3.org/2002/07/owl#

rdf

http://www.w3.org/1999/02/22-rdf-syntax-ns#

rdfs

http://www.w3.org/2000/01/rdf-schema#

xsd

http://www.w3.org/2001/XMLSchema#  

ri

http://id.loc.gov/ontologies/RecordInfo

Vocabularies

This ontology prescribes the use of vocabularies for roles, classification schemes, identifier types, resource types and languages.  Any such vocabularies may be used; the following are available:

Vocabulary Prefix

Vocabulary URI

For use with

Example URI

relators

http://id.loc.gov/vocabulary/relators

roles

http://id.loc.gov/vocabulary/relators/cre

classSchemes

http://id.loc.gov/vocabulary/classSchemes

classification schemes

http://id.loc.gov/vocabulary/classSchemes/lcc

identifiers

http://id.loc.gov/vocabulary/identifiers

identifer types

http://id.loc.gov/vocabulary/identifiers/isbn

resourceTypes

http://id.loc.gov/vocabulary/resourceTypes

resource types

http://id.loc.gov/vocabulary/resourceTypes/Txt

languages http://id.loc.gov/vocabulary/languages languages http://id.loc.gov/vocabulary/languages/fre

 

Primary Design Goals

The design goals of this project are to:

  • Use MODS XML
    use MODS XML and the MODS model  as the basis for MODS RDF.
  • Support legacy MODS
    Support the conversion of existing/legacy MODS records to RDF, while providing an ontology for the creation of new MODS descriptions in RDF.
  • Use MADS RDF where Applicable
    MODS subjects – topic, genre, name, titleInfo, occupation, temporal, and  geographic are expressed using the  MADS ontology as MADS Topic, GenreForm, Name, Title, Occupation, Temporal, and Geographic. MODS  originInfo place and publisher are expressed using  MADS Geographic and Name.
  • Interoperate with Dublin Core
  • Support the use of Vocabularies
    Vocabularies are used for roles, classificationSchemes, identifier types, and resource types.  Any such vocabularies may be used; existing LC vocabularies at http://id.loc.gov  are available for use where appropriate.

MODS Model

The following is intended as a concise description of the MODS model.
Objects in the MODS model are MODS resources and MODS resource descriptions.  
A MODS resource is any library-related resource -- such as a book,  journal article,  photograph, or  born-digital image -- that is described by a MODS resource description.  It may be a physical or digital object, or it may be an abstract notion such as a collection or a work. 
A MODS resource description includes descriptive metadata about a MODS resource, relationships between it and other MODS resources, and administrative metadata associated with the MODS resource description. A MODS resource by definition has at least one associated MODS resource description; it may have multiple descriptions.
            When a MODS resource is a physical or digital object (as opposed to an abstract notion) the MODS resource description generally includes information enabling access to the resource.  Information in a MODS resource description may be supplied by value or by reference (included inline within the description or via a link to an external representation of the information).  A MODS resource description can be thought of functionally as similar to a library record. 
A MODS resource may be related to one or more other MODS resources.  For example, a MODS resource which is a collection may have members, which are themselves MODS resources.  Generally these relationships between MODS resources will be expressed as part of the MODS resource descriptions for one or both of the respective resources.
The descriptive metadata for a MODS resource aggregates titles and names associated with the resource along with  subjects and other data elements that further help to describe the resource.  For systems, the MODS resource description and especially its descriptive metadata aids the indexing, searching, and display of information about the resource.  For users, a MODS resource description assists with identifying, finding, selecting, and accessing a MODS Resource.
Administrative metadata provides information about the about the descriptive metadata, primarily provenance information. It includes information, such as the individual or organization responsible for the descriptive metadata and/or the date the descriptive metadata was last modified, as well as relationships expressed in the MODS resource description.



Summary of MODS RDF Classes and Properties

Classes

The following table summarizes MODS RDF Classes.


MODS RDF Classes

Domain of top level MODS Elements

Class

Usage

modsrdf:ModsResource    

A member of this class is a MODS resource, described by a modsrdf description.  This class is the domain for properties corresponding to MODS top level element.

Classes in the MODS RDF namespace which are ranges for properties whose domain is ModsResource

modsrdf:Cartographics    

An aggregator class which is the range for properties corresponding to MODS cartographic elements.

modsrdf:ClassificationGroup   

Aggregates a classification number with its scheme. For use when the scheme is not in the controlled vocabulary.

modsrdf:IdentifierGroup  

Aggregates an identifier with its type. For use when the type  is not in the controlled vocabulary.

modsrdf:Location    

An aggregator class which is the range for properties corresponding to MODS location elements.

modsrdf: NoteGroup 

Aggregates a note with its type. Used only for notes for which a type is specified.

modsrdf:Part    

An aggregator class which is the range for properties corresponding to MODS part elements.

modsrdf:RoleRelationship    

Aggregates a name with a role.

Classes in the MODS RDF  Namespace namespace which are ranges for properties whose domain is one of the classes in the category above

modsrdf:LocationCopy    

An aggregator class which is the range for properties corresponding to MODS copy elements; copy is a subelement of locationOfResource.

Classes in the MADS RDF namespace which are ranges of MODS Elements

madsrdf:ComplexSubject    

Range for a MODS subject with  multiple subject categories.

madsrdf:GenreForm    

Range for both a MODS genre and MODS subjectGenre.

madsrdf:Geographic    

Range for  MODS subjectGeographic, subjectGeographicCode, and MODS place.

madsrdf:Name    

Range for  MODS name, subjectName, and publisher

madsrdf:Occupation    

Range for a MODS subjectOccupation.

madsrdf:Temporal    

Range for a MODS subjectTemporal.

madsrdf:Title    

Range for a MODS titlePrincipal, or titleUniform when there is no principal name; and MODS subjectTitle.

madsrdf:NameTitle    

Range for a MODS titleUniform when there exists a principal name (so that a NameTitle can be constructed).

madsrdf:Topic    

Range for a MODS subjectTopic.

Classes in the RI namespace, for administrative metadata.

ri:AdminMetadata    

Corresponds to MODS recordInfo.

Properties

The following table lists MODS RDF properties alphabetically, and for each property the MODS XML element that the property corresponds to, as well as the domain and range of the property.  More detailed tables are  found in Summary Tables for Element/Property Relationships.

MODS RDF Property

Corresponding
 MODS XML Element

Domain

Range

abstract

abstract

ModsResource

xsd:string

accessCondition

accessCondition

xsd:string

adminMetadata

recordInfo

ri:AdminMetadata

cartographics

subject/cartographics

Cartographics

class:{scheme}; e.g. class:lcc

classification

xsd:string

classificationGroup

classification

ClassificationGroup

classificationGroupScheme

ClassificationGroup

Classification
Group

xsd:string

classificationGroupValue

xsd:string

date

originInfo/dateOther

ModsResource

(annotation property)

dateCaptured

originInfo/dateCaptured

dateCapturedEnd

dateCapturedStart

dateCreated

originInfo/dateCreated

dateCreatedEnd

dateCreatedStart

dateEnd

originInfo/dateOther

dateIssued

originInfo/dateIssued

dateIssuedEnd

dateIssuedStart

dateModified

originInfo/dateModified

dateModifiedEnd

dateModifiedStart

dateOfCopyright

originInfo/copyrightDate

dateOfCopyrightEnd

dateOfCopyrightStart

ModsResource

(annotation property)

dateStart

originInfo/dateOther

dateValid

originInfo/dateValid

dateValidEnd

dateValidStart

digitalOrigin

physicalDescription/
digitalOrigin

xsd:string

edition

originInfo/edition

extent

physicalDescription/extent

form

physicalDescription/form

frequency

originInfo/frequency

genre

genre

madsrdf:GenreForm

identifier:{type}; e.g. identifier:isbn   

identifier

xsd:string

identifierGroup

IdentifierGroup

identifierGroupType

IdentifierGroup

xsd:string

identifierGroupValue

issuance

originInfo/issuance

ModsResource

languageOfResource

language

(annotation property)

LocationCopy

location/holdingSimple/Copy

Location

LocationCopy

locationCopyElectronicLocator

location/ holdingSimple/copy/ electronicLocator

LocationCopy

xsd:string

locationCopyForm

location/holdingSimple/copy/form

locationCopyNote

location/ holdingSimple/copy/note

locationCopyShelfLocator

location/ holdingSimple/copy/shelfLocator

locationCopySublocation

location/ holdingSimple/copy/sublocation

locationOfResource

location

Location

locationPhysical

location/physical

locationShelfLocator

location/shelfLocator

locationSublocation

location/sublocation

locationUrl

location/url

mediaType

physicalDescription/
internetMediaType

ModsResource

name

name

madsrdf:Name

namePrincipal

madsrdf:Name

noteGroup

note

NoteGroup

noteGroupType

NoteGroup

xsd:string

noteGroupValue

noteUntyped

ModsResource

xsd:string

part

part

Part

partCaption

part/detail/caption

Part

xsd:string

partDate

part/date

(annotation property)

partDetailType

part/[email protected]

xsd:string

partEnd

part/extent/end

xsd:string

partLevel

part/detail/level

xsd:positiveInteger

partList

part/extent/list

xsd:string

partTotal

part/extent/total

xsd:positiveInteger

partNumber

part/detail/number

xsd:string

partOrder

[email protected]

xsd:integer

partStart

part/extent/start

xsd:string

partText

part/text

partTitle

part/detail/title

partTotal

part/extent/list

partType

[email protected]

partUnit

part/[email protected]

physicalDescriptionNote

physicalDescription/note

ModsResource

reformattingQuality

physicalDescription/
reformattingQuality

relatedConstituent

relatedItem

ModsResource

relatedFormat

relatedHost

relatedItem

relatedOriginal

relatedPreceding

relatedReference

relatedReferencedBy

relatedReview

relatedSeries

relatedSucceeding

relatedVersion

statementOfResponsibility

note

xsd:string

subjectComplex

subject

madsrdf:ComplexSubject

subjectGenre

madsrdf:GenreForm

subjectGeographic

madsrdf:Geographic

subjectGeographicCode

madsrdf:GeographicCode

subjectHierarchicalGeographic

ModsResource

madsrdf: ComplexSubject

subjectName

madsrdf:Name

subjectOccupation

madsrdf:Occupation

subjectTemporal

madsrdf:Temporal

subjectTitle

madsrdf:Title

subjectTopic

madsrdf:Topic

tableOfContents

tableOfContents

xsd:string

targetAudience

targetAudience

titlePrincipal

titleInfo

madsrdf:Title

titleUniform



Basic Ontology Design Categories

The various top-level MODS XML elements each  correspond to one or more RDF properties, and are treated in a variety of ways, as described in this section.

Properties with Range in External Namespaces

MODS XML elements <name>, <titleInfo>, <genre>  and <subject>, as well as <originInfo><place> and <originInfo><publisher> are represented by properties whose ranges are  MADS classes, using the MADS ontology.  MODS <recordInfo> is represented by a property whose range is the class AdminMetadata in the RecordInfo ontology.
For example consider a MODS subject-topic:

 

          <subject>
   <topic>history</topic>
           </subject>


This would correspond to triple like the following:

ModsResource12356 subjectTopic  #BlankNode1
#BlankNode1  rdf:type  madsrdf:Topic
#BlankNode1  rdfs:label   “history”
#BlankNode1 madsrdf:elementList  #BlankNode2
#BlankNode2  rdfs:first  #BlankNode3
#BlankNode3   madsrdf:elementValue “history”
.......

The term “blank node” is used to mean the object of a triple (as for example #BlankNode1 above) which serves as an aggregator and becomes the subject of subsequent triples.

Aggregators

MODS XML elements <location> and <part>  are structured elements - they have subelements. Therefore in RDF these are represented by properties  (locationOfResource  and part) whose ranges (classes Location and Part) are what we refer to as  “aggregator classes”: their members - the objects of these properties - becomes the subject for triples corresponding to the subelements.
As an example, MODS <location> might include subelements
            <physicalLocation>Prints and Photographs Division Washington, D.C. 20540 USA </physicalLocation>
                and
            <shelfLocator>DAG no. 1410</shelfLocator>

This would correspond to the following triples:

ModsResource12356   locationOfResource   #BlankNode4
#BlankNode4               locationPhysicalLocation
                                      “Prints and Photographs Division Washington, D.C. 20540 USA”
#BlankNode4              locationShelfLocator       “DAG no. 1410”

RDF Property may be a Vocabulary Term

For certain MODS elements there is a ‘type’ (or similar) attribute, where the value of the attribute belongs to a known vocabulary. In these cases, terms from that vocabulary are defined to be properties. An example  is MODS element <identifier>. If the identifier type is known to be “isbn” then the property used is, for example,  ‘identifier:isbn’  where “identifier:” is the prefix for a vocabulary of identifier types. This category applies also to <classification>, where the property used corresponds to the classification scheme, if known.

RDF Object may be a Vocabulary Term

Similar to the previous category, in some cases the value of the MODS element may be identified to be a term from a controlled vocabulary term.  For example, for MODS <language>, if the language term is know to be a code from Iso639-2b, the RDF object may be a URI for the term.

Typed Elements

Several MODS elements  have a ‘type’ attribute. They are treated in three different ways.

A property for each Enumerated Type

MODS <titleInfo> and  <relatedItem>  both have an enumerated list of types, and a property is defined for each type. For example, <titleInfo type=”uniform”> corresponds to rdf property titleUniform.  <relatedItem type=”host”> corresponds to RDF property relatedHost.

Type and Value Bound Together

For MODS <note> the type is optional. When the type is specified, an aggregator is used to bind together the note with its type. For example,

<note type="bibliography">Includes bibliographies.</note>

would correspond to triples like these:

ModsResource12356       noteGroup       #BlankNode5 
  #BlankNode5                rdf:type            “NoteGroup”
  #BlankNode5                noteGroupNote  “Includes bibliographies.”
  #BlankNode5                noteGroupType  “bibliography”

Type Ignored

 For some MODS typed elements , this ontology chooses to ignore the type. These are MODS <abstract> and <accessCondition>.  They are both treated as simple MODS elements.

Simple MODS Elements

The following:

  • <abstract>,  <accessCondition>, <tableOfContents>, and <targetAudience>;
  • all subelements of <physical description>;
  • all subelements of <originInfo>, with the exception of <place> and <publisher>;
  • <note>, when there is no type supplied;
  • <language> when the vocabulary of the language code is not known;

are all represented in RDF as simple triples where the property corresponds directly to the element and the object is the literal value of the element.

For example:

<abstract> based on a novel by a  man named Lear </abstract>

would correspond to the triple:

ModsResource12356  abstract   “based on a novel by a  man named Lear”

Extra Level of Structure Eliminated

MODS elements physicalDescription and originInfo are each wrappers for several subelements. For this ontology it is assumed that these subelements do not need to be bound together and each may be treated as a top level element.  Thus the extra level of structure is eliminated and rather than create classes for these two, for each subelement a property is defined whose domain is ModsResource.



Ontology Treatment of MODS Elements

A MODS RDF description includes a triple of the form:

            {MODS resource}    is-a    #ModsResource

here {MODS resource} is the resource described.  #ModsResource is a blank node and becomes the subject for subsequent triples corresponding to top-level MODS elements.  

This section lists the MODS elements alphabetically, describing how the ontology treats the element, and which category the element belongs to. 


MODS <abstract>

MODS abstract is treated as described in Type Ignored and also Simple.
A MODS abstract  is described by a MODS RDF triple of the following form:

                               {MODS resource}  abstract   {text of abstract}

Where {text of abstract} is a literal, the actual abstract..
Example:

ModsResource12356  abstract   “The story of a horse, and a boy who loved him


MODS <accessCondition>

MODS accessCondition is treated in the same manner as MODS abstract. It is described by  a MODS RDF triple of the following form:

                      {MODS resource}  accessCondition   { text of access condition }

Where {text of access condition} is a literal, the actual access condition.
Example:

ModsResource12356  accessCondition   “No Restriction


MODS <classification>

For a MODS classification, RDF representation depends on whether or not the classification scheme is a term in a known vocabulary.

Classification scheme from a Known Vocabulary

If the classification scheme belongs to a known vocabulary, classification is treated as described by RDF Property a Vocabulary Term:


{MODS resource}  class:{scheme}  {classification}

Where ‘class:’ is the prefix for the class scheme vocabular.
Example:

ModsResource12356      class:lcc     ‘HE380.8’

Where ‘class:’, in this example, is the prefix for the URI http://id.loc.gov/vocabulary/classSchemes

Classification scheme not from a Known Vocabulary

A classification where the scheme is not part of a known vocabulary is treated as described in Type and Value Bound Together.  It is desribed by a triple of the following form:

{MODS resource}  classificationGroup   {ClassificationGroup}

where {ClassificationGroup} groups together a classification and its scheme.
Example:

ModsResource12356      classificationGroup                #BlankNodex
#BlankNodex                   rdf:type                                 ClassificationGroup
#BlankNodex                   classificationGroupScheme    ‘xyz’
#BlankNodex                   classificationGroupValue      ‘HE380.8’


MODS <genre>

MODS genre is treated as described in Properties with Range in External Namespaces.
A MODS genre is described by the triple:

{MODS resource}  genre   madsrdf:GenreForm

Where madsrdf:GenreForm is an RDF description in the MADS RDF namespace.
Example:

ModsResource12356               genre                              #BlankNode6
#BlankNode6                          rdf:type                            madsrdf:GenreForm
#BlankNode6                           rdfs:label                         “fiction”
#BlankNode6                           madsrdf:elementList         #BlankNode7
#BlankNode7                           rdfs:first                          #BlankNode8
#BlankNode8                           madsrdf:elementValue     “fiction”


MODS <identifier>

A MODS identifier is described by a triple of the following form:

                        {MODS resource}  {identifierProperty} {identifier}

The identifier property depends on whether the identifier type belongs to a  known vocabulary.

Identifier Type from a Known Vocabulary

If the identifier type belongs to a known vocabulary, it is treated as described in  RDF Property a Vocabulary Term..
Example:

ModsResource12356      identifier:isbn    ‘0-937383-18-X’

 ‘identifier:’ in this example is the prefix for  a vocabulary of identifier types, e.g. http://id.loc.gov/vocabulary/identifiers

Identifier Type not from a Known Vocabulary

If the vocabulary for the  identifier type is not known, it is treated in a manner similar to classification,  as described in Type and Value Bound Together.  


MODS <language>

A MODS language term may be either a language code (e.g. “fre”) or text (e.g. “french”).

Language Term Controlled

When the language term is a code, and the authority is IS0-639-2b, It is is treated as described in  RDF Object  a Vocabulary Term, by a triple of the following form:

{MODS resource} languageOfResource  {language code URI}

Example:

ModsResource12356      languageOfResource    http://id.loc.gov/vocabulary/languages/fre

Language Term Not Controlled

Otherwise, the  languageTerm is treated as a simple element, described by a triple of the following form:

{MODS resource}  languageOfResource   {value of languageTerm}

Example:

ModsResource12356      languageOfResource    ‘french’


MODS <location>

MODS location is treated as described in aggregators. It is structured into physical location, shelfLocator, url, and copy information. So there are multiple levels of description. First the triple:

{MODS resource}  locationOfResource   #Location

Where #Location is an aggregator which becomes the subject for triples corresponding to the subelements of location, for example:

 #Location   locationPhysical  {physical location}
#Location    locationShelfLocator   {shelf locator}

Example

ModsResource12356      locationOfResource      #BlankNode9
#BlankNode9                  locationPhysicalLocation  
                                                        “Prints and Photographs Division Washington, D.C. 20540 USA”
#BlankNode9                  locationShelfLocator    “DAG no. 1410”

MODS location may also include holdings information, via subelement holdingSimple, which has only one subelement, copy (which is itself structured into several subelements), so there is an extraneous level of structure in the XML, which is eliminated in the RDF.  So each instance of copy results in a triple of the following form:

#Location   locationCopy                                 #LocationCopy

Example:

#BlankNode9          locationCopy                                                          #BlankNode10
#BlankNode10        locationCopyShelfLocator                                      “QH511.A1J68”
#BlankNode10        locationCopyEnumerationAndChronologyBasic       “v.1-v.8 1970-1976"


MODS <name> and role

A MODS name may have an associated role. For example, if the MODS resource has the name “Matilda Plews”, which  has the role “creator”, this means “Matilda Plew is a creator of the resource”.

<name> 

A MODS name is treated as described in Properties with Range in External Namespaces. It is described by a triple of the form:

                        {MODS resource}  {name property}  madsrdf:Name

where {name property} is one of the following properties:

  • namePrincipal
  • name

A MODS name may be determined to be the principal name as follows.

  • If a name has been designated as "primary" it is determined to be the principal name. In this case, the property for this name is ‘namePrincipal’, and for all other names the property is ‘name’.

  • If no name has been designated as ”primary”’, then if there is exactly one name whose role is "creator", than that name is the principal name. In this case, the property for this name is ‘namePrincipal’, and for all other names the property is ‘name’.

  • If no name has been designated as "primary", and if  there is no name whose  role is "creator", or more than one, then there is no principal name. In this case, the property (for all names) is ‘name’.

The purpose of distinguishing a principal name is to determine if a (MADS) NameTitle should be generated. 
Example:

ModsResource12356       name                        #BlankNode11
#BlankNode11                rdf:type                      madsrdf:Name
#BlankNode11                rdfs:label                   "Epstein, Daniel Mark."
#BlankNode11               madsrdf:elementList    #BlankNode12
#BlankNode12               rdfs:first                      #BlankNode13
#BlankNode13               rdf:type                        madsrdf:FullNameElement
#BlankNode13               madsrdf:elementValue   "Epstein, Daniel Mark."
#BlankNode12               madsrdf:rest                rdfs:nil

Role

A MODS name may have an associated role.  However, a MADS name does not include a role. Since MODS relies on the MADS ontology to express a name,  it needs to additionally associate the name with its role.
For each MODS name and associated role, the means buy which RDF associates the role with the name  depends on whether or not the role is a term in a known vocabulary.

Role is a vocabulary Term

When the role is a vocabulary term it is treated as described in Property  a Vocabulary Term.  as in the following triple:

                        {MODS resource}  {roleProperty} madsrdf:Name

Example:

ModsResource12356   relator:cre  madsrdf:Name

In this example, ‘relator:’ is the prefix for a role vocabulary, and ‘cre’ is a term in that vocabulary.
However, since the same name is otherwise described by a separate triple:

            {MODS resource}  {name property}  madsrdf:Name

duplication of the name can be avoided by assigning an internal identifier to the name for reference, as in the following example:

ModsResource12356               name              #idname103263352
ModsResource12356               relator:spk      #idname103263352

In this example, the first line assigns a name to the resource (see <name>) and in the process coins an identifier for reference in the second line, which associates the role with the name.

Role Not from a Known Vocabulary

When the role is not term in a known vocabulary the above technique cannot be used, and instead, an explicit “role relationship” is described.   
Example:

ModsResource12356                name                                 #idname142958136
ModsResource12356                #roleRelationship               #BlankNode14
#BlankNode14                           roleRelationship Role        “secondary creator”
#BlankNode14                           roleRelationshipName        #idname142958136


MODS <note>

Untyped Note

A note with no type specified is treated as described in  Simple. It is described by a triple of the form:

{MODS resource}  note   {text of note}

Example:

ModsResource12356  note   “Dominus vo-bisque'em et come spear a tu-tu, oh.

Statement of Responsibility

A note with  type=”statement of responsibility” is  treated as described in A property for each Enumerated Type and also Simple. It is described by a triple of the form:

{MODS resource}  statementOfResponsibility   {text of note}

This is the only note type that is singled out as such. 
Example:

ModsResource12356       statementOfResponsibility 
                                              “created and maintained by the Asian Division, Area Studies Directorate.

Typed Note

A note with  type other than ”statement of responsibility” Results in the triple:

{MODS resource}  noteGroup      #NoteGroup

Where #Note is an aggregator  that becomes the subject for triples corresponding to the type of note and the note itself, as described in Type and Value Bound Together.
Example:

                ModsResource12356               noteGroup               #BlankNode5
                #BlankNode5                           rdf:type                    “NoteGroup”
                #BlankNode5                          noteGroupNote       “Included bibliographies.”
                #BlankNode5                          noteGroupType       “bibliography”


MODS <originInfo>

MODS originInfo is treated as described in Extra Level of Structure Eliminated.  In MODS XML originInfo binds together information pertaining to origination of the resource.  The binding is considered necessary because originInfo may repeat, for different origination events.  However, in this ontology, different instances of originInfo are considered to be different resource. MODS RDF dispenses with the container and instead, each originInfo subelement tranforms to a direct property of the resource.
Example:

                                ModsResource12356                               edition                “Morning Edition”
                                ModsResource12356                               frequency           “weekly”
                                ModsResource12356                               dateIssued          “1970”


MODS <part>

MODS part  is treated as described in aggregators.  Each part is described by a triple of the following form:

{MODS resource}  part   #Part

Where #Part is an aggregator and becomes the subject for subsequent triples.
Example:

ModsResource12356                               part                                         #BlankNode15
#BlankNode15                                         rdf:type                                   #Part
#BlankNode15                                         partOrder                                “4”
#BlankNode15                                         partLevel                                "v.2, no. 3"
#BlankNode15                                         partCaption                             “no.”
#BlankNode15                                          partNumber                             “2”


MODS <physicalDescription>

MODS “Physical description”  is treated similar to originInfo, as described in Extra Level of Structure Eliminated. In MODS XML it binds together information pertaining to physical characteristics of the resource. MODS RDF dispenses with the container and instead, each physical description subelement tranforms to a direct property of the resource.
Examples:

ModsResource12356               form                                                      “oil painting”
ModsResource12356                reformattingQuality                                “access”
ModsResource12356                mediaType                                            “image/jpeg”

Each individual physicalDescription property is treated as  simple.


MODS <recordInfo>

MODS recordInfo is treated as described in Properties with Range in External Namespaces. It is described by a triple of the following form

{MODS resource}  administrativeMedatata  recordInfo#AdministrativeMetadata

Where “recordInfo’ is an external ontology for administrative metadata and “AdministrativeMetadata” is an aggregator for administrative metadata properties.
Example:

ModsResource12356     administrativeMetadata            #BlankNode16
#BlankNode16               rdf:Type                                   ri:administrativeMetadata
#BlankNode16               ri:recordCreationData               "030211"^^xsd:date
#BlankNode16               ri:recordContentSource              " CStmoGRI”
#BlankNode16               ri:recordOrigin                           " human prepared"


MODS <relatedItem>

MODS relatedItem is treated as described in A property for each Enumerated Type. It is described by a triple of the form:

{MODS resource}  {property}  #ModsResource

Where {property} depends on the type of related item, as shown in the following table:

For  a related item where type=

the RDF property is

"host” relatedHost
"isReferencedBy” relatedReferencedBy
"original” relatedOriginal
"otherFormat”  relatedFormat
"otherVersion”   relatedVersion
"preceding”     relatedPreceding
"references”  relatedReference
"reviewOf”  relatedReview
"series”  relatedSeries
"succeeding” relatedSucceeding

Example:

ModsResource12356            relatedOriginal          ModsResource12357
ModsResource12357            titlePrincipal              #BlankNode17
etc.


MODS <subject>

MODS subject is treated as described in A property for each Enumerated Type and also in Properties with Range in External Namespaces. Every MODS subject has a category. (More precisely, in MODS XML, every <subject> element has a subelement, which we refer to here as the subject category. For example for <subject><temporal>, the subject category is ‘temporal’.)

 

The following table describes how each subject category is described in RDF.

<subject> .....

Described by a triple of the form:

        ... <topic>

{MODS resource}  subjectTopic madsrdf:Topic

          ...<geographic>

{MODS resource}  subjectTopic madsrdf:Geographic

          ...<temporal>

{MODS resource}  subjectTopic madsrdf:Temporal

          ...<titleInfo>

{MODS resource}  subjectTopic madsrdf:Title

          ...<name>

{MODS resource}  subjectTopic madsrdf:Name

        ...<geographicCode>

{MODS resource}  subjectTopic madsrdf:Geographic

       ...<hierarchicalGeographic>

{MODS resource}  subjectTopic madsrdf:HierarchicalGeographic

     ...<cartographics>

{MODS resource} cartographics modsrdf:Cartographics (see note)

          ...<occupation>

{MODS resource}  subjectTopic madsrdf:Occupation

          ...<genre>

{MODS resource}  subjectTopic madsrdf:GenreForm

Note: Cartographics is not treated as a subject in MODS RDF. A MODS Cartographics is generated.

Example:

ModsResource12356                    subjectTopic                            #BlankNode18
#BlankNode18                              rdf:type                                    madsrdf:Topic
#BlankNode18                              rdfs:label                                  “Government and Politics”
etc.


MODS <tableOfContents>

MODS tableOfContents is treated as  simple. It is described by a triple of the following form:

{MODS resource}  tableOfContents   { text of table of contents }

Example:

ModsResource12356               tableOfContents     “1. Here.   2. There.  3. Everywhere  4. The End. .


MODS <targetAudience>

MODS targetAudience is treated as  simple. It is described by a triple of the following form:

{MODS resource}  targetAudience   { text of target audience }

Example:

ModsResource12356               targetAudience     “adolescent .


MODS <titleInfo>

MODS title is treated as described in A property for each Enumerated Type and also in Properties with Range in External Namespaces.
There are five categories of titles  in MODS.

  • Principal title
    If there is no ‘type’ attribute on the MODS <title> element, it is the principal title. The ontology assumes  that there is at most one principal title. If there are any abbreviated, translated, or alternative titles, then there must be a principal title (and if so there may be any number of these types of titles).
    A principal title  is described by a triple of the following form:

                                    {MODS resource}  titlePrincipal   madsrdf:Title

  • Uniform title
    If the ‘type’ attribute has value ‘uniform’, it is a uniform title. The ontology assumes  that there is at most one uniform title.
    A uniform title is described by a triple of the following form:

                   {MODS resource}  titleUniform   { MADS NameTitle or Title }

                                    Where { MADS Title or NameTitle } is:

    • A MADS NameTitle, If there is a principal name.
    • A MADS Title, If not.
  • Abbreviated title
    If the ‘type’ attribute has value ‘abbreviated’, it is an abbreviated title. There may be any number of abbreviated titles (so long as there is a principal title, as an abbreviated title is an abbreviation of the principal title).

  • Translated title
    If the ‘type’ attribute has value ‘translated’, it is a translated title. There may be any number of translated titles (so long as there is a principal title, as a translated title is a translation of the principal title).

  • Alternative title
    If the ‘type’ attribute has value ‘alternative’, it is an alternative title. There may be any number of alternative titles (so long as there is a principal title, as an alternative title is an alternative to the principal title).

For each abbreviated, translated, or alternative title, a MADS Variant Title is generated and included in the madsrdf:Title.
The following Example, shows a principal title and a variant title.

ModsResource12356                                   titlePrincipal                   http://www.loc/gov/modsrdf/id00001
http://www.loc/gov/modsrdf/id00001            rdf:type                                                        madsrdf:Title
http://www.loc/gov/modsrdf/id00001            rdfs:label                   " Margaret Mitchell's Gone with the wind"
http://www.loc/gov/modsrdf/id00001           madsrdf:elementList                                         #BlankNode19
#BlankNode19                                            rdfs:first                                                        #BlankNode20
#BlankNode20                                           rdf:type                                                        madsrdf:MainTitleElement
#BlankNode20                                        madsrdf:elementValue               " Margaret Mitchell's Gone with the wind"
http://www.loc/gov/modsrdf/id00001      madsrdf:hasAbbreviatedVariant       http://www.loc/gov/modsrdf/id00002
http://www.loc/gov/modsrdf/id00002          rdf:type                                                       madsrdf:Title
http://www.loc/gov/modsrdf/id00002          rdfs:label                                                    "Gone with the wind"
http://www.loc/gov/modsrdf/id00002          rdfs:first                                                        #BlankNode21
#BlankNode21                                           rdf:type                                                        madsrdf:MainTitleElement
#BlankNode21                                          madsrdf:elementValue                               "Gone with the wind"


MODS <typeOfResource>

Each MODS typeOfResouce is treated as a triple of the following form:

{MODS resource}  rdf:type  { resource type }

Example:

ModsResource12356  rdf:type  http://id.loc.gov/vocabulary/resourceTypes#Mov



Summary Tables for Element/Property Relationships

MODS Top-level Elements and their RDF Properties

The following table shows, for MODS "top-level" element, the corresponding MODS RDF property and its range.  The domain for all of these properties is modsrdf:ModsResource .

Two "top-level" elements are not included in this table: mods:extension and mods:typeOfResource. The mods:extension is beyond the scope of treatment by this ontology. mods:typeOfResource differs from other "top-level" elements which all correspond to a property, as for example MODS <abstract> corresponds to the RDF property modsrdf:abstract . In contrast MODS <typeOfResource> corresponds to a class, not a property. For example <typeOfResource>moving image</typeOfResource> would correspond to

{MODS resource}  rdf:type http://id.loc.gov/vocabulary/resourceTypes#MovingImage

 

MODS "top level" element (XML)

condition

Corresponding RDF property

Range

abstract

 

abstract

xsd:string

accessCondition

 

accessCondition

xsd:string

classification

uncontrolled type

classificationGroup

ClassificationGroup

controlled type

class:{scheme}; e.g. class:lcc

(None. Defined as an annotated property.)

genre

 

genre

madsrdf:GenreForm

identifier

uncontrolled type

identifierGroup

IdentifierGroup

controlled type

identifier:{type}; e.g. identifier:isbn   

(None. Defined as an annotated property.)

language

 

languageOfResource

(None. Defined as an annotated property.)

location

 

locationOfResource

Location

name

not the principal name

name

madsrdf:Name

the principal name

namePrincipal

note

type unspecified

note

xsd:string

type = “statement of responsibility”

statementOfResponsibility

type specified

noteGroup

NoteGroup

originInfo

 

(none)

 

part

 

part

Part

physicalDescription

 

(none)

 

recordInfo

 

adminMetadata

ri:AdminMetadata

relatedItem

type unspecified

relatedItem

modsResource

type=”preceding”

relatedPreceding

type=”succeeding”

relatedSucceeding

type=”original”

relatedOriginal

type=”host”

relatedHost

type=”constituent”

relatedConsdtituent

type=”series”

relatedSeries

type=”otherVersion”

relatedVersion

type=”otherFormat”

relatedFormat

type=”isReferencedBy”

relatedReferencedBy

type=”references”

relatedReference

type=”reviewOf”

relatedReview

subject

subject category topic

subjectTopic

madsrdf:topic

subject category geographic

subjectGeographic

madsrdf:geographic

subject category temporal

subjectTemporal

madsrdf:temporal

subject category titleInfo

subjectTitle

madsrdf:title

subject category name

subjectName

madsrdf:name

subject category geographicCode

subjectGeographicCode

madsrdf:geographic

subject category hierarchicalGeographic

subjectHierarchicalGeographic

madsrdf:ComplexSubject

subject category cartographics

cartographics

Cartographics

subject category occupation

subjectOccupation

madsrdf:Occupation

subject category genre

subjectGenre

madsrdf:GenreForm

complex subject (multiple subjects)

subjectComplex

madsrdf:ComplexSubject

tableOfContents

 

tableOfContents

xsd:string

targetAudience

 

targetAudience

xsd:string

titleInfo

type=”uniform”; principal name exist

titleUniform

madsrdf:NameTitle

type=”uniform”; no principal name exist

titleUniform

madsrdf:Title

type not specified

titlePrincipal

type=”abbreviated”, “traslated”, or “alternative”

(no modsrdf property)

madsrdf:variant (embedded in Title)

Aggregations

MODS elements location and part each correspond to a property whose range is an aggregation class; that is, the object of the RDF triple is a blank node which becomes the subject of two or more triples.  This is shown in the  following table. 

MODSElement

Aggregation Class

MODS Subelement

Property (whose domain is the aggregation class)

Range

location

Location

(holdingSimple)
copy

locationCopy

LocationCopy

physicalLocation

locationPhysical

xsd:string

shelfLocator

locationShelfLocator

xsd:string

url

locationUrl

xsd:string

part

Part

@type

partType

xsd:string

@order

partOrder

xsd:integer

date

partDate

(ann. Prop.)

text

partText

xsd:string

[email protected]

partUnit

xsd:string

extent/start

partStart

xsd:string

extent/end

partEnd

xsd:string

extent/total

partList

xsd:positiveInteger

extent/list

partTotal

xsd:string

detail/level

partLevel

xsd:positiveInteger

[email protected]

partDetailType

xsd:string

detail/number

partNumber

xsd:string

detail/caption

partCaption

xsd:string

detail/title

partTitle

xsd:string

location/
holdingSimple/
Copy

LocationCopy

form

locationCopyForm

xsd:string

sublocation

locationCopySublocation

xsd:string

shelfLocator

locationCopyShelfLocator

xsd:string

electronicLocator

locationCopyeElctronicLocator

xsd:string

note

locationCopyNote

xsd:string

Aggregators that bind a value with its Type

For the cases shown in the table below an aggregator is defined to bundle a value toghether with its type (or ‘scheme’, in the case of classification).

MODSElement/ condition

Aggregation Class

Property (whose domain is the aggregation class)

Range

classification  / uncoltrolled type

ClassificationGroup

classificationGroupScheme

xsd:string

classificationGroupValue

identifier / uncoltrolled type

IdentifierGroup

identifierGroupType

xsd:string

identifierGroupValue

note / type specified

NoteGroup

noteGroupType

xsd:string

noteGroupValue

Extra Level of Structure Eliminated

Finally, for MODS wrapper elements physicalDescription and originInfo, the wrappers are eliminated and for each subelement a property is directly defined. This is shown in the following table.

MODSElement

Subelement

Property

Range

originInfo

place

placeOforigin

madsrdf:Geographic

publisher

publisher

xsd:string

dateIssued

dateIssued

(None. Defined as annotation properties.)

dateIssuedStart

dateIssuedEnd

dateCreated

dateCreated

dateCreatedStart

dateCreatedEnd

dateCaptured

dateCatpured

dateCatpuredStart

dateCatpuredEnd

dateValid

dateValid

dateValidStart

dateValidEnd

dateModified

dateModified

dateModifiedStart

dateModifiedEnd

copyrightDate

dateOfCopyright

dateOfCopyrightStart

dateOfCopyrightEnd

dateOther

date

dateStart

dateEnd

edition

edition

xsd:string

issuance

issuance

frequency

frequency

PhysicalDescription

form

form

xsd:string

reformattingQuality

reformattingQuality

internetMediaType

mediaType

extent

extent

digitalOrigin

digitalOrigin

note

physicalDescriptionNote



Interoperability with Dublin Core

This ontology declares each MODS RDF property in the left column of the table below to be a subproperty of the corresponding DC Terms property shown to its right (in the middle column) prefaced by http:// purl.org/dc/terms/. 
For example, the first row says:  modsrdf:abstract is a subproperty of http:// purl.org/dc/terms/abstract.

This modsrdf
property:

is a subproperty of http://
purl.org/dc/terms/….  

Definition of DC Term property from dublincore.org/documents/dcmi-terms/

abstract

abstract

A summary of the resource.

accessCondition            

accessRights

Information about who can access the resource or an indication of its security status.

dateCreated

created

Date of creation of the resource.

dateIssued

issued

Date of formal issuance (e.g., publication) of the resource.

dateModified

modified

Date on which the resource was changed.

dateOfCopyright

dateCopyrighted

Date of copyright.

dateValid

valid

Date (often a range) of validity of a resource.

frequence

accrualPeriodicity

The frequency with which items are added to a collection.

genre

type

The nature or genre of the resource.

identifier

identifier

An unambiguous reference to the resource within a given context.

mediaType

format

The file format, physical medium, or dimensions of the resource. Recommended best practice is to use a controlled vocabulary such as the list of Internet Media Types [MIME].

languageOfResource

language

A language of the resource.

note

description

An account of the resource.

publisher

publisher

An entity responsible for making the resource available.

relatedConstituent

hasPart

A related resource that is included either physically or logically in the described resource.

relatedFormat

isFormatOf

A related resource that is substantially the same as the described resource, but in another format.

relatedHost

isPartOf

A related resource in which the described resource is physically or logically included.

relatedItem

relation

A related resource.

relatedOriginal

source

A related resource from which the described resource is derived.

relatedReference

references

A related resource that is referenced, cited, or otherwise pointed to by the described resource.

relatedReferencedBy

isReferencedBy

A related resource that references, cites, or otherwise points to the described resource.

relatedVersion

isVersionOf

A related resource of which the described resource is a version, edition, or adaptation.

subjectTemporal

temporal

Temporal characteristics of the resource. (Subproperty of coverage.)

tableOfContents

tableOfContents

A list of subunits of the resource.

targetAudience

audience

A class of entity for whom the resource is intended or useful.

title

title

A name given to the resource.

topic

subject

The topic of the resource.