Subject: text in atom:category?

From: "Peter Keane" <[email-masked]>
Date: Mon, 8 Dec 2008 04:17:51 +0000

I am getting an error from the feedvalidator for text in the atom:category
element:

<category term='breed'>siberian husky</category>

But the spec says it "assigns no meaning to the content" and the
RNC seems to allow it.  I'd like to use atom:category here instead of:

<x:breed>siberian husky</breed>

which DOES validate.

BTW, the example comes from Alex Milowski's paper [1] from Baliasge,
which makes extensive use of text w/in atom:category (and it's quite handy).

--peter keane

[1] http://www.balisage.net/Proceedings/html/2008/Milowski01/Balisage2008-Milowski01.html

---

From: Eric Scheid <[email-masked]>
Date: Mon, 08 Dec 2008 17:20:52 +1100

On 8/12/08 3:17 PM, "Peter Keane" <[email-masked]> wrote:

> RNC seems to allow it.

Hmm ... I suspect what you actually want to do is instead something like
this:

    <category scheme='breed' term="siberian husky" />

(where 'breed' would actually be an IRI, not a keyword).

I wouldn't try this though:

    <category term='breed' label="siberian husky" />

... because that is syntactically the same category as:

    <category term='breed' term="any other breed" />

Finally, if your category scheme has unfriendly codes for terms then you
would do this:

    <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 ;-) -->

Bottom line is don't go putting what you think is the label for the category
as text content of the element because (a) we have an attribute specifically
for that purpose, and (b) it gets messy if someone else wants to put an
extension element in as content ...

    <category ...>
        <x:see-also ref="foo" />
    </category>

e.

---

From: Aristotle Pagaltzis <[email-masked]>
Date: Mon, 8 Dec 2008 07:30:08 +0100

* Peter Keane <[email-masked]> [2008-12-08 05:30]:
> But the spec says it "assigns no meaning to the content" and
> the RNC seems to allow it.

If the validator went strictly by the spec (the RNC is informal
anyway) then it couldn’t flag many obvious errors because of
Atom’s mustIgnore nature. Typos like `<caetgory>` would have to
be considered valid, f.ex., even though nothing will process such
a feed correctly.

> I am getting an error from the feedvalidator for text in the
> atom:category element:
>
> I'd like to use atom:category here instead of:
>

I am not sure what it is supposed to mean. Isn’t the text in the
element semantically significant? It seems to me you are looking
for this:

    <category
        scheme="http://example.org/breed"
        term="siberian-husky" />

Maybe with a `label="siberian husky"` thrown in for humans.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: "Peter Keane" <[email-masked]>
Date: Mon, 8 Dec 2008 07:02:50 +0000

On Mon, Dec 8, 2008 at 6:30 AM, Aristotle Pagaltzis <[email-masked]>wrote:

> anyway) then it couldn't flag many obvious errors because of
> Atom's mustIgnore nature. Typos like `<caetgory>` would have to
> I am not sure what it is supposed to mean. Isn't the text in the

  <category

       term="siberian-husky" />

Yes, that's the idea -- I need to apply arbitrary key-value pairs to an
entry.  I'd like to use inner text, though, since the value could be of any
length (maybe even an entire essay).  Right now, I approach it like Google
Spreadsheets does:

<entry xmlns:gsx="http://schemas.google.com/spreadsheets/2006/extended">
....
    <gsx:type>Task/Job Request</gsx:type>
    <gsx:eid>pppp</gsx:eid>
    <gsx:name>hgkjhgk</gsx:name>
    <gsx:text>some arbitrary textj</gsx:text>
  </entry>

But was thinking I might use atom:category instead.  I realize that
atom:content would be a logical place for this stuff (perhaps as RDF or
XOXO), but many of these entries *do* in fact, have textual content that's
not as much like "metadata" as these key-value pairs.

--peter

---

From: "Peter Keane" <[email-masked]>
Date: Mon, 8 Dec 2008 07:19:24 +0000

On Mon, Dec 8, 2008 at 6:20 AM, Eric Scheid <[email-masked]>wrote:

> atom:category

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).  I
actually use category in various other ways -- e.g. < category scheme="
http://example.com/cat/background" term="white"/> to state what the
background color should be when the image represented by this entry is used
in a slideshow (utterly useless except in my own app).

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").

>    <!-- (where L = Librarian, of course ;-) -->

This would certainly not work for me since I am, in fact, a librarian ;-)!

> extension element in as content ...

That's a very good point, and there has been some discussion here or on
atom-protocol about using atom:link under atom:category.  Although,
interestingly the RNC says text is OK and atom constructs are a no-no there.

thanks-
Peter

---

From: Eric Scheid <[email-masked]>
Date: Tue, 09 Dec 2008 02:58:04 +1100

On 8/12/08 6:19 PM, "Peter Keane" <[email-masked]> wrote:

> 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 ;-)

> 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?

> 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?)

e.

---

From: "Peter Keane" <[email-masked]>
Date: Mon, 8 Dec 2008 10:59:54 -0600

> 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.

> 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....

> 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

---

From: Bill de hOra <[email-masked]>
Date: Mon, 08 Dec 2008 21:03:55 +0000

> be considered valid, f.ex., even though nothing will process such

File a bug with the feedvalidator maintainer - text element content is 
allowed as a child of atom:category.

This is a separate matter as to whether element content is what you 
want/need.

Bill

---

From: Eric Scheid <[email-masked]>
Date: Tue, 09 Dec 2008 10:03:13 +1100

On 9/12/08 3:59 AM, "Peter Keane" <[email-masked]> wrote:

> 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.

This distinction may not be important or relevant for your context or
application, of course.

e.

---

From: Eric Scheid <[email-masked]>
Date: Tue, 09 Dec 2008 10:07:49 +1100

> This is a separate matter as to whether element content is what you

and in any case, inserting text into the element content is risky, as it's
no different from any other extension inserting text there. At the least,
consider doing this:

    <category ...>
        <pkeane:text>blah blah</pkeane:text>
    </category>

that way, the next developer coming along could do the following without
borking your original content:

    <category ...>
        <pkeane:text>blah blah</pkeane:text>
        <escheid:meta>bork bork bork</escheid:meta>
    </category>

e.

---

From: "Peter Keane" <[email-masked]>
Date: Tue, 9 Dec 2008 02:53:34 +0000

> 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

---

From: Eric Scheid <[email-masked]>
Date: Tue, 09 Dec 2008 14:46:52 +1100

On 9/12/08 1:53 PM, "Peter Keane" <[email-masked]> wrote:

> I am still puzzling over an AtomPub method to add
> categories to a collection

I've long thought it should* be possible to do this via posting entries to a
designated collection, where each entry is "about" one category. The content
of the entry, ie. the nominated category, would go inside the
<atom:content/> element, with the <atom:summary/> available for any
comments/notes about it's use/provenance etc. The sweet thing about this is
that you can then use <atom:category/> elements (as immediate children of
<atom:entry/>) to designate category collection management meta-data.

For example:

<entry>
    <title>Siberian Huskies</title>
    <author><name>Sally "Woofer" Jones</name></author>
    <category 
        scheme="http://example.com/atompub/atomcat/status"
        term="proposed" />
    <summary type="text">The dog breed</summary>
    <content type="application/atomcat+xml">
        <category 
            scheme='http://www.loc.gov/catdir/cpso/lcco/'
            term="SF429.S65"
            label="siberian husky"
        />
    </content>
</entry>

Similarly, the same approach could be used to manage (say) the list of
authors available in the publishing system, the list of collections, a list
of publishing outputs, and so on.

I don't recall if this would be technically valid though. I do note that the
RNC for atomInlineOtherContent allows anyElement (ie. isn't restricted to
anyForeignElement (which explicitly excludes atom:* elements))

e.

---

From: "Peter Keane" <[email-masked]>
Date: Tue, 9 Dec 2008 04:18:09 +0000

>            scheme='http://www.loc.gov/catdir/cpso/lcco/'

This is very nice -- perhaps just what I was after.  Up to now I have
been (similarly) posting atom entries that represented the attribute
but w/o using content atomcat+xml -- which makes good sense to me.
I'll play with it a bit...

--peter