Subject: solving the extensibility problem

From: Henry Story <[email-masked]>
Date: Tue, 9 Nov 2004 16:03:15 +0100

If the Atom working group wants to move along quickly the extensibility 
problem has to be solved. A good extensibility model for atom means 
that a lot of issues need not be resolved immediately. Those issues 
that don't get a wide consensus don't need to be dealt with now. Only 
the best understood elements need go into the spec. Further additions 
can be left to the extension mechanism, and be integrated in later 
revisions when they are better understood. A good extension mechanism 
will mean a spec out of the door much sooner than otherwise.

And the best extension mechanism is RDF.

Now some are going to scream to high heaven hearing this. "How do you 
think ", they will say jumping up and down, " how on earth do you think 
you are going to get consensus on this !? By the time we have finished 
the debate about RDF, the end of the universe will be nigh, and the 
heavens will be falling upon us!"

So here I propose two ways to do this that should be relatively easy, 
and should satisfy those that don't want to touch RDF with a 
barge-pole, yet make them really happy because they will have a great 
spec to work with real soon.

A COMPARISON
============

The idea is to try to work from both ends: try to get an rdf format 
that resembles as closely as possible the current Atom spec, and 
perhaps make a few adjustments in the Atom spec if needed.

Essentially we would like the following to be RDF:

   <?xml version="1.0" encoding="utf-8"?>
    <feed version="draft-ietf-atompub-format-03: do not deploy"
     xmlns="http://purl.org/atom/ns#draft-ietf-atompub-format-03">
      <head>
        <title>Example Feed</title>
        <link href="http://example.org/"/>
        <updated>2003-12-13T18:30:02Z</updated>
        <author>
          <name>John Doe</name>
        </author>
      </head>
      <entry>
        <title>Atom-Powered Robots Run Amok</title>
        <link href="http://example.org/2003/12/13/atom03"/>
        <id>vemmi://example.org/2003/32397</id>
        <updated>2003-12-13T18:30:02Z</updated>
      </entry>
    </feed>

So this is the closest I have come to the above [1]

<?xml version="1.0" encoding="utf-8"?>
<Feed xmlns="http://bblfish.net/work/atom-owl/2004-11-09/Atom.owl#"
	  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
	<head rdf:parseType="Resource">
			<title>Example Feed</title>
			<link rdf:resource="http://example.org/"/>
			<updated rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime"
				>2003-12-13T18:30:02Z</updated>
			<author rdf:parseType="Resource">
					<name>John Doe</name>
          	</author>
	</head>
     <entry rdf:parseType="Resource">
			<title>Atom-Powered Robots Run Amok</title>
			<link rdf:resource="http://example.org/2003/12/13/atom03"/>
			<id rdf:resource="vemmi://example.org/2003/32397"/>
			<updated rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime"
				>2003-12-13T18:30:02Z</updated>
	</entry>
</Feed>

So what differences does this example reveal? (more elaborate examples 
will of course reveal more)
	- there is a rdf:parseType="Resource" on the head and the entry element
     - there is a rdf:datatype on the date constructs
	- the link has a rdf:resource instead of the src
	- "Feed" is in captials because it is a node, the rest are lowercase 
because they
		are relations

Otherwise we have something very similar in the structure.

TWO SOLUTIONS
=============

So we could do one of two things:

	A. tweak the current Atom standard just enough so that it is not RDF 
but would
without any problems be RDF if the rdf:parseType, rdf:datatype, ... 
attributes get added. With a formal model backing it (where the 
predicates would be defined using the correct namespace, placed at the 
correct http location), this would allow people who want to extend Atom 
to add those missing attributes, and thereby turn Atom into RDF, giving 
them all the extensibility they desire. Simple xml parsers will have to 
be told to ignore any attributes or constructs that are not in the 
spec. The people extending Atom in this way will only be able to say it 
is atom, if an Atom parser that ignores all the RDF magic can parse the 
feed correctly.

	B. Bite the bullet and add the rdf magic in the spec. This would mean 
that any Atom Feed would be parsable by an RDF parser, as well as a 
simple XML one.

TODO
====

   Either of these solutions will require a little understanding and 
ability to compromise on both sides of the debate. There is an Atom-OWL 
list on google [3] that may be a good place to discuss this in more 
details. Because clearly there is still a lot of work to be done 
getting tidying up the details of the OWL spec to get it closer to what 
the Atom group is working on.

