Interactive Fiction Catalogs

This work is licensed under a Creative Commons Attribution 2.5 License.
This copyright and license applies to this document and does not apply to IF data formats, media types, or technology.

Abstract

The most important part of the Interactive Fiction metadata system is the metadata catalog: it is catalogs that allow semantic web user agents to locate games, reviews, people, and other resources. This document defines the Catalog class and explains how to use it to create Interactive Fiction Catalogs.

Status of this Document

This section describes the status of this document at the time of publication. Other documents may supercede this document.

This document is currently in the Working Draft stage of development. As such, it should not be considered a definitive reference, nor an official standard. Early adopters may begin implementing the described technology, but should be prepared for incompatible changes as the specification develops. In software development terms, this is an “alpha” quality release.

It is important to note that this is not a standard in the same way as a W3C Recommendation, ISO Standard, or IETF Standards Track RFC. The IFMI does not have the authority of those bodies to set standards. IFMI standards are offered as a service to those communities that appreciate the need for interoperable standards in Interactive Fiction metadata and choose to recognize IFMI as a supplier of such standards.

Quick Table of Contents

Full Table of Contents

1 About the IFCatalog Specification

1.1 Document Organization

The first part of this document, 2 Interactive Fiction Catalogs, is a normative reference describing the IFCatalog system. The second part, 3 Catalog Construction Guide is an informative tutorial giving an example of how catalogs are constructed in RDF and XML. Finally, Appendix A presents the schemas for IFCatalog.

1.2 Definitions

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119. When those words are not emphasized as shown here they MUST NOT be interpreted as described in RFC 2119 [RFC2119].

1.3 Document Conventions

RDF examples in this document will use the RDF/XML syntax [RDF] for describing data.

References are enclosed in square brackets ([]) and colored red; these are linked to the references section at the end of the document. Hyperlinks to external resources are enclosed in angle brackets (<>), except in the metadata header at the top and the references section at the bottom, which are all external links. External links will use your default link colors. All other hyperlinks are internal links to other sections of this document. Internal links to terms defined in this document are colored green, internal links to sections are blue and italicized. (This paragraph applies to standards-compliant web browsers. Browsers that do not comply with standards may not render hyperlink styles correctly.)

This document uses the keywords “Normative” and “Informative” to classify information; readers familiar with technical specifications will already know what these terms mean, other readers may need the following definitions:

2 Interactive Fiction Catalogs

Interactive Fiction Catalog are described using a combination of two vocabularies, Qualified Dublin Core [DC] for information and Interactive Fiction Relational Links [IFLINK] for structure. Catalog Items are described using a vocabulary appropriate to the type of item. Often catalog items will have their metadata attached to them already.

2.1 The Catalog Resource Type (IFType)

Catalogs are represented by iftype:Catalog type resources. This class is part of the Interactive Fiction Resource Types [IFTYPE] vocabulary.

A Catalog resource represents a collection of IF games and associated information. It may catalog games in an internet archive, a personal collection, an author's portfolio, etc. Catalogs may contain nested catalogs representing different categories or classifications within the collection.

2.2 Catalog Information

Every catalog MUST have a dc:title property giving the name of the catalog. Catalogs SHOULD have a dc:description property giving a longer description of the catalog. Catalogs MAY have a dc:creator and/or foaf:maker property identifying the entity that created the catalog.

A dcterms:modified property is encouraged, as it will help user agents accessing the catalog through a query protocol like SPARQL [SPARQL] determine if the catalog has changed since they last accessed it. HTTP user agents will typically just use a HEAD request for this purpose [HTTP].

Catalog creators are also encouraged to include any other relevant Dublin Core properties. Catalogs can also use an iflink:icon property to provide a graphic identifying the catalog.

2.3 Catalog Structure

The iflink:contents element MUST be used to list the resources contained by a catalog. These can include games, reviews, people, software, child catalogs, and any other catalog items. Contents do not include services provided by the catalog, such as collective downloads (unless the collection is an item in its own right), user support resources, genres and genre schemes, or other service-oriented resources orthogonal to the catalog's inventory. Those are given by the iflink:services element.

When catalogs contain child catalogs, the tree formed by the chain of iflink:contents elements is called the catalog tree. Some types of services might also have iflink:contents arcs, these hierarchies beginning with an iflink:service arc are called service trees.

2.4 Genres and Genre Schemes

