Some time back, there was a discussion about hierarchy among Atom
resources [1]. The approach you describe here will work for
relationships but not for hierarchies. A minor issue in this approach
is that you can't navigate back to the artist entry having seen a work
entry. I would also like to see what kind of discovery mechanisms you
are suggesting, although these are mostly only required for interop.
When dealing with hierarchies, I posit the following requirements:
1. Hierarchies follow a strict containment model. This means removal
of a node in the hierarchy should remove the descendants of that node.
2. Navigation is possible in both directions
3. When manipulating nodes in the hierarchy, URLs are used to provide
navigation context. As an example, if I were to create a work for
Vincent Van Gogh, the URL where I post must implicitly constrain me to
only that artist and no additional data should be required in the
'work' entry being created.
For interop, I posit additional requirements:
1. There should be a way to discover whether a collection understands
the notion of hierarchies.
2. Relations that are hierarchical in nature must be explicitly
identified as so.
What does everyone here think about their requirements and those noted
here?
Nikunj
[1] http://www.imc.org/atom-protocol/mail-archive/msg11259.html
On Dec 3, 2008, at 5:23 AM, Peter Keane wrote:
In an eternal quest to find a simple way to express
relationships/hierachies among atom resources (entries), I have come
up with the following. My criteria:
- simple to manage w/ the RDBMS backend
- straightforward to express w/ standard atom constructs
- relatively easy to manipulate w/ AtomPub
The basic idea is that a link and a category will share the same URI
for the [EMAIL PROTECTED] and [EMAIL PROTECTED] The parent has the link, the
children have the category. The [EMAIL PROTECTED] is the atom id of the
parent, and the [EMAIL PROTECTED] expresses a search over the category scheme,
filtered by the parent id.
For example, a set of entries in a Art & Art History Collection, one
concerning the artist, and two about individual works:
<!-- artist entry -->
<entry>
<id>tag:example.com/000123</id>
<title>Vincent Van Gogh</title>
<content>essay about Van Gogh...</content>
<link rel="http://example.com/link/artist_works";
href="http://example.com/link/artist_works?term=tag:example.com/000123
"
type="application/atom+xml"
title="Artist Works: Vincent Van Gogh"/>
</entry>
<!-- two work entries -->
<entry>
<id>tag:example.com/000124</id>
<title>Harvest in Provence</title>
<x:artist>Vincent Van Gogh</x:artist>
<content>essay about this painting...</content>
<category scheme="http://example.com/link/artist_works";
term="tag:example.com/000123"/>
</entry>
<entry>
<id>tag:example.com/000125</id>
<title>The Sower</title>
<x:artist>Vincent Van Gogh</x:artist>
<content>essay about this painting...</content>
<category scheme="http://example.com/link/artist_works";
term="tag:example.com/000123"/>
</entry>
I can now use AtomPub to add or remove by simply PUTting the entry
with/without proper category. (There'll be some service doc & category
doc choreography to make most of this discoverable).
I am less concerned about fully functional interop, more concerned
with an extensible method to do these sorts of operations w/ standard
atom tools.
Evil hack? Any other thoughts?
--peter keane
