MADS/RDF Vocabulary Description

Status: Public Review Document

Updated: 19 November 2010


This document describes the MADS/RDF (Metadata Authority Description Schema in RDF) vocabulary, a data model for authority and vocabulary data used within the library and information science (LIS) community, which is inclusive of museums, archives, and other cultural institutions. It is presented as an OWL ontology.

Based on the MADS/XML schema, MADS/RDF provides a means to record data from the Machine Readable Cataloging (MARC) Authorities format in RDF for use in semantic applications and Linked Data projects. MADS/RDF is a knowledge organization system designed for use with controlled values for names (personal, corporate, geographic, etc.), thesauri, taxonomies, subject heading systems, and other controlled value lists. It is closely related to SKOS, the Simple Knowledge Organization System and a widely supported and adopted RDF vocabulary. Unlike SKOS, however, which is very broad in its application, MADS/RDF is designed specifically to support authority data as used by and needed in the LIS community and its technology systems. Given the close relationship between the aim of MADS/RDF and the aim of SKOS, the MADS ontology has been fully mapped to SKOS.

Status of This Document

This document is a draft. As such, it is subject to change before its final publication.

This document is intended for those designing and implementing LIS technology systems. It is assumed the reader is familiar with MADS/XML, Resource Description Framework (RDF) for information modeling, and the SKOS/RDF vocabulary.

Comments are encouraged and welcome. The MODS listserv (, which is a public listserv with publicly available archives managed by LC, is the preferred forum for feedback. MADS/XML is maintained as part of the community work on MODS (Metadata Object Description Schema) ( and coordinated by the MODS Editorial Committee.

Table of Contents

1. Introduction

1.1. Background

MADS/RDF provides a means to represent the detailed information embedded in common LIS authority records. Although SKOS has proven a robust and very flexible data model, it does not support the more complicated data formations routinely encountered in LIS data.

The Library of Congress has experience representing authority data in SKOS/RDF since early 2009, before the SKOS specification was a formal W3C recommendation. LC was an early adopter of SKOS, in particular it was used in its Linked Data service, ID.LOC.GOV, which made the entire LC Subject Headings (LCSH) file available in SKOS/RDF format. This enriching experience has, immediately after launch and over time, revealed some of the challenges involved in representing more complex authority data purely in SKOS. One of the larger issues quickly brought to LC's attention by users of the data was: there is useful data in LIS authority records that LC is not passing on because SKOS does not provide a means to record it, such as the multiple components, and their types, of pre-coordinated subject headings. This is in no way a fault of SKOS. SKOS was designed to be “a common data model for sharing and linking knowledge organization systems via the Web.” It achieves its aim admirably. Part of SKOS's success, however, comes from abstracting or generalizing organization systems, thereby creating a common set of data elements (Classes and Properties) that can be supported by a wide range of users and for an equally wide range of data. Indeed, SKOS accommodates LIS authority data very nicely after the data has been somewhat generalized.

MADS/RDF is a more specifically defined data model to represent the complexities of authority data. In part because MADS/RDF derives, ultimately, from the MARC Authority format, it is expected that MADS/RDF will be of greatest interest to the LIS community, though it may also be of interest to non-library applications. It provides a means to not only capture information regularly found in LIS authority records but also represent authority data as it has come to be expected by those working in the LIS community. MADS/RDF is designed to complement SKOS and, as such, is formally mapped to the SKOS/RDF vocabulary to be used for inferencing purposes or data exchange between a MADS/RDF user and a SKOS user.

1.2. Some Terminology

Authoritative (also Authority, Authoritative form): the endorsed form of something

MARC Authority format (also MARC): The MARC21 Authority format is currently the primary carrier for authority data used within the LIS community.

Pre-coordinated heading: a multi-concept subject heading composed of two or more independent concepts or components. The components are usually represented as a string when displayed.

Record: Used throughout the current document to describe the compilation of facts about something or, especially in the case of the present document and topic, the collection of triple statements about an authoritative or variant term (such as a subject or name heading).

Variant (also Variant form): an alternate form of something authoritative.

1.3. Primary Design Goals

1.4. Primary Design Goals, Details

1) MADS/XML ( provided a solid foundation for MADS/RDF. MADS/XML, which “is a MARC21-compatible XML format” for MARC authority data, already provided support for pre-coordinated headings and specific authority types. For those familiar with MADS/XML, MADS/RDF can accommodate everything in the MADS/XML schema. MADS/RDF required a few additions: these range from new authority types to usage clarification and codification rules. The names of some MADS/XML elements, attributes, and attribute values were altered to clarify the semantics in MADS/RDF.

2) In MADS/RDF, a “record” – the compilation of facts about something – may be one of two types: madsrdf:Authority or madsrdf:Variant. Most records will be madsrdf:Authority types; in most cases a madsrdf:Variant is related to a madsrdf:Authority record (that is, a madsrdf:hasVariant property relates a madsrdf:Authority to a madsrdf:Variant). However, there is one special case where a madsrdf:Variant stands alone. See (5).

3) A madsrdf:Authority (or madsrdf:Variant) will be dual-typed. By means of inference (or, optionally, explicit designation), each record will be of a madsrdf:ComplexType or madsrdf:SimpleType type. These are Classes that indicate whether the madsrdf:Authority term is, for example, a pre-coordinated heading (madsrdf:ComplexType) or a simple, single-component heading (madsrdf:SimpleType). A madsrdf:ComplexType is the aggregation of two or more records of madsrdf:SimpleType types.