Catalogs MAY specify a genre scheme that they employ. This is done by referencing the scheme with an iflink:genreScheme element. A genre scheme referenced by a parent catalog is assumed to apply to all child catalogs, including those with their own iflink:genreScheme arcs. Note that current general-purpose RDF inference engines are not able to automatically infer arcs inherited from parent resources, nor do current ontology languages provide any means of specifying such inheritance; user agents designed specifically for IFCatalog MAY be implemented with special knowledge of genre scheme inheritance. Catalogs MAY employ more than one genre scheme.

A catalog MAY assign genres to the IF works in the collection independently of genres assigned by the author or other catalogs. This is done by adding an iflink:genre arc to the game resource. If the catalog does assign genres, then it SHOULD have an iflink:genreScheme property, or inherit one from a parent catalog.

User agents MAY attempt to scope genre assignments to the catalog that makes them. The RDF Reification vocabulary [RDF] MAY be used for this purpose, by creating a resource describing the iflink:genre statement and identifying the entity making that statement. Such scoping is encouraged, but is not a requirement of this specification. The means of storing the scope information is entirely dependent on the user agent in any case.

2.5 Game Catalogs

When catalogs contain IF games, they SHOULD provide the various IFLink arcs between versions, variations, components, etc. Unlike the standard IFMES elements [IFMES], these relational arcs are usually different for each website storing the game, so the author cannot provide them when the game is published.

3 Catalog Construction Guide (Informative)

This section is a guide giving a examples of how a catalog can be constructed. A small catalog tree with three child catalogs will be constructed with example code in both RDF and XML. Games, software, and people will be included in the catalog inventory.

3.1 Setting up the Catalog Tree

We'll begin by setting up the basic catalog tree. We'll use one parent catalog with three child catalogs. The child catalogs are basically the same as the parent, so we'll just show the parent here.

3.1.1 The Document Framework

First we'll set up the document framework. RDF and XML both have some standard material that is needed in every document.

First, the RDF version:

Figure 3.1.1.1: Basic RDF Framework

<?xml version="1.0" encoding="utf-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:dc="http://purl.org/dc/elements/1.1/"
         xmlns:dcterms="http://purl.org/dc/terms/"
         xmlns:dcmi="http://purl.org/dc/dcmitype/"
         xmlns:foaf="http://xmlns.com/foaf/0.1/"
         xmlns:if="http://purl.org/int-fiction/metadata/1.1/"
         xmlns:iflink="http://purl.org/int-fiction/metadata/iflink/1.0/"
         xmlns:iftype="http://purl.org/int-fiction/metadata/iftype/"
         xml:base="http://example.com/">

  <iftype:Catalog rdf:about="archive/">

  </iftype:Catalog>

</rdf:RDF>

This sets up the RDF container and declares the namespace prefixes. We use quite a lot of namespaces in this example, but actual catalogs can leave some of them out if they don't use them. We also set the base URI of the catalog; without the xml:base attribute the base URI is obtained from the location of the RDF file.

The XML version is pretty similar:

Figure 3.1.1.2: Basic XML Framework

<?xml version="1.0" encoding="utf-8"?>
<iftype:Catalog xmlns:xlink="http://www.w3.org/1999/xlink"
                xmlns:dc="http://purl.org/dc/elements/1.1/"
                xmlns:dcterms="http://purl.org/dc/terms/"
                xmlns:dcmi="http://purl.org/dc/dcmitype/"
                xmlns:foaf="http://xmlns.com/foaf/0.1/"
                xmlns:if="http://purl.org/int-fiction/metadata/1.1/"
                xmlns:iflink="http://purl.org/int-fiction/metadata/iflink/1.0/"
                xmlns:iftype="http://purl.org/int-fiction/metadata/iftype/"
                xml:base="http://example.com/archive/">

</iftype:Catalog>

In XML the catalog itself is the root node, and we declare the XLink namespace instead of the RDF namespace. Also notice that the base URI is the base URI for the catalog itself. In RDF, we can put everything in one file, but in XML each catalog is usually placed in a separate file, because there can be only one root element and it becomes very ungainly to keep nesting catalogs inside their parent's iflink:contents element. We still include the FOAF namespace, but be advised that FOAF was meant for RDF; using it in the less powerful XML language lobotomizes a lot of its key features.

In the rest of the examples, we'll leave out the RDF wrapper and the namespaces in the interest of brevity. Assume they are declared as shown above for all examples.

3.1.2 The Catalog Header Information

Now we'll add the basic catalog information. Catalog are required to have a name, and encouraged to have a few other information elements as well. See 2.2 Catalog Information for full details. We'll give our catalog a name, description, creator, and genre scheme.

The RDF version can also have a foaf:maker. We'll see the resource foaf:maker connects to later on.

Figure 3.1.2.1: Basic Catalog Info in RDF

