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 PROTECTED]>;
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 PROTECTED]> 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 PROTECTED]> 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