4) madsrdf:ComplexType and madsrdf:SimpleType have an array of sub-classes, each of which more specifically indicates the type of authority “record.” Records should be more granularly typed. madsrdf:ComplexSubject, madsrdf:HierarchicalGeographic, and madsrdf:NameTitle are all sub-classes of madsrdf:ComplexType. These types are designed to handle records that are the aggregation of two or more madsrdf:SimpleType records. For example, a madsrdf:NameTitle is the aggregation of a madsrdf:Name type and a madsrdf:Title type. Examples of madsrdf:SimpleType types include: madsrdf:Temporal, madsrdf:GenreForm, madsrdf:PersonalName, madsrdf:CorporateName, madsrdf:Geographic, madsrdf:Country, etc. Most of the aforementioned types, especially the madsrdf:SimpleType types, were already defined in MADS/XML.

5) It is imperative to support deprecated records (headings/terms). There will be two indicators of “record” deprecation, one or both of which may be required depending on local use. These are: a record of the type madsrdf:Variant and the presence of a madsrdf:hasLaterEstablishedForm property pointing to the succeeding term. Regarding the madsrdf:Variant designation, it is anticipated that a deprecated term would become a variant, or alternate, term for a new or updated madsrdf:Authority record. In this case, the deprecated record, the new madsrdf:Variant, would be a first-class resource (having, perhaps, a resolvable HTTP URI). [Note: this represents a special case; usually a madsrdf:Variant is related to a madsrdf:Authority with the madsrdf:hasVariant property and is identified as an anonymous resource, or blank node.] This scenario – a deprecated authority record is replaced by a new authority record on which the old authoritative term becomes a variant - is the precise use case for the LC.

When the LC deprecated the LCSH term “Cookery” and replaced it with two new terms “Cooking” and “Cookbooks,” the deprecated term (“Cookery”) became a variant form – madsrdf:Variant – for “Cooking.” In short, “Cookery” changed from being a madsrdf:Authority to a madsrdf:Variant. The new madsrdf:Variant, “Cookery,” would also have two instances of the property madsrdf:hasLaterEstablishedForm, one pointing to the new madsrdf:Authority for “Cooking” and the other pointing to the new madsrdf:Authority for “Cookbooks.” Although this example would likely still require human intervention to determine the most appropriate replacement for “Cookery” (“Cooking” or “Cookbooks”), when the deprecation-and-replacement is one-to-one, then it will be possible to perform data updates via machine-to-machine communication in a Linked Data scenario and other semantic applications.

MADS/XML supports Variants. Information about Variants most often comes from the MARC 4XX (See From Tracings) field.

6) MADS/XML supports the parts of labels, such as the nonSort aspect of a Title authority or the givenName of the Name authority. These are fully represented in MADS/RDF with a few semantic alterations and a few additions.

7) MADS/RDF is mapped to SKOS. Although the details are in the OWL ontology definition, the mapping essentially makes SKOS Classes and Properties parent Classes and Properties of MADS/RDF Classes and Properties. For example, a madsrdf:Authority is a sub-class of skos:Concept. A madsrdf:authoritativeLabel, for example, is a sub-property of skos:prefLabel.

1.5. Ontology and Namespaces