<iftype:Catalog rdf:about="archive/">
  <dc:title>Example Catalog</dc:title>
  <dc:description>An example catalog to demonstrate the IFCatalog ontology</dc:description>
  <dc:creator>M.D. Dollahite</dc:creator>
  <foaf:maker rdf:resource="directory/dollahite-md"/>
  <iflink:genreScheme rdf:resource="genres#"/>
</iftype:Catalog>

XML isn't powerful enough to cope with real FOAF profiles, so we'll just put an XLink on the dc:creator property.

Figure 3.1.2.2: Basic Catalog Info in XML

<iftype:Catalog xml:base="http://example.com/archive/">
  <dc:title>Example Catalog</dc:title>
  <dc:description>An example catalog to demonstrate the IFCatalog ontology</dc:description>
  <dc:creator xlink:href="/directory/dollahite-md">M.D. Dollahite</dc:creator>
  <iflink:genreScheme xlink:href="/genres#"/>
</iftype:Catalog>

Of course we can have multiple genre schemes and any additional Dublin Core data we choose to add, but this will do for a simple catalog.

Genre Schemes will be explained in another document, so we won't show any examples of them here.

3.1.3 The Catalog Contents

Let's finish up the basic structure by giving the catalog some contents. For this catalog, the contents are simply our three child catalogs.

In RDF, the iflink:contents property contains a blank rdf:Seq node, which in turn lists the child catalogs.

Figure 3.1.3.1: Catalog Contents in RDF

<iftype:Catalog rdf:about="archive/">
  <dc:title>Example Catalog</dc:title>
  <dc:description>An example catalog to demonstrate the IFCatalog ontology</dc:description>
  <dc:creator>M.D. Dollahite</dc:creator>
  <foaf:maker rdf:resource="directory/dollahite-md"/>
  <iflink:genreScheme rdf:resource="genres#"/>

  <iflink:contents>
    <rdf:Seq>
      <rdf:li rdf:resource="archive/games/"/>
      <rdf:li rdf:resource="archive/interpreters/"/>
      <rdf:li rdf:resource="directory/"/>
    </rdf:Seq>
  </iflink:contents>
</iftype:Catalog>

In XML, the iflink:contents element is automatically assumed to be an ordered list. The contents can either be inline resource nodes, or ln elements that give the resource URI in the form of an XLink.

Figure 3.1.3.2: Catalog Contents in XML

<iftype:Catalog xml:base="http://example.com/archive/">
  <dc:title>Example Catalog</dc:title>
  <dc:description>An example catalog to demonstrate the IFCatalog ontology</dc:description>
  <dc:creator xlink:href="/directory/dollahite-md">M.D. Dollahite</dc:creator>
  <iflink:genreScheme xlink:href="/genres#"/>

  <iflink:contents>
    <ln xlink:href="games/">Games</ln>
    <ln xlink:href="interpreters/">Interpreters</ln>
    <ln xlink:href="/directory/">Directory</ln>
  </iflink:contents>
</iftype:Catalog>

Validating user agents with access to the XLink schema ought to download the child catalogs and replace the ln elements with them (much the way an HTML img element is replaced by a graphic), but non-validating user agents will probably just display them as clickable hyperlinks, so we provide some text for them to display inside the ln elements.

Note that we don't have to choose between child catalogs and items, both child catalogs and leaf items can be mixed in the same contents list.

The three child catalogs are defined in much the same way, we'll see what they look like in the next section.

3.2 Catalog Items

Now we'll see how to add the actual catalog inventory. We have three child catalogs, each of which contain a different type of item.

3.2.1 Game Catalogs

Our first catalog contains IF games. It looks basically the same as our parent catalog, except we let some of the information elements be inherited from the parent catalog instead of specifying them ourselves. We also add a dcterms:isPartOf element to help user agents find their way back up the tree.

In RDF, our games catalog looks like this:

Figure 3.2.1.1: The Games Catalog in RDF

<iftype:Catalog rdf:about="archive/games/">
  <dc:title>Example Catalog - Games</dc:title>
  <dc:description>Our inventory of IF games</dc:description>
  <dcterms:isPartOf rdf:resource="archive/"/>

  <iflink:contents>
    <rdf:Seq>
      <rdf:li rdf:resource="archive/games/tangle.z5"/>
      <rdf:li rdf:resource="archive/games/ditch3.t3"/>
    </rdf:Seq>
  </iflink:contents>
</iftype:Catalog>

Not too different from the parent catalog. The catalog contents are just the game resources.

