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:

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:

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.

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.

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:

This would correspond to triple like the following:

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:

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,

would correspond to triples like these:

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:

would correspond to the triple:

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:

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 }

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:’, 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:

---

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:

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:

 ‘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:

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:

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

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

Example:

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.

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

Example:

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:

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:

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.

MODS <typeOfResource>

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

{MODS resource}  rdf:type  { resource type }

Example:

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

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. 

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).

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.

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.