Introducing IFMES - an IF metadata standard

7 views
Skip to first unread message

Damian Dollahite

unread,
Aug 2, 2005, 9:21:11 AM8/2/05
to
[Crossposted to r.a.i-f and r.g.i-f, followups to r.a.i-f]

For awhile now I've been working on a Mozilla-based IF collection
organizer application. It's about ready for an initial alpha release,
but there are still a few details I need to work out. One of those
details is to develop a vocabulary for the metadata that the application
associates with each game.

While I could just make up my own private dataset like Microsoft so
often does, I decided that if I want my application to one day reach its
full potential I needed an interoperable set that could be adopted by
the entire IF community, so that my app and others like it may one day
be able to simply retrieve the data for a game instead of requiring the
user to input all the information manually.

There are some existing vocabularies, but all of them were developed for
one specific purpose and don't translate well into other environments.
The TADS Gameinfo.txt format is tilted toward the needs of TADS games,
and is not RDF-ready because it doesn't specify a namespace. Baf's Guide
has namespaces, but uses a lot of esoteric ID numbers instead of
human-readable text, and not all the data fields have URLs associated
with them. None of the IF metadata vocabularies I know of are
compatible with the Semantic Web.

So we come to my proposal. The Interactive Fiction Metadata Element Set
version 1.1 is designed to be a general, interoperable, web-ready
metadata standard. Though developed because of my application's needs,
I designed it to be divorced from my application and made into a global
IF metadata standard. At the same time I've tried to maintain
compatibility with existing vocabularies such as those I mentioned above.

The current version of my proposal is available here:

http://purl.org/int-fiction/metadata/1.1

If you bookmark this page, please bookmark the above URL and not the one
it redirects to, as the latter is likely to change in the near future.
The above PURL is permanent, however, and will get you to the right
place for as long as the document is available on the internet.

I would like to receive comments on this proposal---anything I left out,
anything that should be removed, anything that should be changed. As I
said, I hope for this to eventually be adopted as a standard format used
by a variety of IF applications, so I want to make sure it meets
everyone's needs as far as possible.

One thing I haven't included in this version is information of the sort
that Filfre needs, like the object number of the player-character, or
things specific to TADS like visual theme data. Although such data is
not necessarily specific to the respective applications (mine may
eventually have the same capabilities and need the same info), I am
undecided whether it should be part of the basic set or if it should be
an extension. I'd appreciate thoughts on that too.

--
Ryukage

Jimmy Maher

unread,
Aug 2, 2005, 3:19:12 PM8/2/05
to
Damian Dollahite wrote:
> So we come to my proposal. The Interactive Fiction Metadata Element Set
> version 1.1 is designed to be a general, interoperable, web-ready
> metadata standard. Though developed because of my application's needs,
> I designed it to be divorced from my application and made into a global
> IF metadata standard. At the same time I've tried to maintain
> compatibility with existing vocabularies such as those I mentioned above.

Just to make sure I understand what your application is...

I'm picturing an IF front-end that users can download and install,
preferably optionally packaged with interpreters for all of the major
systems. When the user wants to play a game, she searches on whatever
criteria she likes to pick out something that looks interesting. Then
she can launch that game straight from your front end. The appropriate
interpreter will of course be selected and loaded automatically.

If I'm in the ballpark at all with this description, it sounds like a
great idea, useful for us old-timers and possibly absolutely golden for
bringing newbies into the fold. No futzing about with interpreters or
files... just click on a game and play.

I am hoping your application would be Internet-aware right out of the
box, and all of the meta-data you are describing would be dispatched
automagically from a central server somewhere, sort of an I-Tunes of
interactive fiction.

> I would like to receive comments on this proposal---anything I left out,
> anything that should be removed, anything that should be changed. As I
> said, I hope for this to eventually be adopted as a standard format used
> by a variety of IF applications, so I want to make sure it meets
> everyone's needs as far as possible.