Games are describes using the Interactive Fiction Metadata Element Set [IFMES], but most of that data should either be embedded in or provided along with the game itself, so we just need to fill in the IFLink data specific to our catalog. We'll also provide dc:title elements for the benefit of user agents that just want to display a list of games and don't care about the rest of the IFMES information. Having dc:title elements is also useful to support user agents that only look for Dublin Core data without trying to infer it from other elements.

Figure 3.2.1.2: Game Resources in RDF

<iftype:Game rdf:about="archive/games/tangle.z5">
  <dc:title>Spider and Web</dc:title>
  <foaf:maker rdf:resource="directory/plotkin-a"/>
  <iflink:genre rdf:resource="genres#espionage"/>
  <iflink:genre rdf:resource="genres#sci-fi"/>
  <iflink:platform rdf:resource="http://purl.org/int-fiction/assignments/platforms/vm/zmachine"/>
</iftype:Game>

<iftype:Game rdf:about="archive/games/ditch3.t3">
  <dc:title>Return to Ditch Day</dc:title>
  <foaf:maker rdf:resource="directory/roberts-mj"/>
  <iflink:genre rdf:resource="genres#collegiate"/>
  <iflink:series rdf:resource="series/ditchday"/>
  <iflink:platform rdf:resource="http://purl.org/int-fiction/assignments/platforms/vm/t3"/>
</iftype:Game>

We would also provide links to any alternate, previous, or variant versions of each game if we had them in our catalog. Note that ditch3.t3 is also part of a series. Describing the series is beyond the scope of this document, please refer to the IFType Specification [IFTYPE] for more information. The iflink:platform elements point to a central registry of IF platform identifiers. This registry hasn't been set up yet at the time of writing, but should look something like this. Catalogs can also use their own platform registry, but it's usually better to use a central shared registry for platform identifiers.

For the XML version, we'll list the games inline, right inside the catalog element. We'll use XLink for download and property links. We also change the foaf:maker links into dc:creator elements with XLinks.

This is what we end up with for XML. Note that we put the download link on the title element, so that we don't end up with nested links. This is another good reason to include a dc:title property.

Figure 3.2.1.3: The Games Catalog in XML

<iftype:Catalog xml:base="http://example.com/archive/games/">
  <dc:title>Example Catalog - Games</dc:title>
  <dc:description>Our inventory of IF games</dc:description>
  <dcterms:isPartOf xlink:href="../"/>

  <iflink:contents>
    <iftype:Game>
      <dc:title xlink:href="tangle.z5">Spider and Web</dc:title>
      <dc:creator xlink:href="/directory/plotkin-a">Andrew Plotkin</dc:creator>
      <iflink:genre xlink:href="/genres#espionage">Espionage</iflink:genre>
      <iflink:genre xlink:href="/genres#sci-fi">Sci-Fi</iflink:genre>
      <iflink:platform xlink:href="http://purl.org/int-fiction/assignments/platforms/vm/zmachine">Z-Machine</iflink:platform>
    </iftype:Game>

    <iftype:Game>
      <dc:title xlink:href="ditch3.t3">Return to Ditch Day</dc:title>
      <dc:creator xlink:href="/directory/roberts-mj">Michael J. Roberts</dc:creator>
      <iflink:genre xlink:href="/genres#collegiate">Collegiate</iflink:genre>
      <iflink:series xlink:href="/series/ditchday">Ditch Day</iflink:series>
      <iflink:platform xlink:href="http://purl.org/int-fiction/assignments/platforms/vm/t3">TADS 3</iflink:platform>
    </iftype:Game>
  </iflink:contents>
</iftype:Catalog>

Note that since XML has limited aggregation capabilities, any additional metadata embedded in the game will probably be inaccessible, so the data in the catalog may be all that users get.

Unlike ln elements, property arcs will be displayed as hyperlinks even in validating user agents, so we definitely need to provide some text for the link if we expect to display the catalog to a user directly without transforming it first.

3.2.2 Software Catalogs

Our second catalog includes interpreters used to run IF games. The child catalog itself looks pretty much like the game catalog.

Figure 3.2.2.1: The Software Catalog in RDF

<iftype:Catalog rdf:about="archive/interpreters/">
  <dc:title>Example Catalog - Interpreters</dc:title>
  <dc:description>Our inventory of interpreters</dc:description>
  <dcterms:isPartOf rdf:resource="archive/"/>

  <iflink:contents>
    <rdf:Seq>
      <rdf:li rdf:resource="archive/interpreters/frotz.tar.gz"/>
      <rdf:li rdf:resource="archive/interpreters/playkit.exe"/>
    </rdf:Seq>
  </iflink:contents>