MADS/RDF is modeled as an OWL Full ontology. It is available at:

MADS/RDF to SKOS/RDF mapping, which is imported in the ontology, is available separately at:

The MADS/RDF namespace is (caution, this may change before final publication):

Other namespaces and prefixes used in this document or defined in the ontology are:

Namespace Prefix

Namespace URI





1.6. Examples

Record Type





sh2007010620 RDF/XML Ntriples Turtle



sh85068030 RDF/XML Ntriples Turtle



n00000707 RDF/XML Ntriples Turtle



sh85099085 RDF/XML Ntriples Turtle



sh93004675 RDF/XML Ntriples Turtle



n00039722 RDF/XML Ntriples Turtle



sh96011928 RDF/XML Ntriples Turtle



sh2002012470 RDF/XML Ntriples Turtle



n00037993 RDF/XML Ntriples Turtle



sh85017405 RDF/XML Ntriples Turtle



n50048460 RDF/XML Ntriples Turtle



n00009201 RDF/XML Ntriples Turtle



n00009202 RDF/XML Ntriples Turtle



sh85090955 RDF/XML Ntriples Turtle



sh85072887 RDF/XML Ntriples Turtle



sh2010003666 RDF/XML Ntriples Turtle



sh99001636 RDF/XML Ntriples Turtle



sh2008116061 RDF/XML Ntriples Turtle



sh2010100099 RDF/XML Ntriples Turtle



sh85120945 RDF/XML Ntriples Turtle



sh2010002339 RDF/XML Ntriples Turtle



sh2010002340 RDF/XML Ntriples Turtle



sh2002012502 RDF/XML Ntriples Turtle



sh2010004769 RDF/XML Ntriples Turtle



sh2010004770 RDF/XML Ntriples Turtle

2. MADS/RDF Classes

What follows is a description of the major Classes of the MADS/RDF ontology. Brief discussion of the minor classes – madsrdf:Identifier, madsrdf:Affiliation, madsrdf:AffiliationAddress, and madsrdf:Source – will be incorporated at a later date.

2.1. madsrdf:Authority and madsrdf:Variant

madsrdf:Authority is a sub-class of skos:Concept. A madsrdf:Authority, like a skos:Concept, “can be viewed as an idea or notion; a unit of thought.” It is no more specific about what type of idea, notion, or unit of thought is being described. A madsrdf:Authority record may be part of a madsrdf:MADSScheme or madsrdf:MADSCollection, both of which serve to aggregate madsrdf:Authority records.

madsrdf:Variant is also like a skos:Concept in that it represents an abstracted idea or notion. But it should not be the authoritative form of the idea or notion within the knowledge organization system. Ideally, a madsrdf:Variant would not be an unambiguously identified resource, such as one with an HTTP URI. However, because deprecated authoritative records become variant forms (that is, a record of a madsrdf:Authority type becomes a madsrdf:Variant type), it is possible for a madsrdf:Variant record to have a previously published URI requiring on-going support. [Note: the old authoritative record may be replaced with one or more new madsrdf:Authority records each with their own URI.] In most cases, madsrdf:Variant records are, and will be, anonymous resources identified as a blank node.

madsrdf:Authority and madsrdf:Variant are disjoint classes, meaning a madsrdf:Authority cannot simultaneously be a madsrdf:Variant.

2.2. madsrdf:MADSScheme and madsrdf:MADSCollection

A madsrdf:MADSScheme describes a knowledge organization system and aggregates the madsrdf:Authority records and/or madsrdf:MADSCollection entities that define the knowledge organization system. A madsrdf:MADSScheme can include madsrdf:Authority records and madsrdf:MADSCollection types with the madsrdf:hasMADSSchemeMember property (there is an inverse property: madsrdf:isMemberOfMADSScheme).

A madsrdf:MADSCollection defines an abstract entity and aggregates madsrdf:Authority records or other madsrdf:MADSCollection entities. It is expected that the members of a madsrdf:MADSCollection have some form of intellectually unifying theme. A madsrdf:MADSCollection can include madsrdf:Authority records using the madsrdf:hasMADSCollectionMember object property. A madsrdf:MADSCollection does not need to be associated with a madsrdf:MADSScheme. Establishing a relationship is optional and should be considered with care – a madsrdf:Authority within a madsrdf:MADSCollection is effectively also in the madsrdf:MADSScheme.