Perhaps we could first start off by having everybody out there who 
thinks this is a good idea, give some +1, so that we know there is some 
momentum behind this.

All the best,

	Henry Story
	http://bblfish.net/blog/

[1] This is after reading the very good article
     http://www.w3.org/TR/rdf-syntax-grammar/
     Someone with more experience may do a lot better.

[2] I use the new Atom.owl spec I have made available at
     http://bblfish.net/work/atom-owl/2004-11-09/Atom.owl
     http://bblfish.net/work/atom-owl/2004-11-09/Atom.html
    (ignore the W3C Recommendation on the right hand side :-)

[3] http://groups-beta.google.com/group/atom-owl

---

From: James Robertson <[email-masked]>
Date: Tue, 09 Nov 2004 10:17:41 -0500

At 10:03 AM 11/9/2004, you wrote:

>problem has to be solved. A good extensibility model for atom means that a 
>lot of issues need not be resolved immediately. Those issues that don't 
>get a wide consensus don't need to be dealt with now. Only the best 
>understood elements need go into the spec. Further additions can be left 
>to the extension mechanism, and be integrated in later revisions when they 
>are better understood. A good extension mechanism will mean a spec out of 
>the door much sooner than otherwise.
>

Without commenting on the merits of RDF, I think that RSS 2.0 demonstrates 
the real-world fact that using namespaced modules works.

>you are going to get consensus on this !? By the time we have finished the 
>debate about RDF, the end of the universe will be nigh, and the heavens 
>will be falling upon us!"
>
>So here I propose two ways to do this that should be relatively easy, and 
>should satisfy those that don't want to touch RDF with a barge-pole, yet 
>make them really happy because they will have a great spec to work with 
>real soon.
>
>A COMPARISON
>============
>
>The idea is to try to work from both ends: try to get an rdf format that 
>resembles as closely as possible the current Atom spec, and perhaps make a 
>few adjustments in the Atom spec if needed.
>
>                         <updated 
> rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime"
>                         <link 
> rdf:resource="http://example.org/2003/12/13/atom03"/>
>                         <updated 
> rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime"
>         - "Feed" is in captials because it is a node, the rest are 
> lowercase because they
>                 are relations
>
>         A. tweak the current Atom standard just enough so that it is not 
> RDF but would
>attributes get added. With a formal model backing it (where the predicates 
>would be defined using the correct namespace, placed at the correct http 
>location), this would allow people who want to extend Atom to add those 
>missing attributes, and thereby turn Atom into RDF, giving them all the 
>extensibility they desire. Simple xml parsers will have to be told to 
>ignore any attributes or constructs that are not in the spec. The people 
>extending Atom in this way will only be able to say it is atom, if an Atom 
>parser that ignores all the RDF magic can parse the feed correctly.
>
>         B. Bite the bullet and add the rdf magic in the spec. This would 
> mean that any Atom Feed would be parsable by an RDF parser, as well as a 
> simple XML one.
>
>
>TODO
>====
>
> details. Because clearly there is still a lot of work to be done getting 
> tidying up the details of the OWL spec to get it closer to what the Atom 
> group is working on.
>
>Perhaps we could first start off by having everybody out there who thinks 
>this is a good idea, give some +1, so that we know there is some momentum 
>behind this.
>
>All the best,
>
>         Henry Story
>         http://bblfish.net/blog/
>
>

<Talk Small and Carry a Big Class Library>
James Robertson, Product Manager, Cincom Smalltalk
http://www.cincomsmalltalk.com/blog/blogView
Cincom Smalltalk User Conference!
http://www.cincomsmalltalk.com/blog/blogView?entry=3275631428

---

From: Henry Story <[email-masked]>
Date: Tue, 9 Nov 2004 16:23:43 +0100

On 9 Nov 2004, at 16:17, James Robertson wrote:

>> If the Atom working group wants to move along quickly the 
>> extensibility problem has to be solved. A good extensibility model 
>> for atom means that a lot of issues need not be resolved immediately. 
>> Those issues that don't get a wide consensus don't need to be dealt 
>> with now. Only the best understood elements need go into the spec. 
>> Further additions can be left to the extension mechanism, and be 
>> integrated in later revisions when they are better understood. A good 
>> extension mechanism will mean a spec out of the door much sooner than 
>> otherwise.
>>
> Without commenting on the merits of RDF, I think that RSS 2.0 
> demonstrates the real-world fact that using namespaced modules works.