</iftype:Catalog>

For the software resources, we'll just include dc:creator, foaf:maker, iflink:platform, and iflink:implements properties. As with games, additional metadata will probably be available from other sources. There is not currently any established vocabulary for IF software, IFMI is expected to make a recommendation sometime in the future.

Figure 3.2.2.2: Software Resources in RDF

<dcmi:Software rdf:about="archive/interpreters/frotz.tar.gz">
  <dc:title>Frotz</dc:title>
  <dc:creator>David Griffith</dc:creator>
  <iflink:platform rdf:resource="http://purl.org/int-fiction/assignments/platforms/os/posix"/>
  <iflink:implements rdf:resource="http://purl.org/int-fiction/assignments/platforms/vm/zmachine"/>
</dcmi:Software>

<dcmi:Software rdf:about="archive/interpreters/playkit.exe">
  <dc:title>HTML TADS Player's Kit for Windows</dc:title>
  <foaf:maker rdf:resource="directory/roberts-mj"/>
  <iflink:platform rdf:resource="http://purl.org/int-fiction/assignments/platforms/os/win32"/>
  <iflink:implements rdf:resource="http://purl.org/int-fiction/assignments/platforms/vm/t3"/>
</dcmi:Software>

We don't have the creator of the Frotz software in our directory, so we just use dc:creator instead of foaf:maker. The iflink:platform properties use the same theoretical central platform registry we used for games. Also notice the iflink:implements arcs: user agents can figure out which interpreters can play which games by matching the interpreter's iflink:implements with the game's iflink:platform.

The changes needed for the XML version of the software catalog are pretty much the same as for the games catalog.

Figure 3.2.2.3: The Software Catalog in XML

<iftype:Catalog xml:base="http://example.com/archive/interpreters/">
  <dc:title>Example Catalog - Interpreters</dc:title>
  <dc:description>Our inventory of interpreters</dc:description>
  <dcterms:isPartOf xlink:href="../"/>

  <iflink:contents>
    <dcmi:Software>
      <dc:title xlink:href="frotz.tar.gz">Frotz</dc:title>
      <dc:creator>David Griffith</dc:creator>
      <iflink:platform xlink:href="http://purl.org/int-fiction/assignments/platforms/os/posix">POSIX (UNIX)</iflink:platform>
      <iflink:implements rdf:resource="http://purl.org/int-fiction/assignments/platforms/vm/zmachine">Z-Machine</iflink:implements>
    </dcmi:Software>

    <dcmi:Software>
      <dc:title xlink:href="playkit.exe">HTML TADS Player's Kit for Windows</dc:title>
      <dc:creator xlink:href="/directory/roberts-mj">Michael J. Roberts</dc:creator>
      <iflink:platform xlink:href="http://purl.org/int-fiction/assignments/platforms/os/win32">Windows</iflink:platform>
      <iflink:implements rdf:resource="http://purl.org/int-fiction/assignments/platforms/vm/t3">TADS 3</iflink:implements>
    </dcmi:Software>
  </iflink:contents>
</iftype:Catalog>

The same caveats apply as with the games catalog.

3.2.3 Directory Catalogs

We finally come to our third and final catalog, which is a directory of people. We start with the same general type of child catalog we used before.

Figure 3.2.3.1: The Directory Catalog in RDF

<iftype:Catalog rdf:about="directory/">
  <dc:title>Example Catalog - Directory</dc:title>
  <dc:description>Example who's-who directory</dc:description>
  <dcterms:isPartOf rdf:resource="archive/"/>

  <iflink:contents>
    <rdf:Seq>
      <rdf:li rdf:resource="directory/dollahite-md"/>
      <rdf:li rdf:resource="directory/plotkin-a"/>
      <rdf:li rdf:resource="directory/roberts-mj"/>
    </rdf:Seq>
  </iflink:contents>
</iftype:Catalog>

For the people themselves, we use simple FOAF profiles, with just the foaf:name and foaf:mbox_sha1sum properties.

Figure 3.2.3.2: Person Resources in RDF

<foaf:Person rdf:about="directory/dollahite-md">
  <foaf:name>Michael D. Dollahite</foaf:name>
  <foaf:mbox_sha1sum>B69B8B4FD21AA519C868752733FB2114575A29C</foaf:mbox_sha1sum>
</foaf:Person>

<foaf:Person rdf:about="directory/plotkin-a">
  <foaf:name>Andrew Plotkin</foaf:name>
  <foaf:mbox_sha1sum>31E72F3B9A4B5463E98E38C2E0CD1E0E7EC65889</foaf:mbox_sha1sum>
