Subject: Re: FYI: hAtom

From: Henry Story <[email-masked]>
Date: Fri, 28 Oct 2005 19:14:40 +0200

An example of how atom-owl may help us think about how extensions can
work best in the syntax
--------------------------------------------------------------------

On 28 Oct 2005, at 16:33, Scott Anderson wrote:

> Hi Henry,
>
>
>
>> I have not been following this microsoft proposal. Any pointers?
>> Looking around I found this:
>> http://msdn.microsoft.com/windowsvista/building/rss/ 
>> simplefeedextensions/
>>
>> But I am not aware of your use case.
>>
>>
>>
>
> You found the right thing.
>

I also found this along the way:
http://patricklogan.blogspot.com/2005/08/lists-really-can-we-expect- 
better.html
but this is a battle or argument I cannot claim to have any knowledge  
of.

> I believe that MS is thinking outside the
> context of blogs and other syndicated content to repurpose a web feed
> as an ordered list of entries where each entry is a wrapper for some
> microcontent.
>

I have a problem with this with respect to Atom. In Atom entries are not
ordered as opposed to RSS1.0.

So in N3

[ a :Feed, :Version;
   :entry _:a1;
   :entry _:a2;
   :entry _:a3;
] .

assuming _:a1, _:a2, and _:a3 are different there is no order defined.
There is just a :Feed and three relations to an anonymous :Entry object.

One could add an order by adding a list such as:

(_:a1, _:a2, _:a3) .

but that is not very interesting. You can take any objects in the  
world and
create lists out of them. Ie: the above was true without one needing  
to state
it.

An order is only interesting if one know something else about it: its  
type,
or its relation to something else. So for example if you were  
interested in a
preference ordering I had you could write

[ a foaf:Person;
   foaf:mbox <[email-masked]>;
   xxx:preferenceOrder (_:a1, _:a2, _:a3);
] .

And that would be saying something that could be of interest.

In short if you want an order to something you have to specify the
type of order you are interested in. Atom does not specify this
because that would impose an order and then they would have
to decide what order was especially important. I think wisely it
was decided that none was.

> A client could subscribe to a list and be able to
> respond when a new entry was added/removed or when the order of the
> entries changed.
>

It is an interesting question as to how in atom-owl (and in Atom)
one should present feeds where the ordering is important.

One way would be simple to make the ordering into an entry

[ a :Feed, :Version;
   :entry _:a1;
   :entry _:a2;
   :entry _:a3;
   :entry [ a :Entry, :Version;
            :updated "1 Nov 2005....";
            :id <tag:example.com,2005/order>
            :content [ xxx:Preferences;
                       xxx:order (_:a1, _:a2, _:a3);
                     ];
          ];
] .

Something like this. I have yet to think this through carefully as
in atom-owl I have defined the range of the :content relation to be a
:Content object that is a subclass of  webarch:Representation.

The nice thing about this is that you could have entries indicating a  
change
in your preference ordering I suppose like this:

[ a :Feed, :Version;
   :entry _:a1;
   :entry _:a2;
   :entry _:a3;
   :entry [ a :Entry, :Version;
            :updated "1 Nov 2005....";
            :id <tag:example.com,2005/order>
            :content [ xxx:Preferences;
                       xxx:order (_:a1, _:a2, _:a3);
                     ];
          ];
   :entry [ a :Entry, :Version;
            :updated "3 Nov 2005....";
            :id <tag:example.com,2005/order>
            :content [ xxx:Preferences;
                       xxx:order (_:a2, _:a1, _:a3);
                     ];
          ];

] .

Here you would be notifying the reader of your change in preferences
by adding a new entry.

The nice thing is that this keeps nicely distinct the feed, which is
unordered, and the Preference which has an ordering, by interposing
an Entry that may have at different times different relations to  
different
orderings: in shorter english: the ordering may change.

The above is just a sketch by the way, of the top of my head. It
raises interesting issues in the ontology, that would be well worth
looking into carefully.

>
> My use case is that I want to be able to present a hierarchy of these
> list feeds in the context of an XHTML doument using the hAtom
> microformat. I was thinking that my servlet would only resolve these
> dynamic lists at the time that I generate the XHTML. The Atom feeds
> and any modeling of them would make use of URL references to loosely
> coupled feeds so as to not complicate things outside the context of
> the XHTML document. It may make sense to do some OWL modeling specific
> to this case for some reason but I have not gotten that far yet. It
> may also make sense to provide some useful summary content along with
> these feeds that include entry references to other feeds. I will cross
> that bridge when I see it.
>

Does the above modeling help a little? By the way you can get a quick  
introduction
to N3 by following the link here: http://bblfish.net/blog/page5.html#47