There are many on this list that don't believe this. I think a very 
large part of the W3C does not believe this, and the guy who invented 
the Web, Tim Berner's Lee, who thought about it in the early 80ies, 
when most people had trouble understanding what computers were, let 
alone the net, does not believe this.

So please people don't respond to this.

I want to know who thinks this is a good idea first.

Thanks,

	Henry Story
	http://bblfish.net/blog/

---

From: Antone Roundy <[email-masked]>
Date: Tue, 9 Nov 2004 08:28:45 -0700

On Tuesday, November 9, 2004, at 08:03  AM, Henry Story wrote:
> correct http location), this would allow people who want to extend 
> Atom to add those missing attributes, and thereby turn Atom into RDF, 
> giving them all the extensibility they desire. Simple xml parsers will 
> have to be told to ignore any attributes or constructs that are not in 
> the spec. The people extending Atom in this way will only be able to 
> say it is atom, if an Atom parser that ignores all the RDF magic can 
> parse the feed correctly.
>
Based on your example, I don't think I'd have a problem with this, but 
I'd have to see more details fleshed out.  For those who don't want to 
go whole-hog, the differences in your example would be:

* change "feed" to "Feed"
* add xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" in <feed>
* change @href to @rdf:resource in <link>

None of those changes looks painful to me.  The questions I have are:

1) whether more drastic changes would be needed to other elements or 
attributes that aren't found in the example.

2) how this might affect extensions--what constraints would need to be 
placed on extensions to ensure that they can play nicely in both RDF 
and non-RDF Atom feeds?

Antone

---

From: James Robertson <[email-masked]>
Date: Tue, 09 Nov 2004 10:29:19 -0500

<snip>

>There are many on this list that don't believe this. I think a very large 
>part of the W3C does not believe this, and the guy who invented the Web, 
>Tim Berner's Lee, who thought about it in the early 80ies, when most 
>people had trouble understanding what computers were, let alone the net, 
>does not believe this.

They can disbelieve it all they want.  The fact is, there are a large 
number of namespaced modules for RSS 2.0, and most aggregators support an 
awful lot of them.  In BottomFeeder, it takes me a few minutes to support 
any new module that seems to be of interest.

So what people 'believe' is irrelevant.  Facts are stubborn things.

Now, whether that's the best mechanism for extensibility?  That's a good 
question.  I'd have to say that the simple "It's worked so far" argument 
carries a lot of weight.

>So please people don't respond to this.

too late :)

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 9 Nov 2004 07:37:47 -0800 (PST)

> And the best extension mechanism is RDF.

Can you explain to me in one paragraph or so how RSS
1.0 (based on RDF) is more extensible than (RSS 2.0)
preferrably using examples from actual practice? 

> A COMPARISON

Re-opening the "Should Atom use RDF or not debate"
doesn't seem like a good way to lead to closing down
the discussion on Atom and extensibility. Instead it
seems like another permathread waiting brew that will
eventually lead to a lot of spilled text and little
change to the draft spec. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #222
I reserve the right to execute any henchmen who appear to be a little too intelligent, powerful, or devious. However if I do so, I will not at some subsequent point shout "Why am I surrounded by these incompetent fools?!"

__________________________________ 
Do you Yahoo!? 
Check out the new Yahoo! Front Page. 
www.yahoo.com

---

From: Robert Sayre <[email-masked]>
Date: Tue, 09 Nov 2004 10:48:34 -0500

James Robertson wrote:

> number of namespaced modules for RSS 2.0, and most aggregators support 
> an awful lot of them.  In BottomFeeder, it takes me a few minutes to 
> support any new module that seems to be of interest.
> 

That's a good point, though calling them "modules" is kind of overblown. 
A more interesting question might be which common extensions would be 
invalid RDF in RSS 1.0. Almost all extensions seem to consist of a 
single element with a text value. RSS 1.0 seems quite popular, so I 
wouldn't say the victory is decisive for either approach.

Robert Sayre

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 9 Nov 2004 07:53:59 -0800 (PST)

> alone the net, does not believe this.

Argument from authority and conjecture don't hold much
weight in technical discussions. Guessing that Tim
Berners-Lee and the W3C would be on your side in a
debate isn't any way of convincing people of the
technical merits of your argument. 

>  I want to know who thinks this is a good idea
first.

I don't. 