Notably, a madsrdf:MADSScheme can include a madsrdf:MADSCollection. This design provides a way for knowledge organizers to create groups of madsrdf:Authority records that may be outside the scope of the madsrdf:MADSScheme or, alternatively, that may be outside of the defined madsrdf:Authority description properties. For example, individual library records may contain information about how the term may be used within a predefined scheme. A designation in a MARC authority record indicating that the term could also be used as Temporal Subdivision or that the term could be sub-divided geographically are usage criteria specific to LCSH rules and cataloging. These aspects about the term – that a term can be used as a Temporal Subdivision or that a term can be sub-divided geographically – have been defined as beyond the scope of the madsrdf:Authority description, yet these present intellectually unifying themes upon which to establish a madsrdf:MADSCollection.


<http://LCSH> <rdf:type> <madsrdf:MADSScheme> .

<http://LCSH> <madsrdf:hasMADSSchemeMember> <http://Illinois> .

<http://LCSH> <madsrdf:hasMADSSchemeMember> <http://Collection_GeographicSubdivisions> .

<http://Illinois> <rdf:type> <madsrdf:Authority> .

<http://Illinois> <madsrdf:isMemberOfMADSScheme> <http://LCSH> .

<http://Illinois> <madsrdf:isMemberOfMADSCollection> <http://Collection_GeographicSubdivisions> .

<http://Collection_GeographicSubdivisions> <rdf:type> <madsrdf:MADSCollection> .

<http://Collection_GeographicSubdivisions> <madsrdf:isMemberOfMADSScheme> <http://LCSH> .

<http://Collection_GeographicSubdivisions> <madsrdf:hasMADSCollectionMember> <http://Illinois> .

Such a model does not embed scheme-specific data within madsrdf:Authority records while still allowing for the organization of the scheme and its aspects in a structured manner.

2.3. madsrdf:MADSType

madsrdf:MADSType is an umbrella class. It has two sub-classes: madsrdf:ComplexType and madsrdf:SimpleType. This organization exists primarily for inferencing purposes. It is expected a user will identify a madsrdf:Authority or madsrdf:Variant record with one of the many sub-classes of madsrdf:ComplexType or madsrdf:SimpleType. The distinction, nevertheless, is semantically important.

madsrdf:SimpleType is used for Authority or Variant types the label of which is a discrete term. There are 23 sub-classes in total, ranging from madsrdf:Topic or madsrdf:GenreForm to madsrdf:City or madsrdf:ExtraterrestialArea. madsrdf:Name has 4 sub-classes: madsrdf:PersonalName, madsrdf:CorporateName, madsrdf:ConferenceName, madsrdf:FamilyName. Most of these 23 subclasses are defined in MADS/XML.

madsrdf:ComplexType describes Authority or Variant types created by aggregating two or more Authority and/or two or more Variant records each of a madsrdf:SimpleType. madsrdf:ComplexType has three sub-classes: madsrdf:ComplexSubject, madsrdf:HierarchicalGeographic, and madsrdf:NameTitle.

A madsrdf:ComplexSubject, like madsrdf:ComplexType, is the aggregation of two or more Authority and/or two or more Variant records each of a madsrdf:SimpleType except that the combination of madsrdf:SimpleType types does not meet the conditions to be a madsrdf:NameTitle or madsrdf:HierarchicalGeographic. These restrictions are unenforceable and are followed by convention.

Example: ComplexSubject Authority

<madsrdf:Authority rdf:about="http://United_States--History--Civil_War,_1861-1865">
<rdf:type rdf:resource=""/>
<madsrdf:authoritativeLabel>United States--History--Civil War, 1861-1865</madsrdf:authoritativeLabel>
<madsrdf:componentList rdf:parseType="Collection">
<madsrdf:Geographic rdf:resource="http://United_States"/>
<madsrdf:Topic rdf:resource="http://History"/>
<madsrdf:Temporal rdf:resource="http://:Civil_War,_1861-1865"/>

A madsrdf:HierarchicalGeographic organizes a collection of madsrdf:Geographic types, though the madsrdf:SimpleType types should come from one of madsrdf:Geographic sub-classes such as madsrdf:City, madsrdf:Country, madsrdf:State, madsrdf:Region, madsrdf:Area, etc.

Example: HierarchicalGeographic Authority

