Subject: Relating Atom Resources w/ Category & Link

From: "Peter Keane" <[email-masked]>
Date: Wed, 3 Dec 2008 13:23:57 +0000

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 link@rel and category@scheme. The parent has the link, the
children have the category.  The category@term is the atom id of the
parent, and the link@href 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

---

From: Nikunj Mehta <[email-masked]>
Date: Wed, 3 Dec 2008 09:00:34 -0800

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

---

From: Nikunj Mehta <[email-masked]>
Date: Wed, 3 Dec 2008 09:08:48 -0800

Nikunj

[1] http://www.imc.org/atom-protocol/mail-archive/msg11259.html

---

From: "Peter Keane" <[email-masked]>
Date: Wed, 3 Dec 2008 12:52:48 -0600

Hi Nikunj-

On Wed, Dec 3, 2008 at 11:08 AM, Nikunj Mehta <[email-masked]> wrote:
> 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.

Perhaps I should not use the term hierarchy, but rather "one-to-many"
relationships.  These relationship are extrinsic to the resources
(entries), and may be formed or dissolved with no effect on the
resources themselves.

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

Yes, my plan is definitely optimized for navigating from the parent to
the child.  It would not be too difficult to generate an "up"  link
for the child entries, though.

 I might mention...the system itself has the idea of an entry "type"
-- expressed as atom:category@scheme="http://.....item/type".  (An
entry's "type" can be altered with an AtomPub-style "PUT". ) The
system allows for parent-child relationships between these types, a
relationshp expressed as the shared URI I mentioned in my example.  So
if I create an entry and declare it of type "work", I can retrieve a
feed of all of the possible parents of that entry.  In the case of my
example, I create a "work" entry, and when I go back to edit it in a
web browser, I can display a pull-down list of artists.  Selecting Van
Gogh assigns the category (as described in the example) to the work.
And following the link from the Van Gogh entry automatically now
includes that work.

For discovery, I would include in each entry a link@rel=service.
Depending on the "type" of the entry, that service document might
describe (w/ a categories document) all of the artists I could assign
to it (if it is a work entry) OR a collection that I can post to (if
it is an artist entry) with a required category with the correct
scheme/term.

> 1. Hierarchies follow a strict containment model. This means removal of a
> node in the hierarchy should remove the descendants of that node.

For many use cases, I am sure this is important, but it is explicitly
not a requirement for my use case(s) -- relationships are
superimposed, not intrinsic to the resources.  I think this jibes with
Atom semantics (or lack thereof!) -- there's no innate notion of
hierarchy.

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

Indeed, as described above, the service doc linked from the Van Gogh
entry would define an AtomPub collection that would only accept
entries w/ the proper atom:category pointing it back to the Artist.
In my use case, I will also need to be able to create entries before I
know to what artist they are connected (thus the larger collection
space -- defined by   the "Art & Art History Collection", accepts atom
"work" entries that do not assert a relationship w/ an Artist).  In
many cases, the resources in question will already exist before I
denote a relationship to a "parent".

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

I'll need to ponder these a bit....   Certainly my use case is (I
think) different enough from the use case underlying the I-D you
linked to in the previous post (which I liked quite a lot, in fact) to
warrant a different approach.

--peter

> What does everyone here think about their requirements and those noted here?
>
> Nikunj
>

---

From: Aristotle Pagaltzis <[email-masked]>
Date: Thu, 4 Dec 2008 15:44:39 +0100

Hi Peter,

> Evil hack? Any other thoughts?

hack yes, but not evil, I think. It has some elegance, actually.

I can’t think of any problems that would crop up with it in
practice, but I’m not at all sure that I’m not missing something
blindingly obvious, so I don’t want to commit to yay or nay. But
if you do go ahead with it, I’d be interested to hear about how
it turns out.

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

---

From: James M Snell <[email-masked]>
Date: Thu, 04 Dec 2008 09:12:46 -0800

At first glance, this would appear to be a rather good approach.

- James