Ross Singer wrote:
<?xml version="1.0" encoding="UTF-8"?>
<format name="foaf" uri="http://xmlns.com/foaf/0.1/"/>
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)
vcard-temp (see http://xmpp.org/registrar/namespaces.html)
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ß <jakob.v...@gbv.de>, skype: nichtich
Verbundzentrale des GBV (VZG) / Common Library Network
Platz der Goettinger Sieben 1, 37073 Göttingen, Germany
+49 (0)551 39-10242, http://www.gbv.de