Subject: Re: Atom and RDF

From: Danny Ayers <[email-masked]>
Date: Tue, 12 Oct 2004 10:34:15 +0200

On Mon, 11 Oct 2004 20:39:11 -0700, Joshua Allen <[email-masked]> wrote:
> > happening (i.e. give a discription of what possible
> > representations could be obtained for a given resource, and
> > in what cases) RDF would be the natural source.
> 
> Yeah, I actually meant to refer to the "Accepts" header, which is one of
> many examples of useful metadata passed in HTTP headers.  HTTP has a
> metadata and extensibility story and doesn't use RDF -- and that is not
> worth losing sleep over.

Ok.

> > Taking RDF out of RSS just doesn't compare.
> 
> Danny was talking about Atom, and specifically about the use cases of
> using Atom as a transport for routing and publishing RDF.  Atom doesn't
> have any RDF to "take out".  And it's perfectly feasible to route and
> publish RDF using Atom or RSS 2.0 without having to modify them to be
> based on RDF.  We already have one syndication format based on RDF, and
> one based on XML.  What could we possibly gain by starting a holy war
> about whether the third should be switched from XML to RDF?  

Ok, could be wrong but I don't think Atom yet has a suitable means of
doing the equivalent of <enclosure>. So how would you feel about RSS
2.0 items as payload in Atom?

Maybe what you're suggesting (RDF as payload) is not such a bad idea,
but the main reason I'd like to see Atom inherit some of the
functionality RSS 1.0 has is for further decorating /descriptions/ of
the payload and the properties already associated with the payload.
You can already say the author of an entry is "..." but it would be
useful to add, they have a Personal Profile Document at "...". Or
perhaps a better example would be - the creator of the attached mp3
was "...".

(I would
> point out that a mapping between RDF and XML in the case of Atom is
> trivial, BTW)

Only if you limit Atom to the core terms. That's really the nub of the
issue - building Atom that way arbitrarily restricts the kind of
things it can say. Ok, as I think Graham said we might not want Atom
to be as promiscuous as RDF (I hope I remembered that correctly ;-).
But extensibility is in the charter.

It has been suggested that additional info could go into
foreign-namespaces elements. Unfortunately that suffers from the N^2
problem for interop, and doesn't in itself provide any systematic way
of associated more information with the entries in the feed. Mapping
to RDF would not be trivial.

As has been pointed out, each entry is given a URI, which means RDF
can talk about them. But then that raises the spectre of one (Atom)
feed for content, one (RSS/RDF) for metadata.Or perhaps following the
idea of RDF-as-payload we could have alternating content/metadata
(wierd, but there might be something in it...).

Cheers,
Danny. 

-- 

http://dannyayers.com

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 12 Oct 2004 07:16:29 -0700 (PDT)

> 2.0 items as payload in Atom?

An <enclosure> is a link to a resource with some
metadata about what is at the end of the URI
specified. That sounds like the <atom:link> element
and the recently discused <atom:content src="">. 
 
> to RDF would not be trivial.

What is this N^2 interop problem and can you explain
how it doesn't apply to using RDF? I've read Ken
MacLeod's postings on the topic but as an aggregator
author I felt his arguments were specious. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #23
I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks.

---

From: Robert Sayre <[email-masked]>
Date: Tue, 12 Oct 2004 10:29:11 -0400

Danny Ayers wrote:

> doing the equivalent of <enclosure>. 

We call it content @src. MarkN and I are working on incorporating the 
accepted PaceContentRedux3. That's your "blob" property, remember?

> (wierd, but there might be something in it...).

It should raise the spectre of independent resources. HTTP works better 
that way.

I'm not "against" RDF at all, and I think it has a good extensibility 
story. But we don't really need RDF/XML in core. The Atom project, like 
some versions of RSS, has done a little activity-based planning and 
found that people like to make lists.[0]

Adaptations of Greenspun's Tenth Rule really aren't appropriate here.

Atom does not fear the other. Can we stop the crossposting now?

Robert Sayre

[0] (search for "activity-based planning")
http://www.joelonsoftware.com/printerFriendly/uibook/chapters/fog0000000065.html

---

From: Danny Ayers <[email-masked]>
Date: Tue, 12 Oct 2004 17:48:44 +0200

> author I felt his arguments were specious.

I thought Ken put it rather well, but it's easy enough to describe in
terms of aggregators. An aggregator with RDF support can aggregate
arbitrary data (say RSS plus the author's personal information and
their work schedules) as long as it's expressed as RDF/XML. It can
store it. Ok, you could argue that all that could be done with XML
alone. But the big difference is that because the source data has been
expressed as RDF it has consistent semantics that can be used for
query or inference.

So I could run a query like "give me all the items friends of Joshua
posted on days when he was on vacation". You could build a similar
system based on XML or a RDBMS. But the N^2 problem kicks in when you
try to add a new vocabulary or terms - say "starsigns". Exactly the
same store and query mechanism can be used to ask "give me all the
items people with the same starsign as Joshua posted on days when he
was on vacation".

Every term/vocab you add, has to be fitted it in with the existing
infrastructure, i.e. the N systems you've already got. Whereas if your
original data is expressed in RDF, you only have to fit in with 1
system.

This doesn't work for XML alone as there isn't any consistent
interpretation above the syntax. RDF can do it because it maps to
certain bits of pretty well researched bits of predicate logic. It
really justs pushes the shared language up a level is all.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 12 Oct 2004 09:18:44 -0700 (PDT)

> expressed as RDF it has consistent semantics that

I'm glad you concede that it all can be done with XML
alone, since I do that already today in RSS Bandit and
would have called sheenanigans if you hadn't. 