>
> However, I do need to represent the resolved hierarchy of feeds in the
> context of the XHTML document. The whole point of supporting a
> microformat in this way would be to be able to provide a reasonable
> means to parse/scrape the XHTML to be able to make sense of the
> hierarchy of hAtom representations that were generated from originally
> walking the root Atom document feed when the document got generated,
> to be able to extract nested feeds, and the other microformat types
> that might have been rendered within the context of feed entries.
>
> Except for those restrictions imposed by the microformat community and
> the hAtom spec in particular do you see potential issues with what I
> want to do here? Maybe there are some issues with XHTML ids or with
> hAtom not being able to clearly delineate itself that I am not seeing.
>
>
>
>> I am a little new to microformats myself.
>>
>>
>>
>
> Me too. RDF and OWL are even newer to me.
>
> My concerns with such a solution extend beyond whether it is
> technically doable into whether it meshes with the intent of these
> intersecting efforts (OWL, microformats, CSS, etc.). This idea fits
> very well with how I want to use Atom and microformats but it could
> introduce grief to others who want to play in my sandbox.
>
> Scott
>
> On 10/28/05, Henry Story <[email-masked]> wrote:
>
>
>>
>> On 28 Oct 2005, at 13:10, Danny Ayers wrote:
>>
>>
>>
>>> Hi Scott,
>>>
>>> Henry (cc'ed) - see below,
>>>
>>> On 10/28/05, Scott Anderson <[email-masked]> wrote:
>>>
>>>
>>>
>>>> Danny,
>>>>
>>>> I have been emailing David Janes asking him to preserve the  
>>>> viability
>>>> of recursively embedding an hAtom feed within the contents of  
>>>> another
>>>> feed's entry. I can make use of such a feed hierarchy to provide  
>>>> the
>>>> semantic contexts (URIs included) that I was looking for.  
>>>> Microsoft's
>>>> proposal for extending RSS/Atom feeds to model them as ordered  
>>>> lists
>>>> appears to fit very well with this modeling of XHTML documents (and
>>>> their presentation) as lists of lists.
>>>>
>>>>
>>>>
>>>
>>> True.
>>>
>>>
>>
>> I have not been following this microsoft proposal. Any pointers?
>> Looking around I found this:
>> http://msdn.microsoft.com/windowsvista/building/rss/
>> simplefeedextensions/
>>
>> But I am not aware of your use case.
>>
>>
>>
>>>> I think this implementation of feed=list=context=template  
>>>> hierarchies
>>>> is much cleaner and more functional than what OPML+XSL or XOXO  
>>>> could
>>>> effectively provide. I am convinced that the humans I have worked
>>>> with
>>>> would have a hard time consuming or producing XOXO markup.
>>>>
>>>>
>>>>
>>>
>>> Heh, I know what you mean.
>>>
>>>
>>>
>>>
>>>> I have only had time to do a brief overview of what you guys are
>>>> doing
>>>> with Atom/Owl work. My hope is that I can apply it and some simple
>>>> OWL
>>>> models to get me some syndicated portlets that spit out  
>>>> microformats
>>>> within hierarchies of hAtom semantic contexts.
>>>>
>>>> Do you see any pitfalls that I may have overlooked?
>>>>
>>>>
>>>>
>>>
>>> It sounds reasonable, but there may well be pitfalls ;-) Henry has
>>> looked pretty hard at the feed-hierarchies idea, if I remember
>>> correctly the main objections to this approach on the atom-syntax  
>>> list
>>> were that it would make the parsing a bit harder. But from the XHTML
>>> point of view, where as you say lists can be hard to parse anyhow,
>>> maybe it would make sense.
>>> I don't know, maybe the only way of finding out how feasible this
>>> would be, would be to try a bit of code...
>>>
>>> Henry - thoughts?
>>>
>>>
>>
>> I am a little new to microformats myself.
>>
>> One way to get clear on your problem would be to try to use the
>> latest AtomOwl [1] ontology and write out an example of what you want
>> to  do in n3. There are already 2 examples there. The Atom Syntax has
>> many
>> restrictions that are not shared by the ontology, as the syntax is
>> designed to be easily parsed with xslt type tools, whereas the  
>> ontology
>> is just trying to describe what we are speaking about. Once we work
>> out what we are speaking about, it is then possible to decide what
>> the best presentation of that is. I also find that by writing things
>> out in N3 one gets a lot clearer about what the problem is.
>>
>> Henry
>>
>>
>> [1] http://bblfish.net/work/atom-owl/2005-10-23/
>>
>>
>>
>>
>>> Cheers,
>>> Danny.
>>>
>>> --
>>>
>>> http://dannyayers.com
>>>
>>>
>>>
>>
>>
>>
>
>