On Mon, Dec 8, 2008 at 5:03 PM, Eric Scheid <[EMAIL PROTECTED]> wrote: > > On 9/12/08 3:59 AM, "Peter Keane" <[EMAIL PROTECTED]> wrote: > > >> 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. > > What I meant is that are the values of the keys likely to be shared amongst > multiple members of the larger data set, and would it make sense to group > according to those values? If not, you don't have a category, just values. > For example, assigning "tall" or "short" to a "height" key would be > categorising, while assigning "1.72", "1.73", "1.85", "1.54" to a "height" > key wouldn't be categorising.
In general, you are right, and it's a good heuristic. That said, it is not possible, simply by looking at data, to determine whether we are talking categories or not. Imagine a feed describing drill bits, with a category "size" and some values: 1.75mm 1.778mm 1.8542mm 1.9304mm These are standard drill bit sizes, well known/documented, etc. Quite appropriately "categories." In practice, its almost impossible to draw a distinct line between "categorical" metadata and non-categorical. A system like Filemaker (we do lots of imports from legacy Filemaker databases) serializes as simple <row><col><data/></col></row> xml for the same reason -- it's completely up to the user to give "shape" to the data. It's actually a very common pattern: spreadsheets, tagging (which I am sure had an influence on atom:category), etc. -- all user-generated metadata. I continue to be intrigued by what I view as a built in extension point in atom:category -- certainly the spec leaves things wide open as to how it might be used. My aim is to provide a way to get arbitrary metadata in and then be able to deliver it back out in full fidelity, whether I use atom:category for that or something else. Oh -- I am reminded of one reason I have been exploring atom:category instead of a simple extension elements: I would like to be able to use Atom/AtomPub to deal with categories. A service document could provide a discovery point for the available attributes (aka categories). I am still puzzling over an AtomPub method to add categories to a collection (perhaps accept application/atomcat+xml in the service doc?). Ultimately I want to expose all of the functionality of the system by way of Atom/AtomPub so we (meaning not *me* ;-)) can build custom interfaces on top of it w/o dealing with databases and filesystems directly. I already have to maintain enough not particularly constructed PHP/MySQL apps (usually built by a long-since-graduated CS student) that I see this as a good way to rationalize things. regards- Peter > > This distinction may not be important or relevant for your context or > application, of course. > > e. >
