Ross Singer wrote:

<?xml version="1.0" encoding="UTF-8"?>
<formats xmlns="";>
 <format name="foaf" uri=""/>

I generally agree with this, but what about formats that aren't XML or
RDF based?  How do I also say that you can grab my text/x-vcard?  Or
my application/marc record?  There is still lots of data I want that
doesn't necessarily have these characteristics.

In my blog posting I included a way to specify mime types (such as as text/x-vcard or application/marcURI) as URI. According to RFC 2220 the application/marc type refers to the "harmonized USMARC/CANMARC specification" whatever this is - so the mime type can be used as format identifier. For vCard there is an RDF namespace and a (not very nice) XML namespace:
vcard-temp (see

If you want to identify a defined format, there is almost always an identifier you can reuse - if not, ask the creator of the format. The problem is not in identifiers or the complexity of formats but in people that create and use formats that are not well defined.

What about XML formats that have no namespace?  JSON objects that
conform to a defined structure?  Protocol Buffers?

If something does not conform to a defined structure then it is no format at all but data garbage (yes, we have a lot of this in library systems but that's no excuse). To refer to XML or JSON in general there are mime types. If you want to identify something more specific there must be a definition of it or you are lost anyway.

And, while I didn't really want to wade into these waters, what about
formats that are really only used to carry other formats, where it's
the *other* format that really matters (METS, Atom, OpenURL XML,

A container format with restricted carried format is a subset of the container format. If you cannot handle the whole but only a subset then you should only ask for the subset. There are three possibilities:

1. implicitely define the container format and choose the carried format. This is what SRU does - you ask for the record format but you always get the SRU response format as container with embedded record format.

2. implicitely define the carried format and choose the container format

3. define a new format as combination of container and carried format

unAPI should be revised and specified bore strictly to become an RFC anyway.
Yes, this requires a laborious and lengthy submission and review process but
there is no such thing as a free lunch.

Yeah, I have no problem with this (same with Jangle).  The argument
could be made, however, is there a cowpath yet to be paved?

That depends whether you want to be taken serious outside the library community and target at the web as a whole or not.


Jakob Voß <>, skype: nichtich
Verbundzentrale des GBV (VZG) / Common Library Network
Platz der Goettinger Sieben 1, 37073 Göttingen, Germany
+49 (0)551 39-10242,

Reply via email to