Hi Nikunj- On Wed, Dec 3, 2008 at 11:08 AM, Nikunj Mehta <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]"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 [EMAIL PROTECTED] 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. > > 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. 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. > 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. 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". > > 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. > 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 > > [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 >> > >