=====

---

From: James Robertson <[email-masked]>
Date: Tue, 09 Nov 2004 10:57:06 -0500

<snip>

>That's a good point, though calling them "modules" is kind of overblown. A 
>more interesting question might be which common extensions would be 
>invalid RDF in RSS 1.0. Almost all extensions seem to consist of a single 
>element with a text value. RSS 1.0 seems quite popular, so I wouldn't say 
>the victory is decisive for either approach.

Well, that raises a question - I don't know the answer to it though.  Do 
most aggregators that deal with RSS 1.0 really do RDF, or do they just 
treat it as a variant syndication format?  I know that I didn't bother 
creating a distinct ability to deal with RDF in BottomFeeder - I'd be 
curious as to how others dealt with this one.

---

From: Antone Roundy <[email-masked]>
Date: Tue, 9 Nov 2004 09:01:47 -0700

On Tuesday, November 9, 2004, at 08:29  AM, James Robertson wrote:
>>> demonstrates the real-world fact that using namespaced modules >>> works.
>>
Discussions of RDF in mixed company (RDF-using/non-RDF-using) remind me 
of the book/movie "Flatland".  I myself am a Flatlander 
(non-RDF-using), but I have a sense that there's another world out 
there that I don't quite understand.

Namespaced modules for RSS 2.0 do just fine for those of us who are 
writing tools to work with newsfeeds, but something tells me that once 
you start trying to work with many different formats using the same 
tools, RDF might make your job a lot easier.  The RDF-users may wish to 
confirm or deny that the newsfeed-only vs. many-formats axis is where 
it really starts to matter.

As a Flatlander, I personally don't want Atom to be loaded up with RDF 
stuff, because it just doesn't matter to me. But if it can be done with 
<em>minimal</em> changes from what we have now, I see no reason not to 
do it.

Antone

---

From: Henry Story <[email-masked]>
Date: Tue, 9 Nov 2004 17:09:04 +0100

> technical merits of your argument.

Arguments from authority do have some weight when you look at the 
landscape in which you are moving. I trust Tim Berner's Lee has not 
invented all of RDF and would not be pushing it the way he does if a 
simple solution could have done just as well. If I play chess with 
Kasparov, and he tells me that I would be better off not moving my pawn 
in a certain place, then I will listen, even though I may not 
understand, even though it may take me a few years of study (if not 
more) to understand.

So I don't want to get in the permathread of whether RSS2.0 extensions 
are ok. I believe everyone understands that RDF gives us all we need. 
There may be other weaker mechanisms, but if we try to find these we 
may never get this spec out of the door. So I say lets go with the 
best.

Secondly I ask you to look at my proposal, and see if it works from 
within its own perspective. Forget about RSS2.0. I am proposing that we 
tweak what we have just enough, so that it could be turned into RDF.

       I AM NOT SAYING THAT WE SHOULD MAKE THE CURRENT SPEC BE RDF! (see 
solution A)

Just that we should allow write it in such a way that people who want 
to extend it can use that very well documented extension mechanism.

In fact if you look carefully:

	 MY SOLUTION DOES NOT EXCLUDE AN RSS2.0 TYPE EXTENSION MECHANISM 
EITHER!

Henry Story

---

From: Henry Story <[email-masked]>
Date: Tue, 9 Nov 2004 17:24:10 +0100

Thanks Antone. These question of yours are exactly the type of 
questions I am looking forward to getting answered. This is an 
empirical investigation as I see it. I don't know the answer to these 
problems, and look forward to fleshing them out.

I really look forward to some people with good RDF and XML experience 
helping us work out the feasibility of this task.

Henry Story

On 9 Nov 2004, at 16:28, Antone Roundy wrote:

>> predicates would be defined using the correct namespace, placed at 
>> the correct http location), this would allow people who want to 
>> extend Atom to add those missing attributes, and thereby turn Atom 
>> into RDF, giving them all the extensibility they desire. Simple xml 
>> parsers will have to be told to ignore any attributes or constructs 
>> that are not in the spec. The people extending Atom in this way will 
>> only be able to say it is atom, if an Atom parser that ignores all 
>> the RDF magic can parse the feed correctly.
>>

---

From: Danny Ayers <[email-masked]>
Date: Tue, 9 Nov 2004 17:24:58 +0100

Henry, please correct me if I'm wrong on your proposal A :

1. Atom core would remain essentially as-is*

