On Mon, Dec 8, 2008 at 9:58 AM, Eric Scheid <[EMAIL PROTECTED]>wrote:
> > On 8/12/08 6:19 PM, "Peter Keane" <[EMAIL PROTECTED]> wrote: > > > This would be great in an ideal world, but the key-value pairs are all > > arbitrary (created by users, serialized to atom for syndication & atompub > > manipulation -- like in a spreadsheet -- column name/cell value). > > Sounds very much like you are trying to shoe horn non-categorical metadata > into the atom:category construct. Please don't do this ;-) Well, I guess it depends what you mean by categorizing. Is asserting an RDF triple in a sense "categorizing"? While I could imagine lots of things that are categorical metadata, I'd have a tough time figuring out a good set of criteria to define "non-categorical" metadata. Now "best practices" is another matter -- it's a hack, for sure. > > Since I now use a simple extension element for these key-value pairs, I > was > > thinking about using category instead -- the Balisage paper I cited in my > > original message piqued my interest there. (Oh, BTW my example left out > the > > scheme, which would be something like "http://example.com/metadata";). > > What would using the <atom:category/> syntax buy you that a > <pkeane:key-value/> extension wouldn't? Surely you're not hoping for > interoperability of your key-value data with the wider publishing world? > Perhaps not much -- I'd refer you to the paper I cited in my original post [1] for a description of one possible benefit. I do use the extension that you describe and it indeed works fine. There's been discussion in the past about atom:category as a possible "RDFish extension point," [2], and efforts to embed triples in Atom [3] -- I am just curious to know if other folks are looking at things similarly vis-a-vis atom:category (sounds like not). For me the bottom line is: that I have a large (~200K items) digital repository used on a large university campus (UT Austin -- daseproject.org) that uses Atom/AtomPub extensively. Of the multitude of users from all discipline that use it in a variety of ways, the central need is that we have "collections" of items, each item of which has a digital object attached (image, mp3, pdf, etc.) plus derivatives, and an arbitrary set of key-value pairs, and often a large chunk of textual content. Just meeting those criteria we've eliminated all sorts of one-off collections of digital stuff in spreadsheets, Access, Filemaker, php/mysql apps, etc. with a very standardized way to deal with them. New projects take a matter of days rather than weeks to get off the ground, and archiving/preservation becomes much simpler. I don't really feel all that strongly about how we might serialize the key/vals in Atom. It's basically a two-line change in my code for serializing/unserializing. That said, I have tried as much as possible to hue closely to Atom/AtomPub and have indeed found that other tools (MarsEdit, say, or the Picasa Image uploader) can start to provide useful functionality for this app. Google Spreadsheets is the only obvious example I have found of a similar need and they use a custom extension. I have begun looking at using category in another unusual way, as essentially the inverse of a "link" [4]. Which would allow me to use AtomPub to create "links" between resources. But that's another (not entirely unrelated) kettle of fish.... >> <category >> scheme='http://www.loc.gov/catdir/cpso/lcco/' >> term="SF429.S65" >> label="siberian husky" /> > > >> <!-- note: term may not be entirely accurate, IANAL --> > >> <!-- (where L = Librarian, of course ;-) --> > >> > > This would certainly not work for me since I am, in fact, a librarian > ;-)! > > (just curious btw - was I close with the LOC term for siberian husky, or > did > I clumsily misappropriate the wrong meta-data value from www.loc.gov?) > Actually, I don't really know. Although I have an MLIS, for all intents & purposes I might as well be "NAL" ;-). --peter [1] http://www.balisage.net/Proceedings/html/2008/Milowski01/Balisage2008-Milowski01.html [2] http://torrez.us/archives/2006/05/25/447/ [3] http://www.ietf.org/internet-drafts/draft-nottingham-atomtriples-00.txt [4] http://www.imc.org/atom-syntax/mail-archive/msg20770.html > > > e. > >
