Re: creating new categories w/ AtomPub

["Peter Keane" <pkeane@xxxxxxxxxxxxxxx>]

On Sat, Dec 13, 2008 at 12:25 AM, Erik Wilde <dret@xxxxxxxxxxxx> wrote:
> hello peter.
>
>> I can certainly see using any of those approaches, depending upon the
>> actual needs/use case.  For my own situation, I need to assert things
>> "about" a category, so I'd probably use #3 and that "categories
>> collection" would have categories of it's own that I would again
>> choose one of the above methods to manage.  So it's a recursive
>> pattern, but results, I think in a clean & predictable approach.
>
> if you do what you're proposing here, you are effectively creating a
> "category ontology" (the category categories) and both the categories and
> the category ontology would be accessible through atom(pub). that's pretty
> neat, bun on the other hand, if you really want to do advanced category
> management (beyond atom's simple "tagging" model), you probably want some
> disciplined management of the categories and the category ontology, so that
> you can enforce some constraints for managing that data. and you probably
> don't want to really have that recursively, but limit it to the two levels
> of category and category categories (the "ontology"), beyond that it gets
> pretty hard to come up with meaningful explanations of what all of that is
> supposed to represent.
>

Hi Erik-

Yes, it becomes something of an ontology.  I need to do much more
thinking/implementing before I see if there is much useful here, but
it is kind of intriguing.  The data points I am starting with are:

- a simple way to "relate" atom-based resources (entry-to-entries,
feed-to-feed, etc) That would allow a recursive structure, using a
category on a child that"implies" a link from the parent [1]

- a way to add arbitrary key-value pairs to a entry (using text in
atom:category) which allows something more that simple tagging, at
least at leaf nodes. [2]

With that, I think that a complete AtomPub service could have a RDBMS
behind it that had only these tables:

entry (id, updated, title,etc.)
content (id, entry_id, mime_type, text) -- allows versioning content
category (id, term, label, scheme_id)
scheme (id, uri, description)
entry2category (entry_id,category_id, text) -- text represents text in
atom:category

A minimal Atom/AtomPub ontology (i.e., set of category schemes) would
be enough to bootstrap the whole thing. And everything could be "built
out" using AtomPub.

It's still at the level of "wacky idea " at this point, but perhaps
I'll learn something as I follow it out a bit.

> this scenario has quite a bit of overlap with knowledge management and
> semantic web issues, topic maps also come to mind. i haven't really thought
> about that in detail, but it might be interesting to further explore
> overlaps between atom(pub) as a general mechanism for information handling
> on the web, and topic maps and the semantic web as some specific examples of
> how semantics can be represented, and how that data also could be exposed
> through atom(pub).
>

It's interesting -- I had also been wondering if the world of "linked"
data might be represented but Atom Feeds. Perhaps it's my fear of
unbridled RDF that leads me here... :).

regards-
Peter

[1] http://www.imc.org/atom-syntax/mail-archive/msg20770.html
[2] http://www.imc.org/atom-syntax/mail-archive/msg20780.html


> cheers,
>
> dret.
>