2. Anyone wishing to use an RSS 2.0-style extension mechanism, can do
(i.e. anything can go anywhere, leave it to vendors to figure
individual interpretations)

3. Anyone wishing to use RDF-based extensions can do, by adding the
attributes needed to make the syntax interpretable as RDF/XML, then
re-using standard vocabularies in the same manner as RSS 1.0

* there may be minor readjustments needed to align the formats, but I
can't see any yet (changing the case of Feed etc isn't essential - RSS
1.0 has lower-case classnames)

This seems a low-friction route through the extensibility issue. I
could live with it (to the extent that I'd be a lot more comfortable
about Declaring Victory).

James said "RSS 2.0 demonstrates the real-world fact that using
namespaced modules works". I don't believe it does. There are very few
extensions in common use. Last time I looked the usage was negligible.
I would guess that it's grown now, but nothing like to the extent of
extensions in RSS 1.0.  If you can show me a few RSS 2.0 feeds
carrying more than half-a-dozen extensions, I'll accept the
demonstration.

Dare, if I understand Henry correctly, I don't think this is really
opening the debate as before as the effect on Atom Core is virtually
nil. But you wanted a practical example - how about the query "Give me
all the mp3 format audio files published by any of the people I know
that work for Microsoft in the last week, that are less than 10
minutes long with a review rating better than 8/10, unless the artist
name is "Happy Mondays" in which case just give them to me". That can
be done  today using off-the-shelf tools with virtually no coding (in
particular no database structural building, the RDF provides the
structure) and using mostly common extensions - MusicBrainz, FOAF, REV
etc.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Robert Sayre <[email-masked]>
Date: Tue, 09 Nov 2004 11:28:29 -0500

James Robertson wrote:
>>> Now, whether that's the best mechanism for extensibility?  That's a 
>>> good question.  I'd have to say that the simple "It's worked so far" 
>>> argument carries a lot of weight.
>>
>>
>> That's a good point, though calling them "modules" is kind of 
>> overblown. A more interesting question might be which common 
>> extensions would be invalid RDF in RSS 1.0. Almost all extensions seem 
>> to consist of a single element with a text value. RSS 1.0 seems quite 
>> popular, so I wouldn't say the victory is decisive for either approach.
> 
> 

I think I know the answer to that question. Almost none of them treat 
RSS 1.0 as RDF. That doesn't mean that producers don't find it 
convenient, or that the syntactic restrictions of RSS 1.0 don't help 
interop.

All variants of RSS are essentially pseudo-RDF, and we've had a hard 
time saying anything enlightening about extensibility. I think taking 
another look at RDF might be worth it (look at the category thread), as 
long as we can keep the syntax under control.

There are certainly downsides to RDF when it comes to validation, so we 
would definitely benefit from an approach similar to the DOAP 
project[0], where the format must comply with an RNG schema (or XSD, 
Schematron, and whatever else Randy feels like writing :).

I think Henry's suggestion A is worth looking at, though the link 
element might have some problems. RSS2-style extensions would still be 
as straightforward as ever.

Robert Sayre

[0] http://www-106.ibm.com/developerworks/xml/library/x-osproj3/

---

From: Henry Story <[email-masked]>
Date: Tue, 9 Nov 2004 17:47:35 +0100

> 1. Atom core would remain essentially as-is*

That would be the name of the game. What are the minimum modifications 
one would need
to make to Atom core for this to work? If one could do it without 
making any modifications at all that would be the best.

The example I gave this morning is something I worked on in the last 
24h. So I am sure one can do a lot better.

> individual interpretations)

Yes. Why not. Then we will have a multiply extensible extensibility 
mechanism, and we will have brought the two RSS camps together in a 
loving embrace. :-)

> re-using standard vocabularies in the same manner as RSS 1.0

Yes.

> about Declaring Victory).

These, the questions brought up by Antone Roundy, and others we will 
discover will need to be addressed. With some good minds on the issues, 
this hopefully could be done relatively quickly, so that we can get the 
thing out of the door.

	[snip, stuff that answers other questions]

---

From: Danny Ayers <[email-masked]>
Date: Tue, 9 Nov 2004 17:48:00 +0100

> curious as to how others dealt with this one.

It's a very good question. Most desktop aggregators that I've
encountered don't have any general handling of RDF/XML and don't use
the generic model (three or four maybe do?). The proportion increases
somewhat for server-side aggregation, in fact I've seen tools that
depend on the use of other RDF vocabularies (e.g. Chumpalogica uses
FOAF for blogrolls).

