Metadata

We want volity UI files to contain lots of metadata. They should be self-describing, as much as possible. This enables the client to get hold of useful information just by loading the UI file. It also enables the bookkeeper to extract this information when a UI file is registered, thus simplifying the task of filling in the bookkeeper's database.

(This also applies to pluggable resource files, such as card deck art.)

Metadata which we want:

The generic elements (title, author, etc) are covered by the Dublin Core vocabulary. I think it's reasonable to say "Use Dublin Core where possible." The client and bookkeeper will only pay attention to a few of the DC terms, but if a developer wants to stick in more of them, that's great.

We do, however, need our own vocabulary for a few items. The "version_matching.html" class=wikipagelink>ruleset versioning is its own bundle of joy.

The big question is: how do we wedge this data into an SVG file? The SVG spec supports a <metadata> tag [1], but doesn't specify what you should put into it. It gives an example of an RDF document fragment containing DC data.

My current proposal is simply to stick XML-ified DC elements (and our own) directly into the <metadata> element. We can use xml:lang attributes to distinguish localizations of human-readable elements.

(Footnote: SVG has a <title> element. We scan for that as a special case alternative to <dc:title> in <metadata>.)

Further Details

The metadata can contain anything, but Volity software will mostly pay attention to three vocabularies:

In general, XML tags and extra whitespace inside an element's character data will be ignored.

Human-readable elements (<dc:title>, <dc:description>, etc) can have an xml:lang attribute which specifies what language they are in. It is reasonable to supply multiple elements with the same name and different languages.

SVG Metadata Example

  <metadata
    xmlns:dc="http://purl.org/dc/elements/1.1/"
    xmlns:volity="http://volity.org/protocol/metadata">
    <dc:title>Fluxx Standard Interface</dc:title>
    <dc:title xml:lang="pla">Uxxflay Andardstay Interfaceay</dc:title>
    <dc:language>en</dc:language>
    <dc:language>pla</dc:language>
    <volity:ruleset>http://volity.org/games/fluxx#2.0</volity:ruleset>
  </metadata>

(Note that pla is an imaginary language code for Pig Latin.)

What about RDF?

RDF looks great until you read the spec, at which point your eyeballs start to twitch uncontrollably. Well, mine did.

Furthermore, it's a pain to support. The primary open-source Java library for parsing RDF is Jena [2], which is a two-megabyte JAR file plus five or so megs of supporting JARs. Mind you, that comes with database support and a logical-inference engine for queries into the RDF model. The fact that these features are a good idea seems like evidence that RDF is too much work for our needs.

What do we lose by not using RDF?

I see no need for any of these. Flexibility is confusing. We can handle multiple values by accepting multiple elements (see <dc:language> in my example). And the third "feature" is actually a slight headache, which we are better off avoiding. (An RDF description wants to be about a specific URI. It is possible to specify "the URI of this file, you idiot" but it takes a bit of futzing. In my proposal, all metadata is about the SVG file that the <metadata> element is in.)

Another possibility is to embed code (javascript code for a UI file) which returns metadata information in response to queries. I mention this only so that we may all admire the pure badness of the idea. (The bookkeeper powering up a Javascript interpreter in order to extract info from a UI? Bleah.)