<madsrdf:Authority rdf:about="http://United_States--New_Jersey--Essex--Montclair">
<rdf:type rdf:resource=""/>
<madsrdf:authoritativeLabel>United States--New Jersey--Essex--Montclair</madsrdf:authoritativeLabel>
<madsrdf:componentList rdf:parseType="Collection">
<madsrdf:Country rdf:resource="http://United_States"/>
<madsrdf:State rdf:resource="http://New_Jersey"/>
<madsrdf:County rdf:resource="http://Essex"/>
<madsrdf:City rdf:resource="http://Montclair"

A madsrdf:NameTitle is the aggregation of madsrdf:Name and a madsrdf:Title, both of which are of madsrdf:SimpleType types.

Example: NameTitle Authority

<madsrdf:NameTitle rdf:about="http://Herman,_Jerry,_1933-_Hello,_Dolly!">
<rdf:type rdf:resource=""/>
<madsrdf:authoritativeLabel>Herman, Jerry, 1933- Hello, Dolly!</madsrdf:authoritativeLabel>
<madsrdf:componentList rdf:parseType="Collection">
<madsrdf:PersonalName rdf:nodeID="aHerman-Jerry-1933-">
<rdf:type rdf:resource=""/>
<madsrdf:authoritativeLabel>Herman, Jerry, 1933-</madsrdf:authoritativeLabel>
<madsrdf:elementList rdf:parseType="Collection">
<madsrdf:elementValue>Herman, Jerry,</madsrdf:elementValue>
<madsrdf:Title rdf:nodeID="aHello-Dolly!">
<rdf:type rdf:resource=""/>
<madsrdf:authoritativeLabel>Hello, Dolly!</madsrdf:authoritativeLabel>
<madsrdf:elementList rdf:parseType="Collection">
<madsrdf:elementValue>Hello, Dolly!</madsrdf:elementValue>

A madsrdf:ComplexType will have a madsrdf:componentList, which organizes the disparate components of the madsrdf:ComplexType's label. madsrdf:componentList has a range of rdf:List. Although somewhat cumbersome, rdf:List not only serves to order the list components (the madsrdf:SimpleType records) but also provides a way to establish the end of the list which helps to preserve the heading's integrity.

2.4. madsrdf:Element

The madsrdf:Element class, and its associated sub-classes, provide a way to describe the parts of labels. For example, the name “Black Foot, Chief, d. 1877” can be broken into 3 parts, or elements. “Black Foot” is the madsrdf:NameElement; “Chief” is the madsrdf:TermsOfAddressNameElement; and “d. 1877” is the madsrdf:DateNameElement. The madsrdf:elementList property, which, like madsrdf:componentList, is used to organize the various parts of labels. It has a range of rdf:List.


<madsrdf:PersonalName rdf:about="http://Black_Foot,_Chief,_d._1877">
<rdf:type rdf:resource=""/>
<madsrdf:authoritativeLabel>Black Foot, Chief, d. 1877</madsrdf:authoritativeLabel>
<madsrdf:elementList rdf:parseType="Collection">
<madsrdf:elementValue>Black Foot,</madsrdf:elementValue>
<madsrdf:elementValue>d. 1877</madsrdf:elementValue>

madsrdf:elementList does not, currently, have a domain, thereby permitting it to be used with madsrdf:ComplexType records. It is, however, generally associated with a madsrdf:SimpleType.

3. MADS/RDF Object Properties

Not all Object Properties are discussed in this section. Some have been treated earlier in this document, especially those pertaining to madsrdf:MADSScheme types and madsrdf:MADSCollection types.

3.1 Relationships

All the Object Properties meant to indicate a (potential) high-value relationship are prefixed with the English verb “has.” Employing camel-case, the second term identifies the type of relationship and the third the target of the relationship.

3.2 madsrdf:hasRelatedAuthority

madsrdf:hasRelatedAuthority can be equated with skos:semanticRelation and, as such, is designed as an umbrella property for all of its sub-properties. The property, however, states, at best, a vague ill-defined relationship, simply that one Authority has some form of relationship with another Authority. madsrdf:hasRelatedAuthority has a domain of madsrdf:Authority and a range of madsrdf:Authority. The sub-properties – most of which were predefined in MADS/XML – more precisely define the relationship between two madsrdf:Authority records. Relationships in MADS/RDF map, for the most part, with their SKOS equivalents. And, although different semantics were adopted, the parallel SKOS property should be readily obvious. There cannot be a relationship under the madsrdf:hasRelatedAuthority property between two madsrdf:Variant types or between a madsrdf:Variant type and a madsrdf:Authority type.