But then every single standard RDF tool can read and use RSS 1.0
directly, because it's RDF/XML, the RDF interchange format. That is a
very long list. However you probably wouldn't call many of these
aggregators in the usual sense (e.g.
http://www.semanticwebsearch.com/).

I remain convinced that we'll see an increase in the use of RDF inside
and alongside content management systems and aggregators. It can be
pretty straightforward to add extension and smart-metadata support in
the same way you might add free text search.

The RSS 2.0 approach does more or less make simple things simple, but
it makes complex things unnecessarily difficult, so I think the future
holds diminishing returns there.

Meantime the tools for working with RDF are getting more common and
easier to use. Below I've pasted the core of an RDF-based aggregator
in C# using Carp.

Cheers,
Danny.

KnowledgeBase bloggers = new KnowledgeBase(parserFactory);
bloggers.include(new StreamReader("./bloggers.rdf"), "");
Foaf.Agent pattern = new Foaf.Agent();

foreach (Foaf.Agent agent in pattern.findAllMatching( bloggers ) ) {
  Console.WriteLine( agent[Foaf.name] );
  foreach (Foaf.Document doc in agent.weblog) {
    Console.WriteLine( "Weblog: " + doc );

    KnowledgeBase rss = new KnowledgeBase();
    rss.investigate( doc , new SeeAlsoPropertyInvestigator());

    Rss.Item itemPattern = new Rss.Item();
    foreach (Rss.Item item in itemPattern.findAllMatching( rss ) ) {
      Console.WriteLine( "  - " + item.title );
      Console.WriteLine( "    " + item.description );
    }
  }          
}

from:
http://www.semanticplanet.com/2004/10/announcingSemanticPlanetsRDFLibAndCarp

-- 

http://dannyayers.com

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 9 Nov 2004 09:05:57 -0800 (PST)

> carrying more than half-a-dozen extensions, I'll

There are as many RSS 2.0 modules as there are RSS 1.0
modules since every aggregator I am aware of respects
RSS 1.0 modules that appear in an RSS 2.0 feed. So any
argument against the adoption of modules in RSS 2.0 is
also one against the adoption of modules in RSS 1.0. 

Furthermore, given the fact that most aggregators
don't even use RDF parsers to process RSS 1.0 feeds
it's even hard to argue that RSS 1.0 modules show that
RDF-based extensibility works in the wild. 

This is getting into permathread territory and given
the fact I have to finish my 2 talks for XML 2004 next
week I won't be continuing this particular
conversation thread much further. 

> structure) and using mostly common extensions -

As I've mentioned in the past, complex querying isn't
an interesting scenario for most aggregator users.
This has been my experience with RSS Bandit which for
the most part has a fairly technical user base who
you'd think would enjoy such geeky features. 

=====

---

From: "Laurent Le Meur" <[email-masked]>
Date: Tue, 9 Nov 2004 19:08:13 +0100

ATFU, http://www.xml.com/pub/a/2002/10/30/rdf-friendly.html gives more information
about what is being RDF-friendly.

But the modifications could maybe be smaller -> for example making the globally
unique "id" an attribute of <entry> (it can be mapped to an rdf:about attribute with
a simple xslt), defining the Atom-core entry elements as simple RDF-like elements (no
mixed content), and allowing any #other# namespaced elements in <entry>.

But: RDF is about metadata after all. The content part of the entry has nothing to do
with RDF. How would you make the separation?

Laurent Le Meur
Agence France Presse

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la
> part de Henry Story
> Envoyé : mardi 9 novembre 2004 16:03
> À : Atom WG
> Cc : [email-masked]
> Objet : solving the extensibility problem
>
>
> Otherwise we have something very similar in the structure.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

		DISCLAIMER

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please contact the sender and delete the email from your system. If you are not the named addressee you should not disseminate, distribute or copy this email.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

---

From: Danny Ayers <[email-masked]>
Date: Tue, 9 Nov 2004 19:33:26 +0100

> about what is being RDF-friendly.

Thanks, good pointer.

> mixed content), and allowing any #other# namespaced elements in <entry>.

Hmm,  XSLT can take the <id> element content and put it into an
rdf:about attribute, but I think the aim here would be to avoid
needing XSLT if at all possible. It's not a typical use of a URI, but
if <id> was left as it is then it could be defined as an inverse
functional property when used with RDF.