</foaf:Person>

<foaf:Person rdf:about="directory/roberts-mj">
  <foaf:name>Michael J. Roberts</foaf:name>
  <foaf:mbox_sha1sum>4E72DD2397EF18D424D2909741352ED6D4143170</foaf:mbox_sha1sum>
</foaf:Person>

FOAF user agents will use the foaf:mbox_sha1sum property to find the rest of the profile. However, this process depends on the user agent having special knowledge of the FOAF vocabulary and being able to find the complete profile somewhere, so we include foaf:name to make sure at least that much information is available. If we know where the profile is, we can include an rdfs:seeAlso property to pass that information on to the user agent.

Note that it generally makes no sense to assign http: URIs to people, because people cannot be downloaded over the internet (at least not until someone builds that laser from Tron). We can get away with it only if the URI returns a 303 status and redirects to another resource, because that leaves the nature of the original resource undefined [HTTP-Range-14]. If it is not possible to set up the server to send a 303 response, then we'd need to use another method, such as blank nodes or tag: URIs [TAG].

Once again, for the XML version we put the items inline.

Figure 3.2.3.3: The Directory Catalog in XML

<iftype:Catalog xml:base="http://example.com/directory/">
  <dc:title>Example Catalog - Directory</dc:title>
  <dc:description>Example who's-who directory</dc:description>
  <dcterms:isPartOf xlink:href="/archive/"/>

  <iflink:contents>
    <foaf:Person xml:id="dollahite-md">
      <foaf:name xlink:href="dollahite-md">Michael D. Dollahite</foaf:name>
    </foaf:Person>

    <foaf:Person xml:id="plotkin-a">
      <foaf:name xlink:href="plotkin-a">Andrew Plotkin</foaf:name>
    </foaf:Person>

    <foaf:Person xml:id="roberts-mj">
      <foaf:name xlink:href="roberts-mj">Michael J. Roberts</foaf:name>
    </foaf:Person>
  </iflink:contents>
</iftype:Catalog>

The foaf:mbox_sha1sum property is useless in XML, so we leave it out. This means that the information we put in the catalog is all that users will get; there's no chance of combining it with other datasources. (This is what we meant about XML lobotomizing FOAF.) The xml:id properties provide a convenient place for those 303 responses to redirect to.

In this guide we've used FOAF elements in the XML examples for consistency with the RDF examples, but in a real catalog we'd probably want to use something more XML-friendly for our directory entries.

3.3 Catalog Services

Next let's return to the parent catalog and add some services. We'll add three: a customer support page, a terms of service agreement, and a privacy policy. These services are all web pages, but in principle a service can be almost anything other than catalog items.

Here's the RDF version of the catalog again with the iflink:services property added:

Figure 3.3.1: RDF Catalog with Services

<iftype:Catalog rdf:about="archive/">
  <dc:title>Example Catalog</dc:title>
  <dc:description>An example catalog to demonstrate the IFCatalog ontology</dc:description>
  <dc:creator>M.D. Dollahite</dc:creator>
  <foaf:maker rdf:resource="directory/dollahite-md"/>
  <iflink:genreScheme rdf:resource="genres#"/>

  <iflink:contents>
    <rdf:Seq>
      <rdf:li rdf:resource="archive/games/"/>
      <rdf:li rdf:resource="archive/interpreters/"/>
      <rdf:li rdf:resource="directory/"/>
    </rdf:Seq>
  </iflink:contents>

  <iflink:services>
    <rdf:Seq>
      <rdf:li rdf:resource="support/"/>
      <rdf:li rdf:resource="tos/"/>
      <rdf:li rdf:resource="privacy/"/>
    </rdf:Seq>
  </iflink:services>
</iftype:Catalog>

Since the services are webpages, they just need a dc:title and maybe a few other Dublin Core elements.

Figure 3.3.2: RDF Description of Service Webpages

<foaf:Document rdf:about="support/">
  <dc:title>Customer Support</dc:title>
  <dc:description>Our customer support page</dc:description>
</foaf:Document>

<foaf:Document rdf:about="tos/">
  <dc:title>Terms of Service</dc:title>
  <dc:description>Our Terms of Service agreement</dc:description>
</foaf:Document>

<foaf:Document rdf:about="privacy/">
  <dc:title>Privacy Policy</dc:title>
  <dc:description>Our privacy policy</dc:description>
</foaf:Document>

For XML, we'll just put the service resources inline, with XLinks pointing to the actual pages.

Figure 3.3.3: XML Catalog with Services