XML nodes have a consistent structure that can be used
for query as well. Semantics is all in the eye of the
beholder so without concrete examples we'll be talking
past each other if we I try to pick at your argument
of "consistent semantics". So can you give me some
examples of things that are impossible using XML-based
syndication (i.e. RSS 2.0) but possible using
RDF-based syndication (i.e. RSS 1.0). If you could
include sample XML files as well as pseudo-code it
would help to show that your arguments aren't just RDF
advocacy bit are rooted in technical facts. 

> items people with the same starsign as Joshua posted

(a) Your fundamental assumption is that the benefit of
extensibility in syndication is issuing queries. As
someone who has an aggregator with thousands of users
and has fielded hundreds of bug reports and feature
requests from users this doesn't jibe with my
experience. When people want to add features to RSS or
wish it could do more, I've never seen the ability to
issue queries on the new data or even on the existing
data in RSS being high on people's priority lists. 

(b) I've seen lots of claims from the RDF crowd that I
can just sprinkle new stuff into RSS feeds and
applications will magically understand them. Can you
explain to me preferrably with pseudo code how if an
aggregator is based on RDF (e.g. NewsMonster) it could
be 'learn' to be a podcasting application via the
famed RDF extensibility model if podcasting didn't
exist before the version was shipped? 

(c) The so-called shared semantics RDF buys you is
only in the area of issuing queries. Of all the
extensions RSS Bandit supports, using RDF would not
have made much of a difference if I had shipped it
with only support for core RSS elements. How would
being based on RDF let RSS Bandit know how to deal
with extensions like admin:errorReportsTo,
wfw:commentRss, annotate:reference, wfw:comment, or
even xhtml:body if all it supported was the core
elements in RSS 1.0? 

Sounds like A.I. pixie dust to me. 

RSF buys you a limited degree of extensibility if all
you want to do is issue queries over data. Most of the
valuable extensions that have shown up in RSS have
little if anything to do with providing richer data
that can be queried against but actually signal new
tasks that aggregators need to be able to perform. 

=====

_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 12 Oct 2004 09:38:34 -0700 (PDT)

> found that people like to make lists.[0]

RDF is a good extensibility story for certain cases in
XML syndication 

(1) You have existing functionality and behavior that
applies to certain named items that you want to apply
uniformly to new items that you may not know about.
This is basically the atom:link debate. 

(2) You want to be able to add new data to a system
and not make significant changes to be able to query
against the new data. A scenario is if certain feeds
start adding FOAF data to comments and posts in feeds,
and yiu have a client with query capabilities it
shouldn't take code changes to be able to ask
questions like "Show me all comments and posts by Dare
Obasanjo". 

These are nice but I wouldn't call them the high order
bit for extensibility in syndication based on existing
experience with RSS. Usually extensions require new
behavior or new categories of named items instead of
being capable of being shoehorned into existing
concepts. Not all extensions to RSS are like this, for
example the extensions to RSS in the MSDN RSS feeds
(see http://msdn.microsoft.com/rss.xml for an example)
would fit well into an RDF-based extensibility model. 

=====

---

From: Danny Ayers <[email-masked]>
Date: Tue, 12 Oct 2004 19:03:39 +0200

> accepted PaceContentRedux3. That's your "blob" property, remember?

Oh yes, thankyou.

> It should raise the spectre of independent resources. HTTP works better

So why are we talking of multiple entries being delivered in a single feed?
 
> story. But we don't really need RDF/XML in core. 

I'm happy to go along with that. But I also think it would be a shame
if Atom provides extensibility (which is in the charter) without
allowing some form of disambiguation to assist interop. I wasn't sure
if the minimal structural interpretation of properties proposed by
Robert would be adequate for interop with RDF systems. But the
responses in this thread that have referred to that seem to suggest it
would be worthwhile.

The Atom project, like
> found that people like to make lists.[0]

Lists are good. They are necessary for shopping. Necessary, but not sufficient.
 
> Atom does not fear the other. Can we stop the crossposting now?

300MB mp3 response attached.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Danny Ayers <[email-masked]>
Date: Wed, 13 Oct 2004 12:13:32 +0200

On Tue, 12 Oct 2004 09:18:44 -0700 (PDT), Dare Obasanjo <[email-masked]> wrote:

> of "consistent semantics". 

I'm referring to semantics in the IT sense, broadly "The meaning
associated with a set of symbols in a given language, which is
determined by the syntactic structure of the symbols, as well as
knowledge captured in an interpretative model." [1] More specifically,
the formal logical semantics defined in the RDF and OWL specifications
[2], [3]. There are concrete examples in the specs.

> Sounds like A.I. pixie dust to me.

Well, ok, and I don't expect your opinion to be changed by mere
evidence and logical proof.  I'm afraid I haven't time right now to
find suitable links, coincidentally I've got some interesting
aggregator development work to do.
 
> tasks that aggregators need to be able to perform.

Hardly any of the extensions for general syndication (listed
previously by Ian) or those used in science publishing (listed
previously by Tony) signal new tasks. But even where new tasks are
involved, models like that of RDF can help to describe them
methodically and to interpret them consistently.

I don't deny there's a lot of interesting and useful stuff that can be
done with XML and desktop-style programming models. But it seems to me
that things get considerably more interesting and useful when you add
a Web-friendly data model like RDF's.

Cheers,
Danny.

[1] http://www.uhnres.utoronto.ca/ehealth/html/glossary/eh_glossary.shtml
[2] http://www.w3.org/TR/rdf-mt/
[3] http://www.w3.org/TR/owl-semantics/

-- 

http://dannyayers.com