a) madsrdf:hasBroaderAuthority and madsrdf:hasNarrowerAuthority

These are designed to associate a madsrdf:Authority with a more broadly (general) or more narrowly (specific) term. These have an inverse relationship with each other. MADS/XML supports these relationships.

b) madsrdf:hasBroaderExternalAuthority and madsrdf:hasNarrowerExternalAuthority
These relationships have been added to accommodate the SKOS equivalents (skos:broadMatch and skos:narrowMatch). They assist with linking madsrdf:Authority records in one madsrdf:MADSScheme to a term found in a different madsrdf:MADSScheme. These are sub-properties of their respective non-external relationship type. They are not represented in MADS/XML.

c) madsrdf:hasReciprocalAuthority and madsrdf:hasReciprocalExternalAuthority

madsrdf:hasReciprocalAuthority relates to madsrdf:Authority records with each other so long as the relationship is shared, reciprocally. MADS/XML supports this relationship with the “equivalent” relationship type value. madsrdf:hasReciprocalExternalAuthority – a sub-property of madsrdf:hasReciprocalAuthority - does the same for madsrdf:Authority records in other madsrdf:MADSSchemes.

d) madsrdf:hasCloseExternalAuthority and madsrdf:hasExactExternalAuthority

These have been added to accommodate the SKOS equivalents (skos:closeMatch, skos:exactMatch). They are designed to relate madsrdf:Authority records in two different madsrdf:MADSSchemes. These properties establish relationships between madsrdf:Authority records in two different madsrdf:MADSScheme types.

e) madsrdf:hasParentOrganization and madsrdf:isParentOrganizationOf

These properties are in MADS/XML and serve to relate the records for corporate entities. They are inversely related to each other.

3.3. Relationships between Current Records, Deprecated Records, and Superseded Records

a) madsrdf:hasLaterEstablishedForm

madsrdf:hasLaterEstablishedForm relates a madsrdf:Variant record to a madsrdf:Authority record, which represents its authoritative form. This combination of Class type and Property is one of the primary ways to indicate a record/URI has been deprecated and replaced by a new one. The object of madsrdf:hasLaterEstablishedForm will provide a machine with the knowledge about where to look for the new, authoritative form of the (now) variant form of the record.

However, madsrdf:hasLaterEstablishedForm may, in fact, relate a madsrdf:Authority – i.e. not just a madsrdf:Variant – to another madsrdf:Authority. Although not exclusive – and this characterizes an LC use case – Corporate Names, which include political entities, from the LC Name Authority File may remain authoritative even after being succeeded by a newer authoritative form. For example, the “Minnesota Mining and Manufacturing Company” has a later established form, “3M Company,” but “Minnesota Mining and Manufacturing Company” remains authoritative when used to describe something that pertains specifically to the time when the “3M Company” was known as the “Minnesota Mining and Manufacturing Company.”

MADS/XML supports the relationship madsrdf:hasLaterEstablishedForm, though it is not designed to be used for all madsrdf:MADSType types. This has been revised in MADS/RDF. SKOS has no equivalent.

b) madsrdf:hasEarlierEstablishedForm

madsrdf:hasEarlierEstablishedForm is the inverse of madsrdf:hasLaterEstablishedForm. It can relate a madsrdf:Authority to the madsrdf:Variant (née madsrdf:Authority) it now replaces. It may also establish a link between a new authoritative form and a still-valid, but now historical, authoritative form. MADS/XML provides support for this relationship.

3.4. madsrdf:hasVariant

madsrdf:hasVariant, with a domain of madsrdf:Authority and a range of madsrdf:Variant, relates a madsrdf:Authority to a madsrdf:Variant. madsrdf:hasVariant has no inverse property relationship. At times, this relationship will seem equivalent to madsrdf:hasEarlierEstablishedForm, but it is not. In most circumstances, a blank node will be used but a known resource may be used, especially when the madsrdf:Variant was once a madsrdf:Authority record.

4. Acknowledgements

The MADS/RDF to SKOS/RDF mapping was done by Antoine Isaac. The MADS/RDF model and ontology benefited significantly as a result of the fruitful discussions surrounding his effort to map the MADS/RDF ontology to SKOS.