<iftype:Catalog xml:base="http://example.com/archive/">
  <dc:title>Example Catalog</dc:title>
  <dc:description>An example catalog to demonstrate the IFCatalog ontology</dc:description>
  <dc:creator xlink:href="/directory/dollahite-md">M.D. Dollahite</dc:creator>
  <iflink:genreScheme xlink:href="/genres#"/>

  <iflink:contents>
    <ln xlink:href="games/"/>
    <ln xlink:href="interpreters/"/>
    <ln xlink:href="/directory/"/>
  </iflink:contents>

  <iflink:services>
    <foaf:Document>
      <dc:title xlink:href="/support/">Customer Support</dc:title>
      <dc:description>Our customer support page</dc:description>
    </foaf:Document>

    <foaf:Document>
      <dc:title xlink:href="/tos/">Terms of Service</dc:title>
      <dc:description>Our Terms of Service agreement</dc:description>
    </foaf:Document>

    <foaf:Document>
      <dc:title xlink:href="/privacy/">Privacy Policy</dc:title>
      <dc:description>Our privacy policy</dc:description>
    </foaf:Document>
  </iflink:services>
</iftype:Catalog>

3.4 The Completed Catalog

The complete RDF catalog can be placed in one file or in multiple files connected by rdfs:seeAlso arcs, and, assuming xml:base is properly defined, can live anywhere on the internet. The completed RDF example catalog can be found here <example-catalog.rdf>.

The XML version of the catalog will typically need to be split into multiple files placed at the URIs associated with each catalog. The completed XML example catalog files can be found below.

We could also have simply nested the child catalogs directly inside the iflink:contents element in the parent catalog in place of the ln elements, but having separate files allows each to be placed at a different URI so that they can be accessed just like web pages. Applications using catalogs as internal databases of local files will probably prefer to nest catalogs in one file. For reference, a nested version of the XML example catalog is provided here <example-catalog-nested.xml>.

It is also possible to have it both ways, using the XLink attribute xlink:show="embed" and optionally xlink:actuate="onLoad" (in fact, that is the default behaviour of the ln element), but care must be taken not to get the user agent caught in a circular embedding loop. Cycles are not a problem in RDF.

Appendix A: Schemas

Appendix A.1: Schema for RDF

The following RDF Schema/OWL Ontology is a normative part of this specification. The latest version of this schema is available at <http://purl.org/int-fiction/metadata/schemas/rdf/ifcatalog>. The latest version supercedes the version included below if they differ.

<?xml version="1.0" encoding="utf-8"?>
<!-- http://purl.org/int-fiction/metadata/schemas/rdf/ifcatalog -->
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
         xmlns:owl="http://www.w3.org/2002/07/owl#"
         xmlns:dc="http://purl.org/dc/elements/1.1/"
         xmlns:dct="http://purl.org/dc/terms/">

  <owl:Ontology rdf:about="http://purl.org/int-fiction/metadata/catalog/">
    <dc:title>Interactive Fiction Catalogs</dc:title>
    <dc:description>An ontology for describing catalogs of Interactive Fiction resources.</dc:description>
    <dct:created>2006-03-17T16:38:43</dct:created>
    <dct:modified>$Date: 2006/03/17 17:44:39 $</dct:modified>

    <!-- This Ontology is a union of several other ontologies -->
    <owl:imports rdf:resource="http://purl.org/int-fiction/metadata/iftype/"/>
    <owl:imports rdf:resource="http://purl.org/dc/elements/1.1/"/>
    <owl:imports rdf:resource="http://purl.org/dc/terms/"/>
    <owl:imports rdf:resource="http://www.oaklett.org/map/1.0#"/>
    <owl:imports rdf:resource="http://purl.org/int-fiction/metadata/iflink/1.0/"/>

    <!-- Link to where this and other ontologies can be downloaded -->
    <rdfs:seeAlso rdf:resource="http://purl.org/int-fiction/metadata/schemas/rdf/catalog"/>
    <rdfs:seeAlso rdf:resource="http://purl.org/int-fiction/metadata/schemas/rdf/iflink"/>
    <rdfs:seeAlso rdf:resource="http://purl.org/int-fiction/metadata/schemas/rdf/iftype"/>
    <rdfs:seeAlso rdf:resource="http://purl.org/dc/elements/1.1/"/>
    <rdfs:seeAlso rdf:resource="http://purl.org/dc/terms/"/>
    <rdfs:seeAlso rdf:resource="http://navibar.oaklett.org/specs/nns-10/"/>

  </owl:Ontology>

</rdf:RDF>

Appendix A.2: Schema for XML