> with RDF. How would you make the separation?

Data is data. The content is a representation of the resource, there's
no reason that shouldn't be part of a Resource Description Framework
model. I've not followed the content discussion fully recently, but
I'm sure there will be a suitable datatype available in RDF.

In passing I think it's worth noting that RDF/XML literals changed
quite a bit after the original RSS 1.0 spec came out, and the usual
approach to content there (as <content:encoded>) shares some of the
problems associated with character escaping in RSS 2.0.  If there ever
is a revision of RSS 1.0 then it might well deprecate
<content:encoded> in favour of using RDF/XML's XMLLiterals with true
XML content (e.g. XHTML). This could lead to an element
<content:unencoded>...

Cheers,
Danny.

[1] http://www.w3.org/TR/rdf-syntax-grammar/#section-Syntax-XML-literals

-- 

http://dannyayers.com

---

From: Robert Sayre <[email-masked]>
Date: Tue, 09 Nov 2004 13:34:18 -0500

> with RDF. How would you make the separation?

atom:content is looking like a restricted version of annotea:body[0] 
already.

Robert Sayre

[0] http://www.w3.org/2000/10/annotation-ns#annotates

---

From: Danny Ayers <[email-masked]>
Date: Wed, 10 Nov 2004 12:22:47 +0100

A little postscript - I just discovered this online demo of the Sparql
query language applied to RSS 2.0 (yes, 2.0) which might amuse:

http://tinyurl.com/5cl2z

see also:
http://esw.w3.org/topic/DawgShows

----

original URI was:
http://librdf.org/query?command=query&uri=http%3A%2F%2Fwww.scripting.com%2Frss.xml&language=sparql&query=PREFIX+rss%3A+%3Chttp%3A%2F%2Fpurl.org%2Frss%2F1.0%2F%3E%0D%0ASELECT+%3Fdescription%0D%0AWHERE+%28+%3Fitem+rdf%3Atype+rss%3Aitem+%29%0D%0A++++++%28+%3Fitem+rss%3Adescription+%3Fdescription+%29

-- 

http://dannyayers.com

---

From: Dave Beckett <[email-masked]>
Date: Wed, 10 Nov 2004 12:10:37 +0000

> http://librdf.org/query?command=query&uri=http%3A%2F%2Fwww.scripting.com%2Frss.xml&language=sparql&query=PREFIX+rss%3A+%3Chttp%3A%2F%2Fpurl.org%2Frss%2F1.0%2F%3E%0D%0ASELECT+%3Fdescription%0D%0AWHE…

Yeah I made that, barely a few hours ago.  Be gentle.

[that command=query thing should go, bad me.  It's just a data GET]

Dave

---

From: Henry Story <[email-masked]>
Date: Wed, 10 Nov 2004 18:37:51 +0100

Thanks everyone for the great feedback. Lots of good ideas. And it has 
also helped me formulate a smoother formulation of the task: this is to 
define an RSS2.0 type extension template to allow Atom to be 
transformed into RDF so that RDF extensions can be used with ease.

So this task is not huge, but it will take a little work. Web wide 
participation is welcome :-) We just need to cut up the task into each 
one of the objects defined in the OWL Ontology [1], and try to see if 
we can find the closest serialisation of it to the
current Atom format. This will probably help reveal flaws in the OWL 
ontology, the proposed serialization, and perhaps even in the Atom 
spec.

I will be contributing a little every day or so, as I get some time off 
from writing BlogEd.

Henry Story

http://bblfish.net/blog/

[1] I use the new Atom.owl spec I have made available at
     http://bblfish.net/work/atom-owl/2004-11-09/Atom.owl
     http://bblfish.net/work/atom-owl/2004-11-09/Atom.html
    (ignore the W3C Recommendation on the right hand side :-)

---

From: Henry Story <[email-masked]>
Date: Fri, 12 Nov 2004 16:12:32 +0100

hmmm, I just thought of a nice one:

Comparing the current Atom atom head element

      <head>

with my first attempt at a resembling RDF version

> 			<author rdf:parseType="Resource">

and comparing in particular
	<link href="http://example.org/"/>
and
> 	<link rdf:resource="http://example.org/"/>

what if we made atom:href a subproperty of rdf:resource?

then the current atom link syntax would be good rdf!

Henry Story