Just one quick one I can think of... if your application, as I hope,
will be downloading the game files using the URLs you provide in your
meta-data files, you might want to point to mirror.ifarchive.org instead
of www.ifarchive.org. That way, you will spread the load around
somewhat and avoid the painfully slow central server.

Oh, and you might want to add some functionality to deal with compressed
game files. It should be possible to automagically unzip a file and
feed the result to an interpreter using one of the freely available
Z-libraries. A way to display associated documentation for a game,
whether in zip files with the game file or via another URL, would also
be nice.

> One thing I haven't included in this version is information of the sort
> that Filfre needs, like the object number of the player-character, or
> things specific to TADS like visual theme data. Although such data is
> not necessarily specific to the respective applications (mine may
> eventually have the same capabilities and need the same info), I am
> undecided whether it should be part of the basic set or if it should be
> an extension. I'd appreciate thoughts on that too.

If there's anything I can do to make Filfre work better with what you
have in mind, let me know. It also might be possible to integrate the
SPAG review archive. Feel free to email to discuss.


--
--
Jimmy Maher
Editor, SPAG Magazine -- http://www.sparkynet.com/spag
Thank you for helping to keep text adventures alive!

Tor

unread,
Aug 2, 2005, 6:15:19 PM8/2/05
to
Damian Dollahite wrote:

[snip]

> I would like to receive comments on this proposal---anything I left out,
> anything that should be removed, anything that should be changed. As I
> said, I hope for this to eventually be adopted as a standard format used
> by a variety of IF applications, so I want to make sure it meets

> everyone's needs as far as possible.Good idea.

Do you intend to provide an internet repository of meta-data files,
for looking up things in IF metadata enabled interpreters? If so, what
mechanism were you planning on using for identifying a game file?
md5 or sha1 hash identifiers maybe...

One piece of information that I would like to request is a label,
so that IF-comp and Speed-IF and similar games can be tagged.

Please keep the discussion in the open on the news group.
I would like to support this meta data information in my
MacOS X port of Gargoyle if it pans out. Just last week I was
thinking of mining my own meta-data for games on
the archive, so this could not come at a better time :)

Tor

Mike Roberts

unread,
Aug 2, 2005, 6:45:21 PM8/2/05
to
"Tor" <tor.an...@gmail.com> wrote:
> One piece of information that I would like to request is
> a label, so that IF-comp and Speed-IF and similar
> games can be tagged.

Good idea - and it should be a whole list of labels, not just one, as a
single game could easily fit several such categories. The only problem with
tagging is that it's hard to keep the set of all possible tags coherent over
time, as inevitably someone will unwittingly create a redundant but slightly
different tag (e.g., "IF-Comp" vs "IFComp") because they misread the
original, or because they didn't even know there already was one for what
they had in mind.

--Mike
mjr underscore at hotmail dot com


Andrew Hunter

unread,
Aug 3, 2005, 5:15:02 AM8/3/05
to
Looking at file dates, it's a whole year since I last worked on this,
but you're not the only one.

Zoom's current XML metadata format has documentation at
<http://www.logicalshift.co.uk/etc/IF_XML_metadata.pdf>. You can
remove the /etc/ directory to get what I managed to get done on a
version 1.0 of the format which came out of a discussion on the Inform
developers mailing list on the subject of embedding metadata into
Z-Code files.

The more general 1.0 format required quite a lot of work to the metadata
manager in Zoom, and the dicussion on Inform-dev kind of died, so
nothing so far has happened there.

I point this out, because we have pretty much the same goals: one of the
things that Zoom's iFiction window is supposed to do eventually is provide
a means of downloading games from the if-archive.

Zoom's format has a couple of differences to yours:

- I wasn't particularly interested in RDF at the time. The purpose was
to get a working metadata system first. (Hence the version being 0.9)
- games are by necessity identified by content and not location. This is
why you can load a game from (say) the masterpieces CD and it will show
up in the iFiction window immediately with all details intact.
- with 1.0, I divided the format up into modules, as there is some metadata
that is user-specific (for example, the games star rating is not really
something that should be specified by a game author)
- you can have more than one record per file
- one record can refer to multiple games (which is handy if you are
maintaining metadata for Infocom's games which have many versions)

It's also battle-tested, the older format having been used in Zoom since
2003 (and a really horrible older format since I first wrote Zoom back in
2000). I wrote the ifmetadata.[ch] files in Zoom with the vague notion that
they might get used by other people: they only depend on expat.

I'm still interested in developing the 1.0 format: and it obviously has the
same goals as your format (and was born out of the same necessity):
perhaps we should work on this together?

Andrew.

samwyse

unread,
Aug 3, 2005, 6:22:05 AM8/3/05
to
Damian Dollahite wrote:
> [Crossposted to r.a.i-f and r.g.i-f, followups to r.a.i-f]
>
> For awhile now I've been working on a Mozilla-based IF collection
> organizer application. It's about ready for an initial alpha release,
> but there are still a few details I need to work out. One of those
> details is to develop a vocabulary for the metadata that the application
> associates with each game.

There was some discussion on the Inform compiler mailing list a year or
two ago about meta-data for IF. The hope was to support something like
iTunes or WinAmp for IF. It got as far as deciding that XML would be
good, and that the data could be easily inserted into a Blorb file or
appended to a Z-code file (since the storyfile length in embedded in the
header, trailing data can be ignored by the 'terp). There was some talk
about reaching out the the TADS and Hugo communities, but AFAIK nothing
ever got done.

There was discussion about what fields should be set by the game
developer (game title, author name, etc) and which should be reserved
for the game owner (ranking/reviews, number of times played, etc). And
there was hope that the Inform compiler could notice structured data
inside the source file, much as it already does compiler options, and
that data could be moved painlessly to the XML meta-data region.

Anyway, my point is that there is interest in this, and other people are
willing to use whatever you wind up with.

Jimmy Maher

unread,
Aug 3, 2005, 6:43:24 AM8/3/05
to
Damian sent me the following reply through email, due to some problems
with his newsgroup access. Since Tor expressed the wish to see this
discussion remain completely public, I'm going to take the liberty of
posting Damian's reply here. I'll respond when I have a bit more time...

Damian wrote:

All of the post-accepting news servers I use seem to have gone on the
fritz all at once shortly after my post. Ugh. I'll probably repost some
of this message to RAIF once things are working again.

Jimmy Maher wrote:

> Just to make sure I understand what your application is...
>
> I'm picturing an IF front-end that users can download and install,
> preferably optionally packaged with interpreters for all of the major
> systems. When the user wants to play a game, she searches on whatever
> criteria she likes to pick out something that looks interesting. Then
> she can launch that game straight from your front end. The appropriate
> interpreter will of course be selected and loaded automatically.
>
> If I'm in the ballpark at all with this description, it sounds like a
> great idea, useful for us old-timers and possibly absolutely golden for
> bringing newbies into the fold. No futzing about with interpreters or
> files... just click on a game and play.
>
> I am hoping your application would be Internet-aware right out of the
> box, and all of the meta-data you are describing would be dispatched
> automagically from a central server somewhere, sort of an I-Tunes of
> interactive fiction.
>

That's more or less the idea. At first it will basically just be a
platform-independent (meaning both OS and interpreter) version of the
TADS Game Chest with a few hooks to Baf's Guide, but the ultimate goal
is something like what you describe---an iTunes for IF. Or something
like a Linux package installer (Synaptic, CNR, etc). But as I said,
it'll take more than just virtuous effort on my part to get it there---I
can build the app, but the infrastructure to make it work has to be a
community effort.

At first, the application will be "interpreters sold separately", but
eventually I want it to have built-in interpreters, while retaining the
option of using an external interpreter instead (one of the main reasons
I don't use iTunes is the vendor lock-in). If you look through the RGIF
archives for a post by me in the "Dream Interpreter" thread, you'll find
some more info on what I'm planning for the interpreter side of things.

Another void I hope to fill is to provide full-featured interpreters to
Linux users. I don't know how Glulx games fare on Linux, but I know the
Linux TADS interpreters aren't anywhere near the Windows and Mac
versions. Building my app with Mozilla technology should give me
near-instantaneous support for all three OSes with virtually identical
functionality on each. I just have to figure out how to bridge the VM
kernels to Gecko.

However, unlike what you're doing with Filfre, I don't really plan on
maintaining a single central database all by myself. One of the great
things about RDF is that it can be distributed across dozens of files
all over the internet, then merged into a single unified database on the
fly. This means that users won't have to download a huge wodge of XML
everytime they connect, they can just download the parts they're
interested in. (Ever tried to download that XML directory from the IFA?
It was so big it killed my browser when I tried.) I'll probably create
a central database myself to get things started (finding someplace to
put it is another reason I need community support for this), but I hope
eventually it will be commonplace for authors to include a chunk of
IFMES RDF with every game release. And as I said in my usenet post, I
don't want this to be just for my app, I want it to be something that
other IF cataloging applications---perhaps even Baf's Guide---can make
use of as well. The fact that you have to provide and constantly update
that INI file for Filfre is another example of why something like IFMES
is needed (though admittedly the current spec doesn't help Filfre much).

I will probably also provide special support for IFComp bundles, if the
IFComp operators are willing to create RDF listings for the entries. I
haven't actually downloaded a comp bundle, but I assume the randomizer
thingy just gives you a list of games and you then have to load each one
manually. My app will be able to take an RDF file bundled with the comp
package and plug it in as a category, randomize the sequence, and then
allow the user to simply click the game to launch it. (This feature also
will be lacking from the first release, however.)

> Just one quick one I can think of... if your application, as I hope,
> will be downloading the game files using the URLs you provide in your
> meta-data files, you might want to point to mirror.ifarchive.org instead
> of www.ifarchive.org. That way, you will spread the load around
> somewhat and avoid the painfully slow central server.
>

Good point. I used the central IFA server in the examples because the
RDF:about field needs to be more or less a cannonical identifer for the
game---it identifies which particular file of all the files on the
internet the metadata is describing. Probably a mirrors.ifarchive.org
URL would be equally cannonical, but I might just leave it up to the
applications reading the file to switch the domain on the fly. There's
also the possibility of using a PURL, i.e.
http://purl.org/int-fiction/archive/ that could be pointed to the main
server or the mirrors server as desired. I don't want to register a
PURL for someone else's site without their permission, though. As soon
as my usenet servers are working again I'll be making a post about the
/INT-FICTION/ PURL domain I've registered.

> Oh, and you might want to add some functionality to deal with compressed
> game files. It should be possible to automagically unzip a file and
> feed the result to an interpreter using one of the freely available
> Z-libraries. A way to display associated documentation for a game,
> whether in zip files with the game file or via another URL, would also
> be nice.
>

Hmm. I have been considering the problem of games that require several
files (as many multimedia games do), but zipped games had slipped my
mind. Mozilla does have zlib built-in, so I should eventually be able to
do that. The IFMES already includes an element to reference
documentation, the app will include a built-in web browser (in fact, at
the moment the whole app is a Firefox extension, but I'll probably
retain a minibrowser when I make it standalone), so it'll be able to
display HTML and text format docs right in the program.

Another feature that the built-in interpreters will provide is tracking
which save files go with which game, and the ability to specify a save
to return to immediately upon starting (like TADS already does).
Assuming the game format allows the interpreter to force a restore on
startup.

If you want to get a better idea of technologies available to my
application, read through some of the documentation on xulplanet.com (or
is it .org?) and developer.mozilla.org. Since I'm building it on the
Mozilla platform, it gets access to all the technologies Mozilla uses,
including web browsing, XML, RDF, zlib, Netscape Plugins, XPI, etc., and
can be ported with very little work to any OS Mozilla runs on.

> If there's anything I can do to make Filfre work better with what you
> have in mind, let me know.


What Filfre is doing is already pretty compatible with my work. I just
realized that we have conflicting "release" elements, though---Filfre's
is the internal release number, IFMES's is the release date. I'll have
to do some checking, the conflict might not be a problem if the
different usage can be linked to game format. If there is a problem,
I'll probably just change IFMES's "release" to "date", and add at least
the three z-code fingerprint fields Filfre uses, if not the player and
toplevel object numbers as well. Any interpreter that offers
capabilities like Filfre's will probably need that data as well, so
maybe it's not as esoteric as it at first seems. It might be prudent to
have separate release-number and release-date fields anyway, since even
non-zcode games might want different values for the two. Something I'll
need to look into, find out what actual practice is.

> It also might be possible to integrate the
> SPAG review archive. Feel free to email to discuss.
>

Good idea, though I wonder if a "review" element would end up being
somewhat redundant with the "documentation" element---probably should
include both, though, since they do have different semantic meanings.
IFMES grew out of the internal dataset my app has been using up until
now (thus the 1.1 version number), so I've tended to forget things that
are neither found in Dublin Core nor currently used by my app. Well,
that why I posted it, to get some more eyes to spot the stuff that
slipped my mind.

Thanks for the feedback!

--
M. Damian Dollahite

Andrew Hunter

unread,
Aug 3, 2005, 9:09:22 AM8/3/05
to
In article <mhe6s2-...@sandstone.logicalshift.demon.co.uk>, Andrew Hunter wrote:
> Zoom's current XML metadata format has documentation at
><http://www.logicalshift.co.uk/etc/IF_XML_metadata.pdf>. You can
> remove the /etc/ directory to get what I managed to get done on a
> version 1.0 of the format which came out of a discussion on the Inform
> developers mailing list on the subject of embedding metadata into
> Z-Code files.

Well, having dug this out, I couldn't resist adding some of the updates
from my TODO list. I've modified the version of the specification at
<http://www.logicalshift.co.uk/IF_XML_metadata.pdf>: if you have the
version dated April 2004, you might want to look at the new version: this
now contains my thoughts on what the resources and review modules should
contain (and is actually capable of expressing all the metadata that Zoom
stores for a game now, including the stuff that's currently hidden in a
preference file)

For those of you who don't have a mac, there's a screenshot of Zoom's
browser here:

<http://www.logicalshift.demon.co.uk/mac/iFiction.png>

(taken a year ago, so the graphics in the current version are a bit
different)

Andrew.

ChicagoDave

unread,
Aug 3, 2005, 11:05:46 AM8/3/05
to
I love it.

The one thing I'd change from my experiences with doing the IF Library
would be to eliminate genre and replace it with "keywords". But I guess
you could leave genre in and add keywords.

Good work.

David C.

Damian Dollahite

unread,
Aug 3, 2005, 5:36:02 PM8/3/05
to


I suggest that each comp should publish an RDF listing of the games
they
include. This is very simple, it would look something like this:

<?xml version="1.0"?>
<RDF:RDF xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:DC="http://purl.org/dc/elements/1.1/">

<RDF:Description RDF:about="http://the.competition.website.com"
DC:title="The Competition Title">
<DC:relation
RDF:resource="http://the.competition.website.com/games"/>
</RDF:Description>

<RDF:Seq RDF:about="http://the.competition.website.com/games">
<RDF:li RDF:resource="URL_of_game_1"/>
<RDF:li RDF:resource="URL_of_game_2"/>
<RDF:li RDF:resource="URL_of_game_3"/>
</RDF:Seq>

</RDF:RDF>

Okay, so that does look kinda complicated, but most if it's
boilerplate. Once a specification for comp metadata has been drafted,
we can just make a fill-in-the-blanks template.

An RDF parser can merge this listing with the listings for other comps
and whatever other metadata it has on hand for individual games, then
simply do a "GetIncomingArcs" query to find out what competitions
reference the game in question. RDF has a very fluid nature that
allows
data from multiple sources to be aggregated and manipulated as if it
were one big database the size of the entire internet. RDF parsers can

load as much or as little of this gigantic database as they need.

The tag idea would serve a slightly different purpose, that might be
redundant or might compliment the above idea. It would basically be a
duplicate arc in the graph, pointing back from the game to the comp
instead of from the comp to the game. It would be useful when you have

a game and want to know which comps it was in, instead of the other way

around. In practice, however, I don't think it would be that useful,
because the comp listings are static and could therefore be cached
locally by the application, making the forward lookup just as fast or
faster than the reverse lookup.

The trick is that for all this to work, there needs to be one
cannonical
URL to identify each game, so that the RDF:resource value in the comp
listings match the RDF:about value in the game's metadata. That's not
as hard as it sounds, though, since we've got this convenient little
IF-Archive providing static URLs for most comp games. Non-comp
revisions of comp games are not the same game that was entered in the
comp, and therefore should only reference the comp indirectly, by
referencing the comp version in DCTERMS:isVersionOf,
DCTERMS:supercedes, etc.

Damian Dollahite

unread,
Aug 3, 2005, 6:26:10 PM8/3/05
to

Andrew Hunter wrote:
> Looking at file dates, it's a whole year since I last worked on this,
> but you're not the only one.
>
> Zoom's current XML metadata format has documentation at
> <http://www.logicalshift.co.uk/etc/IF_XML_metadata.pdf>. You can
> remove the /etc/ directory to get what I managed to get done on a
> version 1.0 of the format which came out of a discussion on the Inform
> developers mailing list on the subject of embedding metadata into
> Z-Code files.
>
> The more general 1.0 format required quite a lot of work to the metadata
> manager in Zoom, and the dicussion on Inform-dev kind of died, so
> nothing so far has happened there.
>
> I point this out, because we have pretty much the same goals: one of the
> things that Zoom's iFiction window is supposed to do eventually is provide
> a means of downloading games from the if-archive.
>

I'll take a look at this, and see where it fits together. I've already
made some big changes after reviewing the TADS Gameinfo format
(discovered it wasn't set up quite the way I remembered), I'll see what
I can derive from your format as well. Part of the goal of IFMES is to
unify the various metadata formats we're already using and bridge them
to the Dublin Core, which is one of the key standards in the W3C's
Semantic Web project. Dublin Core is designed to be generic enough for
almost anything, but was meant for online library catalogues
especially, so it's fairly well-suited to IF.

> Zoom's format has a couple of differences to yours:
>
> - I wasn't particularly interested in RDF at the time. The purpose was
> to get a working metadata system first. (Hence the version being 0.9)

Interested in RDF now? It's really powerful for something so simple.

For everyone who wants to take a peek at RDF, the best tutorial I've
found is here:

http://xulplanet.com/tutorials/mozsdk/rdfstart.php

The first couple pages discuss RDF in general, then it moves on to
Mozilla specifics.

> - games are by necessity identified by content and not location. This is
> why you can load a game from (say) the masterpieces CD and it will show
> up in the iFiction window immediately with all details intact.

RDF and Semantic Web require identifying resources by URI, but I'll
probably need to introduce a secondary identifier that doesn't change
when the game is moved. Just what form that will take is something
I've not yet thought out. My current idea for z-code, based on how
Filfre identifies games, is to concatenate the release, serial, and
checksum numbers with hyphens. That's only for z-code, though, and I
don't know enough about the format to know if that's full-proof. I do
expect that the method used to "fingerprint" games will have to vary
from format to format.

> - with 1.0, I divided the format up into modules, as there is some metadata
> that is user-specific (for example, the games star rating is not really
> something that should be specified by a game author)

A valid point, but probably beyond the scope of IFMES. One of the cool
things about RDF is that the data can be spread across two, five, ten,
or a hundred different files, and it doesn't make any difference---as
long as the RDF:about attributes match, the parser will put it all
together just the same as if it were all in one file.

Anyway I think the IFMES spec will simply define the elements, and
leave it to another standard to determine which should be filled by
authors and which by other people. Plus it's likely that IFMES won't
even define elements outside those that should be filled by the author.
Other elements like ratings, etc., would be left to another
vocabulary.

> - you can have more than one record per file

Same with IFMES. I only showed one record in my examples, but you can
put as many as you want in an RDF file, you can even mix it with other
RDF vocabularies, and even totally unrelated RDF information.

> - one record can refer to multiple games (which is handy if you are
> maintaining metadata for Infocom's games which have many versions)
>

It's not possible in RDF for one record to refer to multiple games, but
it might be possible to introduce an indirection scheme in which
multiple records delegate to a single master template.

Though actually, RDF doesn't really have any notion of records. RDF
models what mathematicians call a _directed_graph_, a set of nodes
connected by directional arcs, like a flowchart. You can go beyond
this model and decide that you want to treat a node and the targets of
it's outgoing arcs as a record, but that's a convention of the
application, not a feature of RDF itself.

And come to think of it, Dublin Core includes a variety of elements
meant to link different versions of the same document together. I don't
see any need to duplicate these in IFMES since it can be freely mixed
with DC in any namespace-aware language, but I could define that
missing elements should be looked for on other versions.

> I'm still interested in developing the 1.0 format: and it obviously has the
> same goals as your format (and was born out of the same necessity):
> perhaps we should work on this together?
>

Isn't that what we are doing here?

Damian Dollahite

unread,
Aug 3, 2005, 6:47:46 PM8/3/05
to

Andrew Hunter wrote:
> For those of you who don't have a mac, there's a screenshot of Zoom's
> browser here:
>
> <http://www.logicalshift.demon.co.uk/mac/iFiction.png>
>
> (taken a year ago, so the graphics in the current version are a bit
> different)
>

Looks not unlike what I'm working on. Of course since mine is based on
Mozilla, it should be trivial to port it to all three of the big OSes,
and depending on how many features they pack into Minimo, maybe even
the portable OSes. :)

If you want to get an idea of what mine looks like, you can check out
my TADS 3 GameChest suggestions at

http://members.aol.com/ryukage/tads3/gcp/

I've refined my ideas a bit since I made those pages, but the core
concept is still based on Layout 2.

Damian Dollahite

unread,
Aug 5, 2005, 12:02:53 PM8/5/05
to
I have drafted a new version of the IFMES specification. This is a
major revision, with improved compatibility for TADS Gameinfo and
iFiction story indexes. I have also attempted to address some concerns
Andreas Sewe brought up by e-mail, regarding the handling of elements
that can have multiple values. It should also address some of the
other concerns brought up regarding the previous version.

The new specification can be accessed at the same URL as the old one:

http://purl.org/int-fiction/metadata/1.1

Both specifications are still available for reference, there is version
information and links in the document itself.

Sewe's concern about multiple values was essentially that I had allowed
authors to pick pretty much any separator they wanted when
concatenating the values into a single string. This, I agreed, could
make a mess; however there is no one separator character that works in
all cases, and not all storage formats have the ability to repeat
elements.

This version of the spec suggests that the rules should be stricter
than the previous version, but still doesn't present a complete
methodology.

After I finalized the text for this version, I thought of a possible
way to solve the problem. It involves the introduction of a special
set of psuedo-elements of the form: "all*ELT" where ELT the multi-value
element and * is a user-selected separator character. These special
elements would allow multiple-value elements to be expressed in
concatenated form using a separator appropriate to the values being
stored, while at the same time providing applications reading the data
with knowledge of what that separator is. The optimal separator
character of whitespace (XML defines a whitespace-separated list type,
so that is the best separator for existing XML parsers) would be
expressed by leaving the separator character out of the element name
entirely. Does this sound like a suitable solution?

To Mike Roberts:
I've taken care to craft this version of the standard so that existing
Gameinfo.txt files are valid IFMES files as well. The one thing I
changed was to use a "title" element instead of a "Name" element, for a
more precise semantic meaning and to make it more closely parallel
other vocabularies. I've retained "Name" as a deprecated element for
compatibility, but I'd like to know what your thoughts are regarding
changing the Gameinfo.txt format to match the IFMES spec.

To Andrew Hunter:
In adapting your IF XML format to RDF, I had to use a slightly
different namespace, as noted in the specification. With the namespace
you used, you ended up with full elements names like
"http://www.logicalshift.org.uk/IF/metadataifindex" and
"http://www.logicalshift.org.uk/IF/metadatastory"---there's nothing to
separate the namespace part from the tag name in the fully-qualified
name. This doesn't matter much in XML because you always use namespace
shorthand, but RDF parsers need a separator character. So for IFMES, I
added a trailing slash to the namespace. It could also be a hash mark
if that would be more appropriate---it doesn't seem to link to any
actual resource, so I suspect it doesn't matter.

Mike Roberts

unread,
Aug 7, 2005, 4:06:39 PM8/7/05
to
"Damian Dollahite" <ryu...@aol.com> wrote:
> To Mike Roberts:
> I've taken care to craft this version of the standard so that
> existing Gameinfo.txt files are valid IFMES files as well.

Great - that's a nice feature.

> The one thing I changed was to use a "title" element instead
> of a "Name" element, for a more precise semantic meaning
> and to make it more closely parallel other vocabularies. I've
> retained "Name" as a deprecated element for compatibility,
> but I'd like to know what your thoughts are regarding
> changing the Gameinfo.txt format to match the IFMES spec.

I don't feel too strongly about it one way or the other. On the one hand,
consistency with other standards can't hurt; on the other, 'Name' would have
to be more or less permanently retained as a deprecated synonym for 'Title',
so (a) you wouldn't be able to reuse 'Name' for other purposes, and (b) any
gain in ease of use from using a label that matches other systems might be
offset by the fact that there will be two labels in use for the same thing.
The on-the-other-hand problems are more issues for IFMES than for GameInfo,
though, since the GameInfo format is completely hidden behind library
mechanisms at this point anyway.

Damian Dollahite

unread,
Aug 9, 2005, 1:05:58 PM8/9/05
to
To help those of you already implementing this, and those of you just
trying to understand it in more concrete terms, here's a sample RDF
file actually generated by my application:

http://members.aol.com/ryukage/int-fiction/sample.xml

It's a little hard to read, as Mozilla's RDF serializer doesn't pay too
much attention to formatting and sequencing, but I refrained from
cleaning it up in order to stress that the XML used to convey the RDF
is not important.

The non-IFMES data in the file is a little scrambled right now, as I'm
shifting my namespacing plans from the single "urn:x-bookwyrm:rdf#"
namespace to more standardized namespaces like IFMES and DC.

It should also be noted that my app uses localized values for some of
the elements, not the proper cannonical ones. The "icon" element, for
example, uses a special Mozilla protocol to get the icon that the OS
would use for the file, which is not what you'd want to do in an
internet archive index.

I've also got some screenshots of my application running, so you can
see what the above file looks like when you actually load it into the
app:

http://members.aol.com/ryukage/int-fiction/Bookwyrm-manager.jpg
http://members.aol.com/ryukage/int-fiction/Bookwyrm-options.jpg

The first image is the main story list, the second is the options
dialog with the interpreters page open.

Reply all
Reply to author
Forward
0 new messages