The following XML Schema is a normative part of this specification. The latest version of this schema is available at <http://purl.org/int-fiction/metadata/schemas/xml/ifcatalog>. The latest version supercedes the version included below if they differ. This schema is intended for represented Catalogs as plain XML, RDF/XML documents are not expected to validate against this schema.

<?xml version="1.0" encoding="utf-8"?>
<!-- http://purl.org/int-fiction/metadata/schemas/xml/ifcatalog -->
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            targetNamespace="http://purl.org/int-fiction/metadata/iftype/"
            xmlns:iflink="http://purl.org/int-fiction/metadata/iflink/1.0/"
            xmlns:dc="http://purl.org/dc/elements/1.1/"
            xmlns:dct="http://purl.org/dc/terms/">

  <xsd:import namespace="http://purl.org/int-fiction/metadata/iflink/1.0/"/>
  <xsd:import namespace="http://purl.org/dc/elements/1.1/"/>
  <xsd:import namespace="http://purl.org/dc/terms/"/>

  <xsd:element name="Catalog">
    <xsd:complexType>
      <xsd:complexContent>
        <xsd:sequence>

          <xsd:element ref="dc:title" minOccurs="1" maxOccurs="unbounded"/>
          <xsd:element ref="dc:description" minOccurs="0" maxOccurs="unbounded"/>
          <xsd:element ref="dc:creator" minOccurs="0" maxOccurs="unbounded"/>
          <xsd:element ref="dct:modified" minOccurs="0" maxOccurs="unbounded"/>

          <xsd:element ref="iflink:genreScheme" minOccurs="0" maxOccurs="unbounded"/>
          <xsd:element ref="iflink:contents" minOccurs="1" maxOccurs="1"/>
          <xsd:element ref="iflink:services" minOccurs="0" maxOccurs="1"/>

          <xsd:any namespace="http://purl.org/dc/elements/1.1/ http://purl.org/dc/terms/"
                   minOccurs="0" maxOccurs="unbounded"/>

        </xsd:sequence>
      </xsd:complexContent>
    </xsd:complexType>
  </xsd:element>

</xsd:schema>

Changes

References

For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. However, implementors are encouraged to investigate the possibility of applying the most recent editions of the normative documents indicated below. For undated references, the latest edition of the normative document referred to applies.

Normative References

Informative References

This work is licensed under a Creative Commons Attribution 2.5 License.
This copyright and license applies to this document and does not apply to IF data formats, media types, or technology.

Interactive Fiction Catalogs
IFCatalog Specification

Working Draft 20 March 2006

Abstract

Status of this Document

Quick Table of Contents

Full Table of Contents

1 About the IFCatalog Specification

1.1 Document Organization

1.2 Definitions

1.3 Document Conventions

2 Interactive Fiction Catalogs

2.1 The Catalog Resource Type (IFType)

2.2 Catalog Information

2.3 Catalog Structure

2.4 Genres and Genre Schemes

2.5 Game Catalogs

3 Catalog Construction Guide (Informative)

3.1 Setting up the Catalog Tree

3.1.1 The Document Framework

3.1.2 The Catalog Header Information

3.1.3 The Catalog Contents

3.2 Catalog Items

3.2.1 Game Catalogs

3.2.2 Software Catalogs

3.2.3 Directory Catalogs

3.3 Catalog Services

3.4 The Completed Catalog

Appendix A: Schemas

Appendix A.1: Schema for RDF

Appendix A.2: Schema for XML

Changes

References

Normative References

Informative References

Interactive Fiction CatalogsIFCatalog Specification

Working Draft 20 March 2006

Abstract

Status of this Document

Quick Table of Contents

Full Table of Contents

1 About the IFCatalog Specification

1.1 Document Organization

1.2 Definitions

1.3 Document Conventions

2 Interactive Fiction Catalogs

2.1 The Catalog Resource Type (IFType)

2.2 Catalog Information

2.3 Catalog Structure

2.4 Genres and Genre Schemes

2.5 Game Catalogs

3 Catalog Construction Guide (Informative)

3.1 Setting up the Catalog Tree

3.1.1 The Document Framework

3.1.2 The Catalog Header Information

3.1.3 The Catalog Contents

3.2 Catalog Items

3.2.1 Game Catalogs

3.2.2 Software Catalogs

3.2.3 Directory Catalogs

3.3 Catalog Services

3.4 The Completed Catalog

Appendix A: Schemas

Appendix A.1: Schema for RDF

Appendix A.2: Schema for XML

Changes

References

Normative References

Informative References

Interactive Fiction Catalogs
IFCatalog Specification