Re: PaceEntryMediatype

[Henry Story]

I can see a reason to distinguish more strongly between a feed and an  
entry. And this is with regards to creating new collections.


The best way I see to create a new collection would be to POST a   
  containing no entries to a collection end point.  
Though that is very similar to POSTing an  I think the  
distinction is worth preserving at that point.


I am not sure if this has any bearing on mime types though.

Henry

On 8 Dec 2006, at 21:40, Mark Baker wrote:



On 12/8/06, Asbjørn Ulsberg <[EMAIL PROTECTED]> wrote:


On Wed, 06 Dec 2006 20:42:40 +0100, Jan Algermissen
<[EMAIL PROTECTED]> wrote:

> But that is an issue of linking semantics, not link target media  
types.


Wrong. The link relation 'alternate' is perfectly valid for both  
Entry and
Feed documents, depending on what type of resource they are linked  
from.
An index page of a website can have an 'alternate' relation to an  
Atom

Feed, while an individual article page (or "entry" page) can have an
'alternate' relation to an Atom Entry.


As it can to a feed with one entry.


Both link relations are identical,
but the client has absolutely no clue before it GETs the URI  
whether what

sits on the other end is an Atom Feed or an Atom Entry.


Nor should it need to distinguish, just like it doesn't need to
distinguish between a feed with multiple entries, versus one with one
entry.

Mark.

Re: PaceEntryMediatype

[Henry Story]

Just to say that I strongly agree with Jan's points below. We should  
work to use the link relation type properly, and not get dazzled by  
the current misuse of the alternate relation.


I have been wondering if there would not be a case for different mime  
types if one wanted to place a number of representations at the same  
url.


One could for example have the following at the same place:

- an html version of a blog post
- an  representation of that blog post
- a  for the history of changes to that blog post

That would suggest having different media types because one could not  
place them at the same location if one only has application/atom 
+xml . That does not decide the issue as to whether it is a good idea  
to do so.


For the moment I find the application/atom+xml;type=entry application/ 
atom+xml;type=feed more appealing than the other new media types by  
the way.


On the other hand having different mime types for every document  
format is also crazy. If someone invents a doc to describe cats, and  
someone else a doc to describe mice, are they going to need a new  
mime type? And what about a doc to describe policemen, and a doc to  
describe people? We could end up quickly with an infinite number of  
mime types which clearly would not help interoperability.


Henry


On 6 Dec 2006, at 23:22, Jan Algermissen wrote:

On Dec 7, 2006, at 7:43 AM, A. Pagaltzis wrote:



It seems pointless for atom:link to have a type attribute at all
then. You should be able to decide anything you need to decide by
GETting the resource (and sometimes parsing it). Why did we add
such a useless feature to the spec?



I am pretty sure it wasn't added for being able to tell people:  
"Look, at the other end of this link is a feed".


Seriously: how many feed readers are out there that base the  
decision wheter something is subscribeable on the type attribute of  
a link rather then on the link type?


As an analogy: HTML browsers look for stylesheets where it says

   

and not

   

Eh?

Jan





On 6 Dec 2006, at 11:42, Jan Algermissen wrote:
On Wednesday, December 06, 2006, at 08:30PM, "Antone Roundy"  
<[EMAIL PROTECTED]> wrote:


On Dec 6, 2006, at 12:14 PM, Jan Algermissen wrote:


 I'd say: stick with the one media type that is currently there -
there is no problem, just misconception about what it means to
subscribe.


A few reasons why a user agent might want to be able to tell the
difference between a link to a feed and a link to an entry beforehand
is in order to:


But that is an issue of linking semantics, not link target media  
types. I'd expect the user agent to look for links with 'here is a  
feed' semantics instead of looking for (arbitrary) links to certain  
media types.


IMHO, there is something going wrong somewhere - and it ain't the  
media type.


I completely agree.



On 6 Dec 2006, at 14:26, Jan Algermissen wrote:
To make that decision, the agent has to look at the  
representation and

the it is insignificant overhead to see if the thing returnes 
or .



Not if the resource needn't be GET in the first place. If the  
whole operation can be decided upon the Content-Type returned in a  
HEAD request, or




Ok, HEAD would save the extra payload, butI still think the  
reason for subscribing is NOT how the representation at the other  
end looks, it is based on the link semantics.

Re: In San Francisco/Bay Area

[Henry Story]

Sorry for being so imprecise. I was assuming so too. I don't know why  
I did not make it clearer.
But if there were others who misread this and there are enough of  
them, we can also do it on Wednesday 13th.


Henry

On 6 Dec 2006, at 10:14, Terris Linenbach wrote:

It is unclear reading this thread whether it's for today which I  
assume

it is.

Terris

-Original Message-----
From: Henry Story [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 05, 2006 9:42 PM
To: John Panzer
Cc: Lisa Dusseault; Atom Protocol; Atom
Subject: Re: In San Francisco/Bay Area


I'll be there at 6:30pm then. I imagine people will not be wanting to
stay very late.

Henry

On 5 Dec 2006, at 21:26, John Panzer wrote:


Lisa ran in to me today and reminded me about the meet up
(thanks!).  I will try hard to make it; is there a definite time
set?  (6pm is slightly better for me, but 7pm is okay too.)

-John

Lisa Dusseault wrote:


Thanks for setting this up Henry, I can be there Dec 6.  7pm is
much  easier to make than 6pm if anybody's coming far, even just
from SF.

Lisa

On Dec 1, 2006, at 12:08 PM, Henry Story wrote:



Ok I suggest trying December 6th.
Onion or no Onion rings at Tied House.

What is dinner time in the bay? 6pm? 7pm?

Henry


On 28 Nov 2006, at 21:31, John Panzer wrote:

Any of those would be good for me.  Be careful of the deep
fried  onion rings at Tied House, though.


Henry Story wrote:

It has been suggested that a good meeting location might be
Tied   House in Mountain View [1]. It has a back room that's
like a  patio  but covered and heated for dinner on either

Wednesday 6th Dec
Friday 8th Dec
Monday 11th Dec
Wednesday 13th Dec

Any preferences?

Henry Story

[1] http://www.tiedhouse.com/


On 16 Nov 2006, at 18:23, Henry Story wrote:

Hi,

I am in the San Francisco/Bay Area region for the coming
month.   Would anyone in the area be up for a group meeting?

Henry








--


John Panzer
System Architect
http://abstractioneer.org

Re: In San Francisco/Bay Area

[Henry Story]

I'll be there at 6:30pm then. I imagine people will not be wanting to  
stay very late.


Henry

On 5 Dec 2006, at 21:26, John Panzer wrote:

Lisa ran in to me today and reminded me about the meet up  
(thanks!).  I will try hard to make it; is there a definite time  
set?  (6pm is slightly better for me, but 7pm is okay too.)


-John

Lisa Dusseault wrote:


Thanks for setting this up Henry, I can be there Dec 6.  7pm is  
much  easier to make than 6pm if anybody's coming far, even just  
from SF.


Lisa

On Dec 1, 2006, at 12:08 PM, Henry Story wrote:



Ok I suggest trying December 6th.
Onion or no Onion rings at Tied House.

What is dinner time in the bay? 6pm? 7pm?

Henry


On 28 Nov 2006, at 21:31, John Panzer wrote:

Any of those would be good for me.  Be careful of the deep  
fried  onion rings at Tied House, though.



Henry Story wrote:

It has been suggested that a good meeting location might be  
Tied   House in Mountain View [1]. It has a back room that's  
like a  patio  but covered and heated for dinner on either


Wednesday 6th Dec
Friday 8th Dec
Monday 11th Dec
Wednesday 13th Dec

Any preferences?

Henry Story

[1] http://www.tiedhouse.com/


On 16 Nov 2006, at 18:23, Henry Story wrote:

Hi,

I am in the San Francisco/Bay Area region for the coming  
month.   Would anyone in the area be up for a group meeting?


Henry








--


John Panzer
System Architect
http://abstractioneer.org

Re: In San Francisco/Bay Area

[Henry Story]

Ok I suggest trying December 6th.
Onion or no Onion rings at Tied House.

What is dinner time in the bay? 6pm? 7pm?

Henry


On 28 Nov 2006, at 21:31, John Panzer wrote:

Any of those would be good for me.  Be careful of the deep fried onion 
rings at Tied House, though.



Henry Story wrote:

It has been suggested that a good meeting location might be Tied  House in 
Mountain View [1]. It has a back room that's like a patio  but covered and 
heated for dinner on either


Wednesday 6th Dec
Friday 8th Dec
Monday 11th Dec
Wednesday 13th Dec

Any preferences?

Henry Story

[1] http://www.tiedhouse.com/


On 16 Nov 2006, at 18:23, Henry Story wrote:

Hi,

I am in the San Francisco/Bay Area region for the coming month.  Would 
anyone in the area be up for a group meeting?


Henry

Re: PaceEntryMediatype

[Henry Story]

There are all kinds of other things you don't know: like what's  
inside the document, if the server is up, what the title is, ... What  
interoperability problem is solved by having a new mime type? And  
would that not be solvable by




Not that I really care that much.

Henry

On 29 Nov 2006, at 10:22, James M Snell wrote:



One such problem occurs in atom:link and atom:content elements.
Specifically:

  
  

Given no other information I have no way of knowing whether these are
references to Feed or Entry documents.

- James

Mark Baker wrote:

-1

- there's nothing special about an entry document
- AFAICT (because they're not referenced from the pace), the problems
referred to have other causes.  I prefer we fix those instead.

Mark.

Re: In San Francisco/Bay Area

[Henry Story]

It has been suggested that a good meeting location might be Tied  
House in Mountain View [1]. It has a back room that's like a patio  
but covered and heated for dinner on either


Wednesday 6th Dec
Friday 8th Dec
Monday 11th Dec
Wednesday 13th Dec

Any preferences?

Henry Story

[1] http://www.tiedhouse.com/

On 16 Nov 2006, at 18:23, Henry Story wrote:


Hi,

I am in the San Francisco/Bay Area region for the coming month.  
Would anyone in the area be up for a group meeting?


Henry

Home page: http://bblfish.net/
Sun Blog: http://blogs.sun.com/bblfish/
Foaf name: http://bblfish.net/people/henry/card#me

Re: PaceResurrectAutodiscovery

[Henry Story]

On 24 Nov 2006, at 01:44, Henri Sivonen wrote:

On Nov 23, 2006, at 22:42, Henry Story wrote:

This is very nice, in that it opens up the possibility of placing  
good RDF descriptions of these links at the http://www.iana.org/ 
assignments/relation/,


How could new link relations be described in RDF to such a degree  
that the description would actually be useful for software  
processing but simple enough to actually be implemented? Is it  
realistic to have UAs whacking IANA server effectively performing a  
DDoS on it?


Just some interesting uses of this beyond your question:

- The RDF file would serve as a useful machine readable description  
of the relation, and so serve as documentation.
- This would simply make those terms re-useable in other rdf  
vocabularies, which could be very useful. Do you have an RDF file  
that needs the notion of an alternate link? Well just use elements  
from that vocabulary.


But to get to your point:

The description on the server would probably not be very advanced. It  
would probably be very simple, like the Dublin Core vocabulary  
( http://dublincore.org/ ). And so you are right this would probably  
not say much more than that :alternate is a relation. Perhaps one  
could even specify the Domain and the Range of the relation to be  
documents.


Not much that one could automate. The default relations would rarely  
change, so User Agents would never query the server directly, and so  
you would not have a DDoS on them.


On the other hand, clients wanting to define new relations (as URLs)  
could place the definitions of these relations on their server, and  
say some more interesting things such as


<http://my.eg.com/rel#entry> rdfs:subPropertyOf <http://iana.org/ 
assignments/relation/alternate> .


The user agent would now know that this new entry relation is also an  
alternate relation. Perhaps this could save having to place both  
relations inside of every document.



as well as making the link relation very extensible (people who  
want to try out new link relations, can just use their own,  
unambiguous url).


How are full URIs distinguished from strings that need to be  
appended to "http://www.iana.org/assignments/relation/"; to obtain  
the full URI? Are UAs supposed to look for a colon as with XForms  
input methods? Where is this specified?


This is specified in the atom syntax document.

[[

The value of "rel" MUST be a string that is non-empty and matches  
either the "isegment-nz-nc" or the "IRI" production in [RFC3987].  
Note that use of a relative reference other than a simple name is not  
allowed. If a name is given, implementations MUST consider the link  
relation type equivalent to the same name registered within the IANA  
Registry of Link Relations (Section 7), and thus to the IRI that  
would be obtained by appending the value of the rel attribute to the  
string "http://www.iana.org/assignments/relation/";. The value of  
"rel" describes the meaning of the link, but does not impose any  
behavioral requirements on Atom Processors.


]] http://www.atompub.org/rfc4287.html#rfc.section.4.2.7.2



In practice people seem to want to use one-word link relations even  
when they are coming up with their own.


Yes. My guess is that this is because

1. They probably don't think of the issue of name clashes
2. There is no shorthand way of saying something like iana:alternate
3. There is no behavior associated with the name

If the relation pointed to a document that could have some behavioral  
impact on the browser with the user could adjust by doing something  
at the url of the relation, then there would be an immediate  
understanding of the value of using URIs.


I would recommend you adopt that too. Perhaps you can even adopt  
the iana name space. If we could get them to put the appropriate  
rdf document at that location, people who created/coined new link  
relations could describe these relations as being superproperties  
or subroperties of relations the browser already knows, which  
would allow the browser to partially interpret those.


Well, RDF is not viewed that favorably by the WHATWG. Also, the  
barrier for entry for the IANA registration process is likely too  
high. (It certainly is for MIME types.) As for using the same  
namespace, the HTML5 definitions for the link types don't  
necessarily match the Atom definitions.


I believe I have a good explanation for why people may have good  
reasons to dislike RDF/XML.

see: http://blogs.sun.com/bblfish/entry/crystalizing_rdf

Recently, a WHATWG-managed registry for HTML5 rel values has been  
discussed informally. The idea was that conformance checkers could  
consult an online registry instead of only allowing a fixed list of  
values or allowing everything. RDF is an overkill for this. Even  
XMDP isn't the simplest thing that could possibly work. The  
simplest thing that

Re: PaceResurrectAutodiscovery

[Henry Story]

On 23 Nov 2006, at 14:28, Thomas Broyer wrote:




"The feed keyword indicates that the referenced document is a
syndication feed.


"Being a syndication feed" is expressed by the media type, there's no
need for a 'rel' value.

The only reason for such a 'rel' is to replace the "contents" value in
the example above:


in "blog-like" use-cases where an HTML page serves the same purpose as
a syndication feed, just in an 'alternate' format.


Exactly: you have just made one good point why one should not use  
mime types to identify the relation. After all there may be many  
different feed representations: html, rss 1.0, rss 2.0, atom,   
rdf, ... etc...


There are many other good reasons to not use the "alternate" relation  
everywhere. The spec [1] for feed makes the case for a useful  
distinction between a feed that can be used to track updates of the  
content one is looking at, and something that is just an alternate  
representation of the content one is looking at expressed in  
application/atom+xml format. This would be the case for the front of  
my blog page.



Henry

[1] http://whatwg.org/specs/web-apps/current-work/#feed0

Re: PaceResurrectAutodiscovery

[Henry Story]

Very nice.

One thing I like about the current atom spec, is that the link  
relations are in fact urls. The link relations are equivalent to the  
urls generated by appending "http://www.iana.org/assignments/ 
relation/" to the "alternate", "self", ... rel="..." strings.


This is very nice, in that it opens up the possibility of placing  
good RDF descriptions of these links at the http://www.iana.org/ 
assignments/relation/, as well as making the link relation very  
extensible (people who want to try out new link relations, can just  
use their own, unambiguous url).


I would recommend you adopt that too. Perhaps you can even adopt the  
iana name space. If we could get them to put the appropriate rdf  
document at that location, people who created/coined new link  
relations could describe these relations as being superproperties or  
subroperties of relations the browser already knows, which would  
allow the browser to partially interpret those.


Just a thought.

Henry

On 23 Nov 2006, at 12:05, Henri Sivonen wrote:



The latest WA 1.0 draft covers this as follows:

"If the alternate keyword is used with the type attribute set to  
the value application/rss+xml or the value application/atom+xml,  
then the user agent must treat the link as it would if it had the  
feed keyword specified as well."

http://whatwg.org/specs/web-apps/current-work/#alternate0

"The feed keyword indicates that the referenced document is a  
syndication feed. If the alternate link type is also specified,  
then the feed is specifically the feed for the current document;  
otherwise, the feed is just a syndication feed, not necessarily  
associated with a particular Web page."

http://whatwg.org/specs/web-apps/current-work/#feed0

--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/

Re: PaceResurrectAutodiscovery

[Henry Story]

I agree. It would be useful to work on placing a little bit more  
weight on the rel relation rather than putting everything on the mime  
type. After all if every link is going to be an "alternate" relation,  
then what was the point of the rel="..." attribute? We might as well  
have stuck with simple  anchors.


I think there is still time to put forward a number of simple  
relations such as "feed", "entry" or even "service" or "collection".  
This could be really useful distinctions.


Henry

On 21 Nov 2006, at 20:46, Eric Scheid wrote:



We're in a good position, in this WG, to suggest a future standard.  
We've

delved deeply into the intricacies, we've examined a wide range of use
cases.

Speaking of which ... there's another use case to consider. Since  
Atom has

promoted interest in using feed documents in an archival manner, it is
entirely reasonable to use @rel="alternate" to point to an archive  
feed
document which contains the *same* content as the referring page,  
as opposed
to referring to a feed document which has the "most recent"  
additions from
the same source as where the contents of the current page came  
from. (what a

mouthful!)

In San Francisco/Bay Area

[Henry Story]

Hi,

I am in the San Francisco/Bay Area region for the coming month. Would  
anyone in the area be up for a group meeting?


Henry

Home page: http://bblfish.net/
Sun Blog: http://blogs.sun.com/bblfish/
Foaf name: http://bblfish.net/people/henry/card#me

Re: searches - was Re: Adding POST capability to atom:link

[Henry Story]

On 8 Nov 2006, at 19:49, Jan Algermissen wrote:

On Nov 8, 2006, at 5:57 PM, Henry Story wrote:


http://www.intertwingly.net/wiki/pie/PaceSparqlLink


Are you really suggesting to use POST for querying (as the Pace says)?


Sorry, it was my misreading of SPARQL protocol to think that POST was  
necessary. You can also use GET, though that would end up creating  
very large URLs. Not sure if there is a way one could shorten SPARQL  
queries. Perhaps work for a SPARQL extension.


I'll change the Pace.

Henry

You wouldn't even be able to send someone a link to the [feed that  
is] the

query result or page through the result etc.

??

Jan

searches - was Re: Adding POST capability to atom:link

[Henry Story]

One very powerful solution would be to use a "sparql" link as  
described in PaceSparqlLink [1]

This would point to a service end point such as the following:

http://roller.blogdns.net:2020/snorql/

to which a simple SPARQL POST or GET request can be made. The above  
url points to the html view of the form which you can query and find  
out about all the entries on the attached roller server at


http://roller.blogdns.net:8080/roller/

Henry


[1] http://www.intertwingly.net/wiki/pie/PaceSparqlLink

On 26 Oct 2006, at 18:24, Gopalan Sri wrote:

Hello,

I am trying to use opensearch to do some paging of my search  
results and

I have a question regard adding POST capabilities to the atom:link
construct.

The information I want to pass back to the server is complex in nature
and makes sense to capture in XML.  My question is whether or not  
there

are any thoughts or plans to extend the atom:link contruct to support
something like this:

http://example.com/"; type="application/atom 
+xml"

action="POST">






Thanks.
Sri Gopalan
Booz Allen Hamilton
Office: Allen 147
Tel: 703.377.1404
Mobile: 703.395.4057

Re: categories and tagging

[Henry Story]

On 2 Nov 2006, at 14:33, Thomas Broyer wrote:

2006/11/2, Henry Story:
Since scheme is a URL I can presumably go there to find something.  
But what?


Some people also want to dereference XML Namespaces' URIs.


It works for the Atom namespace: http://www.w3.org/2005/Atom
You get a nice page that points you to the spec.

It works for all the AtomOwl terms, I used.

@prefix : <http://bblfish.net/work/atom-owl/2006-06-06/#> .

_:C a :Category;
 :term "13745";
 :label "cats"@en;
 :scheme <http://my.categories.net/> .

Each one of them is a URL and can be dereferenced, to find their  
meaning.


I find it odd, that a someone speaking from a group that prides  
itself on being RESTfull, does not want to get the added advantage  
that URLs provide. Especially in APP where we are concentrating so  
much on the HTTP protocol.


Yes. The information we have currently is useful. But if we get  
people to organise their web sites the way Tim Bray has, then we  
could write clients that use this information in much more  
interesting ways.  And we would not need an extension for every  
obviously good way of doing things.


Henry

html content, xml:base and xml:lang

[Henry Story]

Does xml:base and xml:lang apply to html encoded content?

There is the notion of language sensitivity and content is language  
sensitive. So it makes sense to apply it to html content. But what  
about the xml:base?


Henry

Re: categories and tagging

[Henry Story]

On 2 Nov 2006, at 12:19, Thomas Broyer wrote:



[[
The "term" attribute is a string that identifies the category to
which the entry or feed belongs. Category elements MUST have a "term"
attribute.
]]

nowhere is there mentioned a IRI there,


IRIs are not forbidden either, and Andrew's description makes me think
the "concept URI" *is* the "term".


The question is: how does this help any of us? It may look like it is  
a "term", but what is a client meant to do with all this information?


So if Tim Bray uses



Then what am I meant to do with this info? Since scheme is a URL I  
can presumably go there to find something. But what?


Term is not defined to be a URI, and in the above example it is not,  
and so why should I do anything with the term below?


http://my.scheme.net/my-vocabulary/";
  term="http://my.concept.net/my-vocabulary/13745";
  label="cats"
  />


What I am proposing is that we put forward some best practice to  
formalize a useful and RESTful way to publish this information, so  
that clients can use it. With APP we could do something like this: we  
could define for example that when entries are published and they  
contain categories that have a scheme that is accepted by the  
collection, then the entry will be found in the feed that is to be  
found either by appending scheme+term or in the catid location I  
mentioned previously.


So if Tim Bray posts an entry containing


   ...
   


and his collection manages the   
scheme, as defined perhaps in the service document, (and perhaps we  
can place the list of available categories at that scheme location!)  
then his client will know that the entry will also be found in the  
 collection.


Now this would be useful for an APP publishing client, and it would  
be useful for an APP reader, because it could find some useful  
information at these various locations, and it would save us having  
to define an unending number of link relations that parallel the  
categories we have, when it is in fact clear that everybody intends  
to use scheme+term as a uri.


Henry

Re: categories and tagging

[Henry Story]

On 2 Nov 2006, at 08:59, Thomas Broyer wrote:

[redirecting to atom-syntax]


This is also a protocol issue, because we are asking what to do with  
the information in the atom feed. [1]



2006/11/1, Houghton,Andrew:


  concept scheme URI: http://my.scheme.net/my-vocabulary/
  concept URI:http://my.concept.net/my-vocabulary/13745

http://my.scheme.net/my-vocabulary/";
  term="http://my.concept.net/my-vocabulary/13745";
  label="cats"
  />


Thomas, I don't think that this is a natural reading of "term" in the  
atom syntax list.


[[
The "term" attribute is a string that identifies the category to  
which the entry or feed belongs. Category elements MUST have a "term"  
attribute.

]]

nowhere is there mentioned a IRI there, whereas just below

[[
The "scheme" attribute is an IRI that identifies a categorization  
scheme. Category elements MAY have a "scheme" attribute.

]] [2]

The scheme attribute is defined in terms of an  IRI .

To give a bit more context to what Andrew was saying, he was arguing  
that for a mapping between the SKOS [3] vocabulary and the atom  
vocabulary. SKOS is indeed very interesting. It allows one to say  
something like



 a skos:Concept;
 skos:inScheme ;
 skos:prefLabel "cats" .

and much more.

The question remains as to how this can be well mapped to atom.

If I take one of Tim Bray's examples



I can translate this to the AtomOwl ontology [4]

[] a :Category;
   :scheme  ;
   :term "Places" .

Practically, this seems to mean that one can get all the nice info  
about Places at the url


   

And this seems to be becoming quite a common way people are setting  
things up, and also it has some continuity with what the RSS2 folks  
were doing.


[[
 is an optional sub-element of .

It has one optional attribute, domain, a string that identifies a  
categorization taxonomy.


The value of the element is a forward-slash-separated string that  
identifies a hierarchic location in the indicated taxonomy.  
Processors may establish conventions for the interpretation of  
categories. Two examples are provided below:

]] [5]

It follows that what we have is something that can be expressed in  
RDF by saying that the
:scheme and the :term relation form a CIFP [8], ie: together they  
uniquely identify one thing, and furthermore that the identity of the  
thing is given by the concatenation of those two strings.


This seems therefore to capture behavior that is not present in skos,  
but apart from that the two should be quite complimentary. Let us see  
how we can make them more so.


What we need perhaps is some way to make clear what the url of the  
category is.

We could do this as follows:

   1. add a new attribute to identify the category (lets call it catid)
   2. Assume that if a catid is not present, and we have scheme and  
a term attribute, that the catid is formed by the concatenation of  
the scheme+term


we could then write out

 a skos:Concept;
 skos:inScheme ;
 skos:prefLabel "cats" .

like this

http://my.concept.net/my-vocabulary/13745";
  scheme="http://my.scheme.net/my-vocabulary/";
  term='cats' />


Now because the "term" is mandatory in atom (and not the scheme), I  
suggest that one use the skos:prefLabel for it. I know there is a  
label too, but well, it certainly makes it easier to search for  
similar categories using the SPARQL type queries I put forward in [1].


Henry




--
Thomas Broyer



[1] for the atom-syntax people who may not have been following this  
thread then, see
http://blogs.sun.com/bblfish/entry/ 
folksonomies_ontologies_atom_and_the

[2] http://www.atompub.org/rfc4287.html#element.category
[3] http://www.w3.org/TR/swbp-skos-core-guide/
(though I would suggest rewriting the rules using N3, rather  
than the Jena language)

[4] https://sommer.dev.java.net/atom/
[5] http://blogs.law.harvard.edu/tech/ 
rss#ltcategorygtSubelementOfLtitemgt

[6] http://esw.w3.org/topic/CIFP

Re: AD Evaluation of draft-ietf-atompub-protocol-11

[Henry Story]

On 18 Oct 2006, at 16:34, James M Snell wrote:

No, it means only that it's the server's responsibility to determine
when atom:updated should be updated and when it shouldn't.  If the
server wishes to delegate that responsibility to the client, then  
that's

fine.


Is this not splitting hairs a little? In the end it is always the  
server who is going to decide if it wants to accept anything at all.  
The server could also change the content if it wished (though I would  
not use such a service, having lived through the greed of the .com,  
we can be assured that servers will want to add their adds to your  
content). If we use the word responsibility this way then it's not  
going to help us distinguish anything interesting.


When it comes down to it, my feeling was that the client decides  
whether or not it wants to check that box "significant update" or  
not. The client does not have any say in what the value of app:edited  
is.


But special cases can be made. It's just that those would be  
understood to be deviations from the norm.



- James

Henry Story meant to write:

[snip]
If the server controls atom:updated then what was the point of  
the  whole discussion of app:edited?
The client controls atom:updated. It is the client who decides  
what a significant change is.


The server controls app:edited. Any edit changes app:edited.

Re: AD Evaluation of draft-ietf-atompub-protocol-11

[Henry Story]

On 18 Oct 2006, at 16:10, John Panzer wrote:



My assumption: Tim is correct.  The server controls  
atom:updated.  While

the client is required to provide a valid atom:updated element, the
server can (and in most cases will) ignore that value.



Completely disagree.
If the server controls atom:updated then what was the point of  
the  whole discussion of app:edited?
the client controls app:edited. It is the client who decides what  
if  there was a significant change.

The server controls app:edited. Any edit, changes app:edited.


I think you have a typo somewhere in the above.


Duh. You are right. I wish there were unit tests for typing docs. Why  
is it one always has to test everything in life?


I meant:

If the server controls atom:updated then what was the point of the   
whole discussion of app:edited?
The client controls atom:updated. It is the client who decides what a  
significant change is.


The server controls app:edited. Any edit changes app:edited.

Henry

Re: AD Evaluation of draft-ietf-atompub-protocol-11

[Henry Story]

Many thanks to Lisa for the lengthy and detailed comments. I am just  
replying to those comments relating to the parts of the spec I  
understand best.


On 18 Oct 2006, at 01:40, James M Snell wrote:


*Synchronization*

I predict that some AtomPub authoring clients will attempt to
synchronize: to maintain an offline copy of the feed including all  
its

MERs and media resources, and to keep that offline copy up-to-date.
Some will probably even allow offline authoring of new posts, and  
offer

to synchronize when the client next goes online -- because of the
possibility of multiple authors, this may mean at times that the  
client
would download new entries created by other authors, upload new  
entries

created offline, and reconcile its offline copy of feed documents.

Because authoring clients will attempt to do this based on Last- 
Modified

and ETag -- after all, the functionality is all there in some form or
another -- the spec needs a little more clarity on how the client can
rely on this working.  Otherwise, some servers may omit features that
these authoring clients require, or implement them oddly.  While I  
would
never suggest repeating all the requirements from other specs (in  
this

case HTTP), there are cases where clarity and interoperability are
greatly improved by at least referencing explicitly requirements from
HTTP.  It's also possible to add new requirements based on  
features in

HTTP, that apply to Atom servers alone.



I would be very happy to see some discussion of this in the spec,
especially if it normatively required the use of ETags for offline
synchronization.


I think synchronisation would be best dealt with by adding  
functionality to sort the collection in different ways.
Currently the sort order is a SHOULD on atom:updated. That does not  
allow clients to find the most recent edits. If there were a way to  
sort the entries by app:edited one could find the most recent edits  
quite quickly. Doing a HEAD on all the entries to find out which  
changed by comparing etags is not really an option. For large blogs  
such as Tim Bray's ongoing this would use up way to many resources  
and take way too long.




[snip]
of HTTP (calendaring) than the general case.  If HTTP  
synchronization in

authoring cases were clearly defined and had not lead to years of
arguments since the last HTTP update, I would probably feel  
differently

about just silently relying on the mechanisms in HTTP.



+1


In any case, I have very specific brief suggestions to cover
synchronization so that it's implemented more successfully than not.
- Consider adding a brief section offering clients non-normative
guidelines on synchronization.  It doesn't have to limit server  
behavior

so much as point out with green and red lights where the fairway is
(mixing transportation and golfing metaphors in my head)
- Make a few requirements of servers to avoid some of those HTTP
ambiguities.  For example:
"The ETag or Last-Modified values for a member resource MUST  
change when
any metadata in the resource changes, as well as text/content, and  
this

includes "next" and "last" link relation values.  The ETag or
Last-Modified values of a member resource MUST NOT change solely  
because

an associated other resource (e.g. the media resource being an
associated resource to the media link entry resource) changed.  "


+0.5. I would add that the ETag/Last-Modified values of a resource
SHOULD NOT change solely because of non-significant changes to the
infoset serialization of an entry (e.g. a different namespace  
prefix is
used, or whitespace is added or removed, etc).  I would also prefer  
that
the ETag for a MLE change when it's associated media resource is  
updated.




More open questions that might be related to synch or might have
relevance even for clients that don't do full synch:
- What is the relationship, if any, between the "atom:updated"  
value and

the HTTP "Last-Modified" value.  Can the "atom:updated" value ever be
later (greater) than the "Last-Modified" value?  I believe it can  
be the

same or earlier, but the spec doesn't disallow the broken case.


My assumption: There is no relationship.  atom:updated should be  
treated

as being entirely independent of Last-Modified.


yes.


It might be reasonable,
however, to define a relationship between Last-Modified and  
app:edited.


No. In discussions on the topic of synchronisation it became obvious  
that people wanted to have servers add properties to entries, such as  
changing the number of comments for an entry, without this changing  
app:edited.


A new app:modified would be the closest to something that could have  
a 1-1 relation to Last-Modified. But there was a lot of push back  
against app:modified as being too britle - ie. changing too often  
(xml formating changes could cause app:modified to change)


- Is it clear whether the client MUST GET the entry after  
modifying it

in order to have an accurate offline cache?  (

Re: AD Evaluation of draft-ietf-atompub-protocol-11

[Henry Story]

On 18 Oct 2006, at 01:40, James M Snell wrote:


[snip]
The spec says "The value of atom:updated is only changed when the  
change

to a member resource is considered significant. "  The use of passive
voice obscures who does what here.  When the client doesn't suggest a
value for "atom:updated", does the server provide one, and if so, how
does the server know what is "significant"?   I thought it would  
always
be the client suggesting values, but Tim says that the server  
controls

atom:updated which could imply that the client doesn't even need to
suggest values.  See above about whether the server MUST accept  
certain
values for "updated", or more likely, MUST NOT accept suggested  
values

for "updated" when they're clearly wrong (e.g. this entry was last
updated on October 16, 1906).



My assumption: Tim is correct.  The server controls atom:updated.  
While

the client is required to provide a valid atom:updated element, the
server can (and in most cases will) ignore that value.


Completely disagree.
If the server controls atom:updated then what was the point of the  
whole discussion of app:edited?
the client controls app:edited. It is the client who decides what if  
there was a significant change.

The server controls app:edited. Any edit, changes app:edited.

If you have it your way, then atom:updated will end up meaning  
app:edited, which Tim Bray specifically mentioned he did not want in  
his wiki example.


Henry

SPARQLing Roller

[Henry Story]

I have recently been working on adding a SPARQL end point to a test  
Roller weblogger server.


Using the D2RQ library developed at the Freie Universität of Berlin  
and the Roller Weblogger software that is powering blogs.sun.com, I  
have put up a test server that maps Roller's mysql tables to the  
AtomOwl ontology.


I have blogged about this in more length with hyperlinks to  
presentations, the online server, and all the components.


http://blogs.sun.com/bblfish/entry/sparqling_roller

This could work very nicely with the PaceSparqlLink I proposed some  
months ago.

http://www.intertwingly.net/wiki/pie/PaceSparqlLink

Henry

Foaf name: http://bblfish.net/people/henry/card#me

Fwd: Atom and bidi

[Henry Story]

The Atom Syntax group is discussing a bidi proposal (see end). I am  
not sure how much chance it has of getting through, and I don't  
understand the issues that well yet ( I have a few other things to do  
right now ), but I thought I should point out how I think it could  
impact AtomOwl.


In a recent thread in this group entitled "Making Content into  
Literals in AtomOWL", I was arguing for using literals more in the  
AtomOwl ontology.


Ie. I am suggesting that we convert


 Atom-Powered Robots Run Amok
 ...


into

[] a :Entry;
:title "Atom-Powered Robots Run Amok"^^:text ;
.

Literals in rdf don't have space for a bidi encoding. There is space  
for language encoding

such as "hello"@en^^:text but none for bidi.

I suppose this is not really a problem as one could always encode  
this in unicode when needed or for xml

fragments add it to a  in the content.

If it really were a problem, then that may constitute an argument for  
using a content object.


[] :title [ a :Content;
:text "Atom-Powered Robots Run Amok";
:bidi :rtl; ] .

Henry


Begin forwarded message:


From: James M Snell <[EMAIL PROTECTED]>
Date: 3 October 2006 16:33:07 GMT+02:00
To: James Holderness <[EMAIL PROTECTED]>
Cc: atom-syntax@imc.org
Subject: Re: Atom and bidi


Doh! I actually meant [RLE] here and not [RLO].  Either way, yes, I  
know

there is a difference. The point I was trying to make is the same made
in HTML4-8.2:

Although Unicode specifies special characters that deal with text
direction, HTML offers higher-level markup constructs that do the
same thing: the dir attribute (do not confuse with the DIR  
element)
and the BDO element. Thus, to express a Hebrew quotation, it is  
more

intuitive to write

...a Hebrew quotation...

than the equivalent with Unicode references:

‫״...a Hebrew quotation...״‬

- James

James Holderness wrote:


James M Snell wrote:
just to be clear, I'm saying the following would be equivalent  
(where

[RLO] and [PDF] represent the corresponding bidi controls)

ABCDEFG
[RLO]ABCDEFG[PDF]


You should be aware that there is a significant difference between  
RTL

override, RTL embedding and the RTL direction attribute in HTML.

Regards
James

Re: URGENT: Remove atom:updated ordering requirement?

[Henry Story]

+1 to make the MUST a SHOULD
+1 on app:edited

But I think it would be really useful if we could have something that  
allowed the user to specify how the feed should be sorted.


Henry

On 27 Sep 2006, at 22:14, Tim Bray wrote:




Please see the dialogue below.


(Eric's point seems plausible to me; personally I'd be inclined to  
a +1.)



Can we have some feedback from the WG ASAP?  We want to take  
protocol-11 to the IETF.



  -Tim

On Sep 26, 2006, at 4:59 PM, Eric Scheid wrote:



On 27/9/06 8:15 AM, "Tim Bray" <[EMAIL PROTECTED]> wrote:

PaceAppEdited: Lots of discussion.  There seems universal support  
for

the utility of an app:edited element, and an assertion that entry
members SHOULD contain one.  On the other hand, every discussion of
sort order has spiraled instantly into a rat-hole.

Conclusion.  PaceAppEdited is accepted, in part. The second part of
the proposal, defining the app:edited element, is ACCEPTED.  The
first part, imposing a requirement on the sort order of collections,
clearly does not have consensus support.


There also seems to be universal support for the notion that  
collection
feeds could be sorted by something other than what's currently in  
the spec.

The spec currently not only says collections are to be sorted by
atom:updated, but because of the MUST it also says it MUST NOT be  
sorted by

anything *else*, which is a problem.

Section 10.0 ¶ 2 says this:

The entries in the returned Atom Feed MUST be ordered by their
   "atom:updated" property, with the most recently updated entries
coming first in the document order. Clients SHOULD be constructed
in consideration of the fact that changes which do not alter the
atom:updated value of an entry will not affect the position of
the entry in a Collection.

We need to either strike that entire paragraph, or at the very  
least make

that MUST into a SHOULD.

I say +1 to s/MUST/SHOULD/

e.

Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests

[Henry Story]

On the other hand, if one strips the  element, then :xhtml can  
no longer be an inverse functional property, as contents with  
different bases could have very different meanings. Just think of  
xhtml content with a picture, which in one subtree points to bush,  
and in another one points to Gore, the relative uri references being  
the same in both cases.


This seems to make it more reasonable to create a new literal type  
which contains the . (it makes finding duplicates in an rdf  
database easier).


On that topic are there not xhtml ways to create xml:base and  
xml:lang elements? Should those not perhaps be used instead on the  
 element?


Henry

On 29 Jun 2006, at 00:11, Henry Story wrote:



Thanks everyone for this really interesting discussion. I have  
added a note to this effect to the latest atom-owl ontology [1].


In Atom-Owl we could easily do both.

[] :content "Oui!"^:xhtml.

or we could have

[] :content "Oui!"@fr^:xhtml .

or

[] :content [ :xhtml "oui";
  :lang "en" ].


It would be simplest I suppose to have the :xhtml type be defined  
as always having an  element. Except that of course it  
would look odd for xhtml content that contains an  base tag  
such as



  ..


From this discussion it looks like the most reasonable would be to  
strip the  element. In which case one may wonder what the  
whole purpose of putting the  in the content really was in the  
first place.


Henry

[1] https://sommer.dev.java.net/atom/2006-06-06/awol.html#term_xhtml


On 28 Jun 2006, at 23:53, Antone Roundy wrote:



On Jun 28, 2006, at 3:10 PM, Robert Sayre wrote:

The content in the entries below should be handled the same way:

http://example.com/foo/";>
  ...
  
  http://example.com/
feu/">axe
  


http://example.com/foo/";>
  ...
  
feu/">
  axexhtml:div>

  



Of course the end result of both should be identical.  Is that  
what you mean by "should be handled the same way"?  The question  
is, if the xhtml:div is stripped by the library before handing it  
off to the app, how is the app going to get the attributes that  
were on the div?  Is the library going to push those values down  
into the content or act as if they were on the atom:content  
element (or something similar to that)?


BTW, it just occurred to me that pushing them down into the  
content won't work.  Here's an example where that would fail:



  ...
  
  Oui!
  


Notice that there are no elements inside the xhtml:div for  
xml:lang to be attached to (and even if there were any, any text  
appearing outside of them would not have the correct xml:lang  
attached to it).


So it looks like the options (both of a which a single library  
could support, of course) are:


* Strip the div, but provide a way to get the attributes that were  
on it

or
* Leave the div

Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests

[Henry Story]

Thanks everyone for this really interesting discussion. I have added  
a note to this effect to the latest atom-owl ontology [1].


In Atom-Owl we could easily do both.

[] :content "Oui!"^:xhtml.

or we could have

[] :content "Oui!"@fr^:xhtml .

or

[] :content [ :xhtml "oui";
  :lang "en" ].


It would be simplest I suppose to have the :xhtml type be defined as  
always having an  element. Except that of course it would  
look odd for xhtml content that contains an  base tag such as



  ..


From this discussion it looks like the most reasonable would be to  
strip the  element. In which case one may wonder what the whole  
purpose of putting the  in the content really was in the first  
place.


Henry

[1] https://sommer.dev.java.net/atom/2006-06-06/awol.html#term_xhtml


On 28 Jun 2006, at 23:53, Antone Roundy wrote:



On Jun 28, 2006, at 3:10 PM, Robert Sayre wrote:

The content in the entries below should be handled the same way:

http://example.com/foo/";>
  ...
  
  http://example.com/
feu/">axe
  


http://example.com/foo/";>
  ...
  
feu/">
  axexhtml:div>

  



Of course the end result of both should be identical.  Is that what  
you mean by "should be handled the same way"?  The question is, if  
the xhtml:div is stripped by the library before handing it off to  
the app, how is the app going to get the attributes that were on  
the div?  Is the library going to push those values down into the  
content or act as if they were on the atom:content element (or  
something similar to that)?


BTW, it just occurred to me that pushing them down into the content  
won't work.  Here's an example where that would fail:



  ...
  
  Oui!
  


Notice that there are no elements inside the xhtml:div for xml:lang  
to be attached to (and even if there were any, any text appearing  
outside of them would not have the correct xml:lang attached to it).


So it looks like the options (both of a which a single library  
could support, of course) are:


* Strip the div, but provide a way to get the attributes that were  
on it

or
* Leave the div

Re: Dublin Core and Atom: Any plans for an (Informational) RFC?

[Henry Story]

The Atom-OWL group is working on an ontology for Atom. You can find  
the latest version here


https://sommer.dev.java.net/atom/

It comes with a XSLT 2.0 and XQuery 1.0 transform from atom xml to  
atom-owl. (The XQuery transform is the best). We were thinking of  
adding relations from the atom-owl vocabulary to the DC vocabulary.  
Have a look at what is there now, and let us know what you think.


Henry

On 19 Jun 2006, at 15:31, Andreas Sewe wrote:



I wonder whether there are any plans of publishing an (perhaps  
Informational) RFC on the use of DCMI Metadata Terms in conjunction  
with Atom feeds and entries?


Given both the popularity of that vocabulary in the various flavors  
of RSS and the fact that it offers numerous useful refinements of  
Atom's built-in metadata (I still remember the PaceDate* debate),  
this seems like a good idea to me. So, are there already efforts in  
this direction?


Regards,

Andreas Sewe

Atom N3

[Henry Story]

A new, clearer more concise ontology for atom is now available at

https://sommer.dev.java.net/atom/

It comes with an XSLT style sheet to transform atom feeds into  
turtle, a subset of N3 [1], and is released under a BSD license.


Please feel free to contribute bug reports, patches and any other  
feedback to me or to the mailing list at http://groups.google.com/ 
group/atom-owl/


Sincerely,

Henry Story


[1] http://blogs.sun.com/roller/page/bblfish/20060614


Home page: http://bblfish.net/
Sun Blog: http://blogs.sun.com/bblfish/

Re: when should two entries have the same id?

[Henry Story]

On 8 Jun 2006, at 14:44, Elliotte Harold wrote:



James M Snell wrote:

That's not quite accurate.  Two entries with the same atom:id may  
appear

within the same atom:feed only if they have different atom:updated
elements.  The spec is silent on whether or not two entries  
existing in
*separate documents* may have identical atom:id and atom:updated  
values.


They're ids, not guids. Certainly I would expect that there'll be  
some accidental conflicts. For instance one site might number its  
posts post1, post2, post3,...; and a different, unrelated site  
might do the same.


No, they are guids. The datatype for an id is a IRI, which is a  
generalisaiton of URI. IRIs are constructed in such a way that it  
should be easy to construct universally unique ones without ever  
having name clashes. If name clashes there are, this will either be  
due to incompetence or to malevolence.


Henry



--
Elliotte Rusty Harold  [EMAIL PROTECTED]
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/ 
cafeaulaitA/

Re: when should two entries have the same id?

[Henry Story]

Yes, I know, the atom syntax doc does not make statements about what  
happens in different feeds. But that does not mean that we are not  
forced logically to a conclusion. There was a very in depth  
discussion of this by the way on the atom semantics [1] mail list  
this February.


I think the Atom Protocol is forcing the issue towards there being  
only one entry per update time stamp. When you publish an entry with  
an updated time stamp it is going to have to appear in a feed at some  
point. And that won't be possible unless you overwrite one or the  
other entries.


Also think of agregators. If you have the same entry with the same id  
but different content, which is it going to choose?


Henry

[1] http://groups.google.com/group/atom-owl/browse_frm/thread/ 
357e36c4ee9cd31b/



On 7 Jun 2006, at 20:40, James M Snell wrote:

Henry Story wrote:


You can have two entries or feeds with the same id, as long as  
they have

different updated time stamps.


That's not quite accurate.  Two entries with the same atom:id may  
appear

within the same atom:feed only if they have different atom:updated
elements.  The spec is silent on whether or not two entries  
existing in
*separate documents* may have identical atom:id and atom:updated  
values.


Consider the case where my personal weblog publishes two Atom feeds.
One is a "full-content" feed that publishes content as XHTML.  The
second is a "partial-content" feed that strips the markup and  
publishes

content as plain text in the atom:summary while containing an
atom:content with a src attribute to the original XHTML.  They  
exist in

two separate Atom documents and both are based on the same underlying
blog post.  The atom:id and atom:updated values for each entry are
identical.

Another example.  I post an iCal file to an APP collection.  In the
collection feed, I see a "media link entry" that uses content/@src to
point to the iCal.  However, another feed that is used to provide a
summary of upcoming events has entries whose content element  
contains an

XHTML rendering of the iCal files.  Each entry in the summary feed
corresponds to exactly one entry in the APP collection; should they or
should they not use the same atom:id and atom:updated values?

- James


It's very much the same as you being Robert Yates all your life, but
having different sizes throughout your life. At any point in time you
have all the same properties...

Henry

On 7 Jun 2006, at 19:29, Robert Yates wrote:



This relates to work that we are doing with the publishing protocol,
but is syntax related.

In an implementation of APP a single entry can appear both in the  
APP

collection and in any number of arbitrary feeds that the site
subsequently offers.

These feeds / collections can be optimized differently depending on
the client.  For example, an entry in the collection feed may  
have its
content "out of lined" whereas the "same" entry rendered in a  
feed may

have its content inlined.  There are other different optimizations
that we are investigating, that cause the entry representation in
various feeds / collections to be different, even though it has
originated from the same source.

So are these representations in the different feeds / collections  
the
same entry or different entries?  Should they have the same id?  
and if
a feedreader comes across two entries with the same atom id,  
what, if

anything, can it infer from that? is it only that they came from the
same source?

Many Thanks,

Rob

Re: when should two entries have the same id?

[Henry Story]

You can have two entries or feeds with the same id, as long as they  
have different updated time stamps.
It's very much the same as you being Robert Yates all your life, but  
having different sizes throughout your life. At any point in time you  
have all the same properties...


Henry

On 7 Jun 2006, at 19:29, Robert Yates wrote:



This relates to work that we are doing with the publishing  
protocol, but is syntax related.


In an implementation of APP a single entry can appear both in the  
APP collection and in any number of arbitrary feeds that the site  
subsequently offers.


These feeds / collections can be optimized differently depending on  
the client.  For example, an entry in the collection feed may have  
its content "out of lined" whereas the "same" entry rendered in a  
feed may have its content inlined.  There are other different  
optimizations that we are investigating, that cause the entry  
representation in various feeds / collections to be different, even  
though it has originated from the same source.


So are these representations in the different feeds / collections  
the same entry or different entries?  Should they have the same id?  
and if a feedreader comes across two entries with the same atom id,  
what, if anything, can it infer from that? is it only that they  
came from the same source?


Many Thanks,

Rob

formal methods: AtomOwl

[Henry Story]

A week ago I attended the W3C Technical Plenary Week in Cannes  
(France). There was an very interesting session on Formal Methods at  
the W3C [1]. The specs that had benefited from working with formal  
methods were:


- XQuery
- OWL and RDf
- Web Services Choreography and Web Services Descriptions  
(using pi notation)

- WSDL 2.0 (using Z notation)

In some cases parts of the formalization became the authoritative  
work, in others they only had a guiding and clarifying role, and the  
english text remained the authoritative work. But in every case the  
feeling was that the formal backing helped work out a lot of problems  
that were difficult to notice in the natural language text.


	Now each of the formal methods languages used is in the end back by  
Set Theory, which RDF and OWL and other semantic web enterprises are  
based on. My suggestion was therefore that RDF/OWL could itself be a  
formal language one can use to help explicate various standards.


	The work being done by the AtomOwl group could then be understood to  
simply be a formalization of the work done by the atom syntax and APP  
groups, where the spec release by these groups remain the  
authoritative texts. The advantage of the Semantic Web languages over  
these other formalisms is that it is much more widely understood, is  
web centric, and furthermore has some very interesting direct  
practical applications. AtomOwl [2] could for example be directly  
used to help create Sparql end points for aggregators [3], as well as  
being used directly as a data model as BlogEd does [4].


	It is in this light that I am looking to set W3C Working Group (or  
XG) to create a standard ontology for Atom. As a formalization of  
Atom it will have to be faithful to the specs released by these IETF  
groups, which as stated, remain authoritative. There is interest from  
IBM,  Talis Information and Sun Microsystems, three members of the  
W3C to work on this. If other members would like to join we would be  
more than happy. We would be very interested to hear from other  
members of the Atom group on how we can proceed to make the resulting  
spec be of the highest possible quality. Ideally we would like to  
place the resulting document at the Atom namespace location with some  
(XSLT?) transform that would be the default transform from atom to RDF.


We are very open on what the best way to proceed is.

Yours sincerely,

Henry Story


Sem Web Researcher, Sun Microsystems
http://blogs.sun.com/bblfish/


[1] Session 7: Adventures in Formal Methods
http://www.w3.org/2006/03/01-TechPlenAgenda.html
[2] http://bblfish.net/work/atom-owl/2005-10-23/
[3] see http://www.intertwingly.net/wiki/pie/PaceSparqlLink
[4] https://bloged.dev.java.net/

Re: Feed paging and atom:feed/atom:id

[Henry Story]

I think they should all have the same id.  But I don't have any good  
arguments in favor. It just seems to make sense that way.


Henry

On 10 Mar 2006, at 18:44, James M Snell wrote:


If the feeds have the same atom:id, I would submit that they form a
single logical feed.  Meaning that all of the feed documents in an
incremental feed (using Mark's Feed History terminology) SHOULD use  
the

same atom:id value.  This is the way I have implemented paging in our
APP implementation.  If the linked feeds have different atom:id  
values,

they should represent different logical feeds.

Thoughts?

- James

further refinements to the APP model of Collections

[Henry Story]

My first N3 representation of the example Service document, with 3  
classes :Service, :Workspace, and :Collection


<> a :Service;
   :workspace [ a :Workspace;
   :title "Main Site"@en;
   :primaryCollection [ a :Collection;
:title "entries"@en;
:href ;
:member-type :entry ];
   :primaryCollection [ a :Collection;
:title "photos"@en;
:href 
:member-type :media ]
 ];
   :workspace [ a :Workspace;
   :title "Side Bar Blog"@en;
   :primaryCollection  [ a :Collection;
 :title "Remaindered Links"@en;
 :href ;

 :member-type :entry ]
 ] .


We can think of a Collection as a Feed. Perhaps a subclass of feeds  
document resources at which one can also post? Perhaps we can even  
specify this by creating two classes :EntryCollection  
and :MediaCollection which we can define as follows


:Collection rdfs:subClassOf atom:Feed;
rdfs:label "Atom Application Collection";
rdfs:comment "An resource to which one can POST  
resources, and which presents itself as an atom feed";

owl:unionOf ( :EntryCollection :MediaCollection ).

:EntryCollection rdfs:subClassOf :Collection;
rdfs:label "Entry Collection class";
rdfs:comment "One should only POST atom entries to entry  
collections" .


:MediaCollection rdfs:subClassOf :Collection;
rdfs:label "Media Collection class";
rdfs:comment "Content posted to this collection will  
create an entry and be the content of the created entry";

owl:disjointWith :EntryCollection .


Let us keep it simple and ignore the primary and secondary collection  
distinction. Our example above could then be better written as


<> a :Service;
   :workspace [ a :Workspace;
   :title "Main Site"@en;
   :collection [ = ;
 a :EntryCollection;
 :title "entries"@en ];
   :collection [  = ;
 a :MediaCollection;
 :title "photos"@en ]
  ];
   :workspace [ a :Workspace;
   :title "Side Bar Blog"@en;
   :collection  [ = ;
  a :EntryCollection;
  :title "Remaindered Links"@en;
]
  ] .


Because collections are subclasses of Feeds, we can also add the  
other feed properties, such as id, author, updated, etc, to them if  
we want. Of course no need to add entries in the Service document  
itself as that would be of no interest.


If we represent things as above then we would have to specify that  
the title be the title of the feed at the href location. But that  
does not seem very controversial. Why not nail that down in the spec?



Henry

Re: wiki mime type

[Henry Story]

On 6 Mar 2006, at 18:54, James Tauber wrote:
Agreed that this would be very useful and also that it needs to be  
done

on a per wiki format basis.


Is there a forum a large number of them tend to hang out on, so that  
one could ask them to think about this? What would be the best to do  
in the meantime? Something like


text/x-wiki+textile
text/x-wiki+markdown

perhaps?



I think, however, that this is something the format creators should be
encouraged to register, or at least suggest a convention for.

James

On Mon, 06 Mar 2006 07:59:10 -0800, "Walter Underwood"
<[EMAIL PROTECTED]> said:


--On March 6, 2006 3:59:39 PM +0100 Henry Story  
<[EMAIL PROTECTED]>

wrote:


Silly question probably, but is there a wiki mime type?
I was thinking of "text/wiki" or "text/x-wiki" or something.

I want people to be able to edit their blogs in wiki format in  
BlogEd  and be able
to distinguish when they do that from when they enter  plain  
text, html or xhtml.

Perhaps this is also useful for the protocol.


It would be really useful, especially for feeds that archive the  
content

of a blog. It would be best to use the official names of the formats,
like
"text/markdown" or "text/textile". The wikis and blogs that I use  
can be

configured to accept different formats, so "text/wiki" doesn't work.

wunder
--
Walter Underwood
Principal Software Architect, Autonomy


--
  James Tauber   http://jtauber.com/
  journeyman of somehttp://jtauber.com/blog/

wiki mime type

[Henry Story]

Silly question probably, but is there a wiki mime type?
I was thinking of "text/wiki" or "text/x-wiki" or something.

I want people to be able to edit their blogs in wiki format in BlogEd  
and be able to distinguish when they do that from when they enter  
plain text, html or xhtml. Perhaps this is also useful for the protocol.


Henry

Re: More on atom:id handling

[Henry Story]

On 2 Feb 2006, at 02:09, Danny Ayers wrote:



On 2/1/06, A. Pagaltzis <[EMAIL PROTECTED]> wrote:


* David Powell <[EMAIL PROTECTED]> [2006-02-01 17:10]:

On the contrary, I have a problem with preventing multiple
revisions from having the same atom:updated value.


But then you have no idea which revision will be picked by
clients that try to show the latest one, which to me sounds like
it fulfills the criteria for a potential interop problem, which
is exactly what "SHOULD" is about, so I think this was the right
choice.


yes. One could of course have also allowed different language  
versions of an entry at the same time for example. But then things  
would probably have gotten a lot more complicated in the protocol.



It's not straightforward, this came up pretty quickly in the Atom/OWL
efforts. As Bill said, it's a composite key.


yes. Though this is very much true for the web on the whole. A url  
names a thing
but there may be many representations for that thing, even at the  
same time. So for a given URL there can be any number of different  
language dependent representations, or even different mime type  
representations. If you want to refer to the representations instead  
of the resource you do usually need a composite key. You are not  
usually aware of this composite key nature of the web, as you usually  
use defaults: the default representation is returned as the  
representation given to you at the time you ask for it, in the  
default language, for the default mime type.


An atom Entry is a representation of the resource named by the id.  
This id can only have representations that vary along the axis of  
time it seems.


In RDF/OWL that has so far demanded a rule* - somewhat less  
convenient than having a single

URI as id.


The id relation is functional. That is an entry can only have one id.

[ a :Entry;
  :id ;
  :updated "2003-12-13T18:30:02Z"^^xsd:dateTime;
  :title "an example"
] .

but the same feed can have another anonymous :Entry with the same id.

[ a :Entry;
  :id ;
  :updated "2005-08-24T09:32:04Z"^^xsd:dateTime;
  :title "an fixed example"
]

The inverse of :id is :version so that we could rewrite the above  
triples as


 :version [ a :Entry
 :updated  
"2003-12-13T18:30:02Z"^^xsd:dateTime;

 :title "an example" ];
  :version [ a :Entry
 :updated  
"2005-08-24T09:32:04Z"^^xsd:dateTime;

 :title "a fixed example" ] .

which shows more clearly the relation between the resource and its 2  
representations.


Now the question is when we find two entries with the same id and the  
same updated time stamp are they the same entry? This is where the  
CIFP's Danny metnioned enter into play.


And this is where I am unsure in atom-owl currently. My feeling is  
that deep down that is what all of us believe.



The question is, from what is the composite key formed? id
certainly, updated too - but is same id+updated enough? What if other
parts of the entry differ? Different xml:lang even...same entry or
different?


or is it only the case in one feed document?



*see also : http://esw.w3.org/topic/CIFP

Cheers,
Danny.



--

http://dannyayers.com

Re: todo: add language encoding information

[Henry Story]

 a debate as to whether multilingual  
representations of an entry can exist simultaneously. Ie. is this a  
special case where SHOULD rule can be broken? ]]


1. give entries urls


When entries have urls then it is easy to link to them.
Here is an example:


...

		

Atom-Powered Robots Run Amok

tag:eg.com,2005/en/atom03
2003-12-13T18:30:02Z
Some text.
...



Robots Atomiques se révoltent
http://example.org/2003/12/13/atom03"/>

tag:eg.com,2005/fr/atom03
2003-12-13T18:30:02Z
Some text.
...




The disadvantage is that one has to place entries at well known  
locations for this to work correctly, which creates duplication of  
entries (one in the feed, and one on the hard drive). The protocol  
may force this issue anyway. (does the atom protocol force entries to  
have urls, so they can be GET, PUT, and DELETEed?)




2. if entries do not have URLs
--

Then one can only point to entries by their id. But since ids are not  
dereferenceable, this is not very helpful. It would tell the reader  
of the entry that this is an entry whose metadata has an alternate  
language version, and so it would/could reduce the number of alterts  
a client would need to send out (he has already seen the alternate  
entry for example).


  this would require a new link type

  

where the href points to the id of the translated entry. I suppose  
one would assume that at the

time of the entry update the relations was true.

Now if one wanted to find the feed in which the entry with that id  
had appeared one would have to add an extension to the link such as  
xxx:feedhref="http://example.org/feed.atom";



http://example.org/feed.atom";>


where xxx:feedhref would point to a feed document that forms part of  
a next, prev chain of such documents that constitute a feed, in which  
the other language version entry could be found (among other places)




QUICK CONCLUSION


The simplest and least powerful solution of simply having entries  
with the same id but in different languages is (very probably) not  
possible because of the SHOULD restriction in the spec. This makes it  
impossible for one to just state that feeds are translations of each  
other, as it would not help one work out which entries in one feed  
were translations of which entries in the other feed.


We need a link relation to relate entries. The link alternate  
pointing to an entry would work best if entries had urls that were  
dereferenceable.


Otherwise one needs to create new "translation" link relation that  
points to an entry id in its href. This would not be very helpful in  
finding the translated entry (unless of course the id of an entry was  
the same place as that at which it could be GET, PUT, POST and DELETEd)



Henry Story

PS. Not sure what I should do with the above. Perhaps write it up  
somehow?



On 31 Jan 2006, at 02:17, James Holderness wrote:



Henry Story wrote:

Just re-reading your mail I think you make a good point that perhaps
"translation" is the wrong word to use. We would like something more
abstract such as "otherLanguageVersion". This made me think that the
word we want is "alternate". And then looking at the spec again I
found the following:

[[
4.2.7.4.  The "hreflang" Attribute


This was the first thing I suggested...

"If you want to link the various translations together you can add  
one or more link elements at the top of the feed with  
rel="alternate" and hreflang set to the language of the alternate  
feed. If you're feeling really enthusiastic you can include  
alternate links pointing to the translated html pages for each  
entry too." [1]


Regards
James

[1] http://www.imc.org/atom-syntax/mail-archive/msg17609.html

Re: todo: add language encoding information

[Henry Story]

On 1 Feb 2006, at 02:10, Eric Scheid wrote:



On 31/1/06 1:27 PM, "James Holderness" <[EMAIL PROTECTED]> wrote:


Actually I was thinking just a regular href and type. For example:

http://mydomain.com/feed";
hreflang="fr"
x:id="french_entry_id"
x:updated="2005-11-15T18:30:02X" />

I'm not sure how valid that is considering a client that didn't  
understand
this extension would consider the full feed to be an alternative  
for that

one particular entry which doesn't seem right.


Any reason that application/atom+xml document couldn't be an Atom  
Entry
Document, apart from the current lack of reader/browser support? It  
could
also then include the links necessary to subscribe to the specific  
language

feed.


I think that was one of James' original suggestions. It seems like  
one good solution. The only problem is that it forces people to have  
Entry Documents.


I am just writing up a document listing all the different ways one  
can solve this problem...




e.

Re: todo: add language encoding information

[Henry Story]

This looks like a good place to look for a solution.

On 31 Jan 2006, at 03:27, James Holderness wrote:

Henry Story wrote:
Presumably one would need to add an x:feed="http://mydomain.com/ 
feed" attribute for translations of entries that appear in other  
feeds.


Actually I was thinking just a regular href and type. For example:

http://mydomain.com/feed";
 hreflang="fr"
 x:id="french_entry_id"
 x:updated="2005-11-15T18:30:02X" />

I'm not sure how valid that is considering a client that didn't  
understand this extension would consider the full feed to be an  
alternative for that one particular entry which doesn't seem right.



Your point is well taken that the extension would be confusing for  
tools that did not understand it.  Perhaps one could create a new  
link rel="translation" that would point to a feed containing an  
alternate entry with the given x:id and updated at the particular time.


http://mydomain.com/feed";
  hreflang="fr"
  x:id="french_entry_id"
  x:updated="2005-11-15T18:30:02X" />

would that still be confusing to tools that did not understand the  
extension?


Henry

Re: todo: add language encoding information

[Henry Story]

On 31 Jan 2006, at 03:27, James Holderness wrote:
Personally I would have preferred using a fragment identifier. So  
the above example would look something like this:


http://mydomain.com/feed#french_entry_id";
 hreflang="fr"
 x:updated="2005-11-15T18:30:02X" />

And a link to an entry within the same feed could be done with a  
fragment only uri, like this:




But from what I can make out, this sort of thing would only be  
valid if atom:id was defined to be an ID attribute which would  
assumedly require an Atom DTD.


And that won't be quite possible because:
	- a feed can have a number of entries with the same id, whereas I  
think that when something is defined as being an ID attribute there  
can only be one instance in the same document (not absolutely sure  
about this though)
	- an id is not an attribute in atom xml, so I am not even sure this  
would be possible anyway


Also it is quite possible that the entry fall off the end of the feed  
after a while (usually just before it gets placed into an archive).  
So the link in your first example above would be falsified a little  
too easily.


Henry Story
http://bblfish.net/

Re: todo: add language encoding information

[Henry Story]

Sorry for being away for a while. I am back on this issue. We had  
narrowed in on this quite well. It should be RFC time real soon.



On 24 Dec 2005, at 07:25, James Holderness wrote:

Henry Story wrote:

I think you have not quite grasped the point my graph was trying to
make. Perhaps I did not explain myself clearly enough. The graph
represents a feed with three entries A, B and C.
B and C share the same id. C has an updated time stamp that is after
B so C is an update of B.


If you went with my link+hreflang method, this could be handled  
with an additional date attribute in the link, where the date  
signified the time at which the translation was valid. For example:


Yes. Quite right.



 tag:eg.com,2005:/en/atom03
 x:updated="2005-11-15T18:30:02Z"/>



 tag:eg.com,2005:/fr/atom03
 2005-11-13T18:30:02Z
 


 tag:eg.com,2005:/fr/atom03
 2005-11-15T18:30:02Z
 



Presumably one would need to add an x:feed="http://mydomain.com/feed";  
attribute for translations of entries that appear in other feeds.


I've left off the obvious elements and attributes for brevity, but  
you get the idea.


yes I do.

Henry

Re: Atom2RDF via Universal Feed Parser

[Henry Story]

On 29 Jan 2006, at 16:47, Danny Ayers wrote:


fyi, Chimezie has a blog post [1] including the mapping below between
Atom as interpreted by Mark Pilgrim's UFP (so it'll also work for
anyRSS) to RDF.

[snip]


I don't quite understand what is going on in that blog post.


At some point it'll probably be a good idea to capture the mapping
from the core Atom constructs (as expressed in Atom/OWL [2]) to the
other vocabs/ontologies used - FOAF, SKOS, DC, presumably through
owl:equivalentClass/owl:equivalentProperty statements.  (APP construct
mappings to follow, when someone's got a bit of time...)


atom-owl already uses the foaf ontology for foaf:Person construct.
for DC there was some mapping someone made between DC and atom- 
constructs.


There was this wiki page:
http://www.intertwingly.net/wiki/pie/PaceEquivalents

My guess is that I could add some inheritance properties to atom-owl.  
Something like:


awol:id rdfs:subclassOf dc:identifier .

we would have to look at this case by case. Also should this be part  
of the main ontology?


Henry Story

Re: todo: add language encoding information

[Henry Story]

[ :value "Des Robot Atomiques se rebellent";
  :type "text/plain" ];
 :link [  :href <http://example.org/2003/12/13/fr/atom03>;
  :rel iana:alternate ];
 :id ;
 :updated "2003-12-13T18:30:02Z"^^xsd:dateTime;
 :summary [  :value "Apres un cours d'integration en  
philosophie francaise...";

 :type "text/plain" ]
 ext:translation <http://example.org/2003/12/13/en/ 
atom03.atom> .

-8<---


Does that cover all cases?

(I may be a little less quick to respond in the next few days, though  
I'll try my best to keep up on this :-)


Henry



- James

Henry Story wrote:
Yes. That is one solution. But what we are looking for is how one  
can state that two entries in the same feed are translations of  
one another.

Henry
On 22 Dec 2005, at 20:52, James M Snell wrote:


Hmmm.. interesting thought, hadn't considered that.

rel="self" should always point to *this* document, and never to  
some other document, but if the document referenced is the same  
document just in a different language, then it is possible?  Good  
thinking but I'm not sure if it's legal according to the spec.


 
   ...
   http://.../thefeed?lang=fr";
   http://.../thefeed?lang=de";
   
 tag:example.org,2005:some_entry
 ...
   
 

- James

A. Pagaltzis wrote:

* James M Snell <[EMAIL PROTECTED]> [2005-12-22 19:30]:

To indicate that the feeds were translations of one another, a
new  "translation" link rel could be established on the feed
level


  ...
  http://.../thefeed?lang=fr";
  
tag:example.org,2005:some_entry
...
  



  ...
  http://.../thefeed?lang=de";
  
tag:example.org,2005:some_entry
...
  


Is that even necessary? Wouldn’t @rel='self' already work here?
Regards,

Re: [Fwd: Re: todo: add language encoding information]

[Henry Story]

Yes. That is one solution. But what we are looking for is how one can  
state that two entries in the same feed are translations of one another.


Henry

On 22 Dec 2005, at 20:52, James M Snell wrote:



Hmmm.. interesting thought, hadn't considered that.

rel="self" should always point to *this* document, and never to  
some other document, but if the document referenced is the same  
document just in a different language, then it is possible?  Good  
thinking but I'm not sure if it's legal according to the spec.


 
   ...
   http://.../thefeed?lang=fr";
   http://.../thefeed?lang=de";
   
 tag:example.org,2005:some_entry
 ...
   
 

- James

A. Pagaltzis wrote:

* James M Snell <[EMAIL PROTECTED]> [2005-12-22 19:30]:

To indicate that the feeds were translations of one another, a
new  "translation" link rel could be established on the feed
level


  ...
  http://.../thefeed?lang=fr";
  
tag:example.org,2005:some_entry
...
  



  ...
  http://.../thefeed?lang=de";
  
tag:example.org,2005:some_entry
...
  


Is that even necessary? Wouldn’t @rel='self' already work here?
Regards,

Re: todo: add language encoding information

[Henry Story]

I still think it would be good to be able to have to entries in one  
feed and be able to state that they are translations of one another.  
I don't think that putting them in different feeds is going to cover  
all the cases. See below.


On 22 Dec 2005, at 17:45, James M Snell wrote:
One possibility for this in Atom is to provide multiple Atom  
documents, each covering their own language.  Given that the date  
restriction only covers Atom entries within the *same* feed  
document, the following would be perfectly acceptable:



  ...
  
tag:example.org,2005:some_entry
...
  



  ...
  
tag:example.org,2005:some_entry
...
  




[note I change my mind on this half way through the thought]

Ah. I did not read your post carefully enough when posting my  
previous reply to James Holderness.
I don't in fact think this is ok. If the date restriction covers  
entries inside the same feed (which can be millions of entries long  
btw) it has to do so for some good reason. Or else why put the  
restriction in there at all? Now that atom is final, and we cannot  
change the restriction I think we had better assume it is there for a  
very good reason. That will make us all look more intelligent that  
otherwise for one.


So my best explanation is that the id at a time identifies one and  
only one entry - universally, semantically if you will. If books had  
isbn numbers that persisted over editorial changes then this would be  
equivalent to our id. By using the isbn number of a book we could  
then refer to all the transformations of that book. But it would not  
make sense perhaps to have two different books versions published at  
the same time, with the same isbn number... (no that makes  
sense?!)... by the same publisher... Oops. That looks like the feed  
has taken the role of the publisher in the analogy...


(ponders)

Ok. So that would make me change my mind. It should be possible to  
have two entries with the same id and the same updated time stamp but  
different content in two different feeds. This would suggest that the  
feed is really part of the identity of the entry (and that the motto  
"it's the entry stupid" is wrong).


To indicate that the feeds were translations of one another, a new  
"translation" link rel could be established on the feed level



  ...
  http://.../thefeed?lang=fr";
  
tag:example.org,2005:some_entry
...
  



  ...
  http://.../thefeed?lang=de";
  
tag:example.org,2005:some_entry
...
  




I still would suggest it be better to have different ids for the  
translations so that they can be put in the same feed. After all, why  
not allow that? If I am a publisher and I am publishing books, why  
could I not simultaneously publish a book and its translation? It  
should be possible then somehow to state that one entry is a  
translation of the other. Is there a way to do what I was going  
trying to state here in N3.  This is really the problem that Simon  
Phipps was looking at.




[ a :Feed, :Version;
:title [ :value "Example Feed";
 :type "text/plain" ];
:link  [ :href ;
 :rel iana:alternate ];
:updated "2003-12-13T18:30:02Z"^^xsd:dateTime;
:author [ :name "John Doe" ];
:id ;
:entry [ a :Entry;
 = _:someid1;
 :title [ :value "Atom-Powered Robots Run Amok";
  :type "text/plain" ];
 :link [  :href ;

  :rel iana:alternate ];
 :id ;
 :updated "2003-12-13T18:30:02Z"^^xsd:dateTime;
 :summary [  :value "After a course of integration in  
French philosophy,...";

 :type "text/plain" ];
 ext:translation _:someid2;
   ];
:entry [ a :Entry;
  = _:someid2;
 :title [ :value "Des Robot Atomiques se rebellent";
  :type "text/plain" ];
 :link [  :href ;

  :rel iana:alternate ];
 :id ;
 :updated "2003-12-13T18:30:02Z"^^xsd:dateTime;
 :summary [  :value "Apres un cours d'integration en  
philosophie francaise...";

 :type "text/plain" ]
 ext:translation _:someid1;
   ];
] .

Re: todo: add language encoding information

[Henry Story]

Simon makes some good practical points in the message I forwarded  
just previous to this one. But I would like to make some more  
abstract points too for those of you who are more of the Jungian  
introspective/rational character types (most of us here I guess or  
else we would be out surfing on the beach ;-)


On 22 Dec 2005, at 16:34, James Holderness wrote:

Henry Story wrote:
Does Atom allow there to be multiple parallel renditions of a  
blog  entry in different languages?


So it is not really possible to put atom entries with the same id  
and updated time stamp in a  feed (without a SHOULD level  
violation) even  if they are translation of each other. That means  
that the Swiss  would not be able to publish a law with the same  
atom id in french  and in german, as they are obliged to publish  
these at the exact same  time by law. (No linguistic preference)


The Swiss may need to publish laws in multiple languages  
simultaneously, but most users surely don't need to read those laws  
in multiple languages simultaneously. Why waste their bandwidth  
including several translations in one feed when it would be far  
more convenient if you just had a separate feed for each language?


The atom syntax has a very clear restriction which I believe is of  
semantic importance [1]. And that is as I mentioned in my original  
post that:


[[
   If multiple atom:entry elements with the same atom:id value  
appear in

   an Atom Feed Document, they represent the same entry.  Their
   atom:updated timestamps SHOULD be different.  If an Atom Feed
   Document contains multiple entries with the same atom:id, Atom
   Processors MAY choose to display all of them or some subset of them.
   One typical behavior would be to display only the entry with the
   latest atom:updated timestamp.
]] last para of section 4.1.1 of http://www.ietf.org/rfc/rfc4287

What would be the point of having this restriction if it was not of  
semantic significance? It seems a little odd to tell people that they  
cannot put two entries into a feed with the same updated time stamp,  
but that they can put them into two different feeds and all is ok.  
Why have that restricition in that case? My guess is that the  
restriction was accepted because it worked on the following  
intuition. The atom id is a string that identifies something we can  
think of as a document. It therefore does not make sense to have two  
different incompatible versions of the same document with the same  
time stamp. The atom id is therefore much more restrictive than a URL  
[2]. A URL in web architecture can have any number of different  
representations at the same time. Atom clearly rules this out. So my  
guess is that we should take this seriously. The id is identifying a  
document. And a document cannot be wholly in two languages at once.


Once we accept this, then there is no big problem. We just need the  
translations to have 2 different ids. They are after all two  
different documents. We can then put the two translations into the  
same feed, or different feeds without problem.


All we need is to find a way to state that one document is a  
translation of the other. And James Snell's proposal is a good start  
at getting us there (it is a possible translation of the N3 proposal  
in my original e-mail).


If you want to link the various translations together you can add  
one or more link elements at the top of the feed with  
rel="alternate" and hreflang set to the language of the alternate  
feed. If you're feeling really enthusiastic you can include  
alternate links pointing to the translated html pages for each  
entry too.


If my argument above is sound then we should be able to put the  
translations in the same feed. What we want to do then, is find some  
way to state that one entry in the feed is a translation of the other  
entry in the same feed. So though the solution saying that one feed  
is a translation of the other is ok (apart from it breaking what I  
think are the inherent semantics in atom) it is also too general. We  
need more precise tools.


No extensions need to be made to the Atom spec. No wasted bandwidth  
by having multiple translations in a feed that may not be used. But  
you can still publish muliple language simultaneously by making  
sure you update all feeds simultaneously. You could even publish  
all the feeds at the same URL, serving the correct translation  
based on the HTTP Accept-Language header.


Those are cool ideas. But again, it would be good to have a way to  
specify that an entry in one feed is a translation of a particular  
different entry in the other feed.




I may be missing something here, but it seems to me like a  
reasonable solution to the problem.




Those were my first thoughts too btw. And also Retos. :-)


Regards
James


I hope this type of argument also helps show how the semantics we are  
working on at the atom-owl group can help reveal hid

Re: todo: add language encoding information

[Henry Story]

Simon is not a member of the atom-syntax list. I imagine his response  
will get through atom syntax moderation at some point, though as we  
are in holiday season, I imagine this could take some time.


I have also changed the policy on [EMAIL PROTECTED] to allow  
posts by non members, forcing them through a moderation stage. This  
option was not available on google groups when I started the group.  
So you non members can cc that group hapily now. :-)


Henry

On 22 Dec 2005, at 18:44, Simon Phipps wrote:



On Dec 22, 2005, at 15:34, James Holderness wrote:


Henry Story wrote:
Does Atom allow there to be multiple parallel renditions of a  
blog  entry in different languages?


So it is not really possible to put atom entries with the same id  
and updated time stamp in a  feed (without a SHOULD level  
violation) even  if they are translation of each other. That  
means that the Swiss  would not be able to publish a law with the  
same atom id in french  and in german, as they are obliged to  
publish these at the exact same  time by law. (No linguistic  
preference)


The Swiss may need to publish laws in multiple languages  
simultaneously, but most users surely don't need to read those  
laws in multiple languages simultaneously. Why waste their  
bandwidth including several translations in one feed when it would  
be far more convenient if you just had a separate feed for each  
language?


You're making a couple of dodgy assumptions here:

* You're assuming Atom is just used by an end-user here. Atom feeds  
can also be used to pass data between servers, for backup, or for  
content transfer. Structuring multilingual data as multiple feeds  
without including cross-relationships with the data involves loss  
of meta-data.


* You're assuming multiple languages are always present. When I  
blog, I have some entries translated for me because they relate to  
local issues in a country I am visiting. I won't be making a  
permanent pt-br feed when I visit Brazil, but I may well want the  
translated blog entry to be made available in the syndication feed.


It may well be appropriate to have multiple feeds in the case Henry  
cites where there is a stable set of translations, but the more  
general case merits serious consideration. James Snell has an  
interesting proposal that addresses the issue directly with minimal  
change.


S.

Re: todo: add language encoding information

[Henry Story]

Sorry again to take so long to respond. I have been a little too busy  
to respond recently.


On 4 Dec 2005, at 16:42, Simon Phipps wrote:

On Dec 4, 2005, at 14:33, Henry Story wrote:

I have written my first blog entry in French [1] which has made me  
aware that
it would be very useful to add language information to the atom  
file generated by

BlogEd. A menu beneath the Entry icon would probably do the trick.

Henry

[1] http://bblfish.net/blog/page9.html#t2005_12_04.14_17_02_642


Does Atom allow there to be multiple parallel renditions of a blog  
entry in different languages? I've been discussing with Dave  
Johnson how we might provide a facility in Roller where a blog  
entry might be provided in multiple languages and then select the  
appropriate entry based on the contents of the HTTP GET. If this  
were to be implemented, we'd need a way to express the same reality  
in the Atom feed.


This is a complicated and delicate issue. An atom entry has been  
syntactically limited by the atom spec by the following clause


[[
   If multiple atom:entry elements with the same atom:id value  
appear in

   an Atom Feed Document, they represent the same entry.  Their
   atom:updated timestamps SHOULD be different.  If an Atom Feed
   Document contains multiple entries with the same atom:id, Atom
   Processors MAY choose to display all of them or some subset of them.
   One typical behavior would be to display only the entry with the
   latest atom:updated timestamp.
]] last para of section 4.1.1 of http://www.ietf.org/rfc/rfc4287

So it is not really possible to put atom entries with the same id and  
updated time stamp in a  feed (without a SHOULD level violation) even  
if they are translation of each other. That means that the Swiss  
would not be able to publish a law with the same atom id in french  
and in german, as they are obliged to publish these at the exact same  
time by law. (No linguistic preference)


If we want to respect this we have to give different translations of  
a document different ids. We should be able to specify that they are  
translations of each other some other way. Using the Atom OWL  
ontology [1] we could do this by adding some translation relation  
between the entries. Once this the best way to do this is settled and  
that it satisfies our needs it should be possible to put a proposal  
to the atom syntax group for an extension to their xml format.


So perhaps something like this is needed

[ a :Feed, :Version;

:title [ :value "Example Feed";
 :type "text/plain" ];
:link  [ :href <http://example.org/>;
 :rel iana:alternate ];
:updated "2003-12-13T18:30:02Z"^^xsd:dateTime;
:author [ :name "John Doe" ];
:id ;

:entry [ a :Entry;
 :title [ :value "Atom-Powered Robots Run Amok";
  :type "text/plain" ];
 :link [  :href <http://example.org/2003/12/13/en/atom03>;
  :rel iana:alternate ];
 :id ;
 :updated "2003-12-13T18:30:02Z"^^xsd:dateTime;
 :summary [  :value "After a course of integration in  
French philosophy,...";

 :type "text/plain" ];

 ext:translation 

   ];

:entry [ a :Entry;
 :title [ :value "Des Robot Atomiques se rebellent";
  :type "text/plain" ];
 :link [  :href <http://example.org/2003/12/13/fr/atom03>;
  :rel iana:alternate ];
 :id ;
 :updated "2003-12-13T18:30:02Z"^^xsd:dateTime;
 :summary [  :value "Apres un cours d'integration en  
philosophie francaise...";

 :type "text/plain" ]


 ext:translation 

   ];
] .


The ext:translation relation above relates a :Entry to an :EntryId  
which is to say that it cannot distinguish between one version of an  
entry and another. So we would either be saying that each version of  
one entry is always going to be a translation of the other, or that  
there is some version of the other entry that is a translation of  
this one (which is a little too vague for comfort).


We could be more precise by giving each entry version its unique id,  
in which case we could say that this particular entry is a  
translation of that particular entry, which would be more precise and  
satisfactory. In N3:



[ a :Feed, :Version;

:title [ :value "Example Feed";
 :type "text/plain" ];
:link  [ :href <http://example.org/>;
 :rel iana:alternate ];
:updated "2003-12-13T18:30:02Z"^^xsd:dateTime;
:author [ :name "John Doe" ];
:id ;

:entry [ a :Entry;

 = _:someid1;


 :title [ :value "Atom-Powered Rob

Re: Atom, files and directories: what it's all about

[Henry Story]

Thanks Uche for making me think a little more carefully about this  
topic. Your intervention has been very helpful in identifying a  
concern that is probably more widespread than openly acknowledged.


On 1 Dec 2005, at 21:20, Uche Ogbuji wrote:


Hmm.  I worry about such a land grab.  I'd rather put muscle behind
WebDAV and be sure that Atom dovetails.  I think that the  
similarities

should be used to ensure such dovetailing, rather than to seed a
competition between Atom and DAV.


I don't think this need be thought of as a landgrab.


It needn't be, of course, but I think your characterization so far  
gave

the impression that it could be.  Nevertheless, I think I'll leave off
this thread.  After all, it's all vapor so far, and so no real  
problem.

If people do start coming up with WebDAV-replacement ideas, and
seriously advocating them, I can take up the cause then.  Until then,
it's all academic.


Seeing something as something else is a very important aspect of  
learning. This reminds me of various mathematical puzzles one learns  
in school. It is a long time since I studied geometry but I can  
remember the importance of seeing a shape as the sum of two others.  
Was it by these means that the Greeks prooved the irrationality of  
the square root of 2? [1] I can't remember. But there are many other  
examples along these lines, I am sure. These questions may be  
academic, but one should not disparage academia. It is from those  
quarters that some of the greatest changes in the human condition of  
stemmed from.


I will say while ducking through the door (sorry) that I don't  
think the

distinction between "simple file system" and "metadata file system" is
all that instructive, but again I'll have to take up that matter if it
comes up again in a more practical context.


If the only practical effect this discussion may have is help people  
think about feeds a little differently, something will have been  
achieved.


Thanks again for participating,

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

[1] http://en.wikipedia.org/wiki/Irrational_numbers#Another_proof

Re: Atom, files and directories: what it's all about

[Henry Story]

On 1 Dec 2005, at 17:50, Uche Ogbuji wrote:

On Tue, 2005-11-29 at 10:25 +0100, Henry Story wrote:

On 29 Nov 2005, at 00:31, Luke Arno wrote:

On 11/28/05, Ernest Prabhakar <[EMAIL PROTECTED]> wrote:


Hi Henry,

On Nov 23, 2005, at 3:22 AM, Henry Story wrote:

A few improvements of atom over directories is that our feed can
contain not just the current version of an entry, but all previous
versions as well, which I think I remember was a feature supported
by the vms file system.


Interesting.  It reminds me of a thought I had a while ago:   
would it

be possible to emulate 80% of WebDAV by using HTTP + Atom?



I think that is very much the idea. If you check what is going on on
the atom protocol group you will find that they are moving in that
direction

http://bitworking.org/projects/atom/


Hmm.  I worry about such a land grab.  I'd rather put muscle behind
WebDAV and be sure that Atom dovetails.  I think that the similarities
should be used to ensure such dovetailing, rather than to seed a
competition between Atom and DAV.


I don't think this need be thought of as a landgrab.

For one it is probably a consequence of atom trying to do the  
simplest thing possible. When you think about it, a file system or  
directory hierarchy is probably one of the simplest things around. It  
is not surprising that if you think about content and publishing  
content you end up with something that is very very similar to what  
we had before.


Secondly Atom is already finished. It can hardly be claimed that atom  
(and all the RSS formats before it) tried to grab hold of something  
unintentionally. 'Grabbing' involves a conscious act, an intention.  
If you think of Atom as a mathematical structure which in some sense  
it is (if you follow some of the work of the atom-owl group) then you  
are closer to understanding the type of grabbing that is happening  
here. It is just simply that there is a strong isomorphism between  
these two structures [1]. You and me are very similar. We are both  
human. And there is an isomorphism there too. But I never intended to  
grab you :-)


Mentioning WebDav further reinforces the parallel with file systems  
now that I think of it. If you look at the parallel between atom and  
WebDav, and compare this with the parallel between a plain unix file  
system and a metadata enabled one, we have a very illuminating  
parallel. A plain file system is the simplest thing around pretty  
much and as a result it is the most wide spread type of file system.  
Atom and RSS follow a similar pattern. They are much more widely  
available than WebDav implementations. WebDav on the other hand is  
really very similar to the metadata enabled file systems such as the  
one shipped with Apple's Tiger [2]. In WebDav you ask the file  
directly for its properties using PROPGET; in Tiger you do that using  
tools such as xattr.


% xattr --set name John file
% xattr --set color red file

% xattr --list file
file
color   red
 name   John

So with this paralell in mind

Simple File System  / Atom
Metadata File System / WebDav

it becomes possible to further see how there is no landgrab happening  
at all. Notice that both normal file systems and metadata file  
systems can coexist quite peacefully. In fact OSX allows you to copy  
a file with metadata to a non metadata enabled file system without  
trouble and without loosing your metadata. Furthermore I imagine it  
would be quite possible to publish atom files to WEBDAV systems.


Certainly it would be interesting to look into these parallels further.


Henry Story

[1] http://en.wikipedia.org/wiki/Isomorphism
[2] http://arstechnica.com/reviews/os/macosx-10.4.ars/7

Re: Atom, files and directories: what it's all about

[Henry Story]

On 29 Nov 2005, at 00:31, Luke Arno wrote:


On 11/28/05, Ernest Prabhakar <[EMAIL PROTECTED]> wrote:


Hi Henry,

On Nov 23, 2005, at 3:22 AM, Henry Story wrote:

A few improvements of atom over directories is that our feed can
contain not just the current version of an entry, but all previous
versions as well, which I think I remember was a feature supported
by the vms file system.


Interesting.  It reminds me of a thought I had a while ago:  would it
be possible to emulate 80% of WebDAV by using HTTP + Atom?



I think that is very much the idea. If you check what is going on on  
the atom protocol group you will find that they are moving in that  
direction


http://bitworking.org/projects/atom/


Would we
also need some sort of list structure, a la XOXO?

http://microformats.org/wiki/xoxo



Yup, but Atom Feed _is_ a list format. :-)


Mhh. An Atom feed is a *Set* of entries. Not a list of entries.
The entries are not ordered in any particular way in a feed. That is  
stated in the spec section 4.1.1


[[
This specification assigns no significance to the order of atom:entry  
elements within the feed.

]]

In this sense it is again like the files in a directory. You can sort  
them different ways using options to the ls command, or if you have a  
graphical browser by clicking the different columns, but there is no  
objectively better order than another.


In html one could perhaps represent them as un unordered list, which  
is perhaps what the xoxo people intend.




You should check out some of the recent introspection
discussion that went on over on Atom Pub.

- Luke

- Luke

Atom, files and directories: what it's all about

[Henry Story]

I suppose I am kind of slow in some ways. Perhaps everyone has  
realized this all along. But the relation between atom and a file  
system has just struck me forcefully recently.


REST does not have the notion of a directory hierarchy. You may think  
it does because urls have slashes in them, and because you can browse  
the file system in a web browser. But really you are just lucky that  
most people use hierarchical file systems to construct their urls.  
The pages you get back if you point your browser to something like  
http://bblfish.net/bloged/ is an html human readable representation  
of the contents of a directory.


What is a feed? It is a machine readable representation of the  
RESTful equivalent of a directory.


What is an entry? It is the machine readable representation of the  
RESTful equivalent of a file.


Directories contain files. Feeds contain entries. Files contain  
'content'. Entries contain content too. When you type 'ls -ali' in a  
directory


bash-2.03$ ls -ali
total 61
2705932 drwxr-xr-x   3 hjs  vuser512 Nov 22 16:10 ./
2662433 drwxr-xr-x  34 hjs  vuser   1024 Nov 22 16:10 ../
2705933 -rw-r--r--   1 hjs  vuser   2059 Nov 22 16:10 BlogEd.jnlp
2705934 -rw-r--r--   1 hjs  vuser  49674 Nov 22 16:10 BlogEd.tiff
2705935 drwxr-xr-x   2 hjs  vuser   1024 Nov 22 16:10 lib/

you get all kinds of metadata about the directory '.', and about the  
files in the directory. The first number is the inode, which is a  
little like the  src url of the content.


Same when you look at a basic feed


http://www.w3.org/2005/Atom";>

  Example Feed
  http://example.org/"/>
  2003-12-13T18:30:02Z
  
John Doe
  
  urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6

  
Atom-Powered Robots Run Amok in France
http://example.org/2003/12/13/atom03"/>
urn:uuid:1225c695-cfb8-4ebb--80da344efa6a
2005-11-13T18:30:02Z
Some text.
type="xhtml" xml:lang="en"
 xml:base="http://diveintomark.org/";>
  http://www.w3.org/1999/xhtml";>
After a crash course in french cultural  
integration...

  

  




The information is just presented differently. The xml makes it  
easier for machines to parse the content, as it deals with all the  
problems of unicode and separation of the data. Yes you can use sed  
and grep in unix, but you always will come across weird corner cases,  
such as when a file has a blank space in it, non ascii weird  
characters, ...


Entries and Feeds are therefore both containers. In Unix we have  
known this all along: everything is a file. It is just that  
Directories are special kinds of files, that contain files  
themselves. So, as I have argued for a long time, Feeds are really  
types of Entries.


Feeds can have images (icons) associated with them. In most end user  
file systems, so can folders. The atom group is working on adding the  
ability to add icons and images to entries too, then the symmetry  
will be complete.


Entries are really containers for file metadata. As OSX is slowly  
moving to enabling file system metadata [1],


% xattr --set name John file
% xattr --set color red file

% xattr --list file
file
color   red
 name   John


so using the link relation one can add all types of metadata on feeds  
or entries


 
Atom draft-07 snapshot
http://example.org/2005/04/02/atom"/>
http://example.org/audio/ph34r_my_podcast.mp3"/>
tag:example.org,2003:3.2397
...
  

The attribute value of the rel relation is in fact a url, as befits a  
web document text, and people can add whatever metadata they like there.


By adding a "feed" link relation one allows feeds to point to feeds,  
which is the equivalent of directories inside directories.


A few improvements of atom over directories is that our feed can  
contain not just the current version of an entry, but all previous  
versions as well, which I think I remember was a feature supported by  
the vms file system.


Of course the URI id construct and the fact that the web does not  
have partitions, allows one to keep track of the identity of a file  
over the whole web, which simple inodes just cannot do.


Henry Story

[1] http://arstechnica.com/reviews/os/macosx-10.4.ars/7

Re: What is this entry about?

[Henry Story]

Just thought I'd mention that there is of course nothing
in  rdf that can stop anyone giving things names. So that
the blank node could be given a name such as


 a :Entry;
 :title [ :value "Atom-Powered Robots Run Amok";
  :type "text/plain" ];
 :link [  :href <http://example.org/2003/12/13/atom03>;
  :rel iana:alternate ];
 :id ;
 :updated "2003-12-13T18:30:02Z"^^xsd:dateTime;
 :summary [  :value "some text";
 :type "text/plain" ].


And so I suppose you could treat

 as an Entry itself,
give it a title, a link, an id, etc

I am not sure this makes sense. I have formalised this doubt
in the Atom-OWL ontology by the following statement:

:Version   a owl:Class;
 rdfs:comment "Metadata about the state of  a resource with  
given :id at an :updated time."@en;

 rdfs:subClassOf [ owl:complementOf :Id ].


Since :Entry and :Feed are subclasses of :Version, that means that
Entries or feeds cannot be ids. Perhaps that is too harsh.


Henry Story


On 12 Nov 2005, at 12:48, Henry Story wrote:



The way we got around this in Atom/OWL is to make the entry itself a
blank node, with atom:id being a property of it. The unique
identification of the entry node being provided by the combination of
the id, updated (and some other stuff - multiple language support  
is a

complication).


Yes.  The correct way to model it is therefore

[] a :Entry;
 :title [ :value "Atom-Powered Robots Run Amok";
  :type "text/plain" ];
 :link [  :href <http://example.org/2003/12/13/atom03>;
  :rel iana:alternate ];
 :id ;
 :updated "2003-12-13T18:30:02Z"^^xsd:dateTime;
 :summary [  :value "some text";
 :type "text/plain" ].


ie, as Danny says, to apply the :title, :link, etc relations to a  
blank node
of type :Entry. By defining :id as functional we allow different  
blank node
:Entry s to have the same id, and so the contradiction we had  
before no

longer exists.

This is not so complicated really, it is just easy to be mislead by  
the 'id' word
and think that it must be a strong identity relation, rather than a  
weaker one.
(ie, to think that the relation is not just functional, but also  
inverse functional

symmetric and transitive)

Re: What is this entry about?

[Henry Story]

On 12 Nov 2005, at 10:26, Danny Ayers wrote:

[snipped a very good conversation]

(I've cc'ed the atom-owl list, this is certainly in scope over there).

I think Bill's right about the direction being the issue, and has
probably got the right answer with adding another property to the
entryURI, but there's a fair bit of devil in the detail.

There's a slight mismatch between Atom's id and resource
identification in the RDF sense (Henry, you've looked at this hardest
- please correct me if I'm wrong). Entries can appear with different
values but the same id, e.g.
[[
If multiple atom:entry elements with the same atom:id value appear in
   an Atom Feed Document, they represent the same entry.  Their atom:
   updated timestamps SHOULD be different.
]] 4.1.1

So if  atom:id is treated as the entry resource URI then in a literal
RDF interpretation of the Atom spec you either end up with information
loss, older versions of the entry ceasing to exist (which doesn't
really work with either Atom or the RDF model) or contradictions, e.g.
more than one content value for an entry when the properties of the
resources are lined up together.


yes. Very well explained. I'll just fill out the details again below,
for those who may be new to this [1]. If you take the example


   Atom-Powered Robots Run Amok
   http://example.org/2003/12/13/atom03"/>
   urn:uuid:1225c695-cfb8-4ebb--80da344efa6a
   2003-12-13T18:30:02Z
   Some text.


you DON't want to model it as:


   :title "Atom-Powered Robots Run Amok"^^xsd:string;
   :updated  "2003-12-13T18:30:02Z"^^xsd:date .

because if a feed contained a correction of the above entry say


   Atom-Powered Robots Run Amok in France
   http://example.org/2003/12/13/atom03"/>
   urn:uuid:1225c695-cfb8-4ebb--80da344efa6a
   2005-12-13T18:30:02Z
   Some updated text.


then you would have


   :title "Atom-Powered Robots Run Amok in France"^^xsd:string;
   :updated  "2005-12-13T18:30:02Z"^^xsd:date .


And so by smushing the graph you would end up with something that was  
not

very useful such as


   :title "Atom-Powered Robots Run Amok"^^xsd:string;
   :title "Atom-Powered Robots Run Amok in France"^^xsd:string;
   :updated  "2003-12-13T18:30:02Z"^^xsd:date .
   :updated  "2005-12-13T18:30:02Z"^^xsd:date .

And you would no longer know which title belonged with which updated  
time

stamp.


The way we got around this in Atom/OWL is to make the entry itself a
blank node, with atom:id being a property of it. The unique
identification of the entry node being provided by the combination of
the id, updated (and some other stuff - multiple language support is a
complication).


Yes.  The correct way to model it is therefore

[] a :Entry;
 :title [ :value "Atom-Powered Robots Run Amok";
  :type "text/plain" ];
 :link [  :href ;
  :rel iana:alternate ];
 :id ;
 :updated "2003-12-13T18:30:02Z"^^xsd:dateTime;
 :summary [  :value "some text";
 :type "text/plain" ].


ie, as Danny says, to apply the :title, :link, etc relations to a  
blank node
of type :Entry. By defining :id as functional we allow different  
blank node

:Entry s to have the same id, and so the contradiction we had before no
longer exists.

This is not so complicated really, it is just easy to be mislead by  
the 'id' word
and think that it must be a strong identity relation, rather than a  
weaker one.
(ie, to think that the relation is not just functional, but also  
inverse functional

symmetric and transitive)


This seems to work pretty well for most purposes - an
application could either take the "forget older entry versions"
processing model, or accumulate all the versions.


yes.


But when it comes to
saying what the entry in about, I think you'd almost certainly expect
all *versions* of an entry to be about the same thing, so the subject
of the statement would be the id URI. This is easy enough in RDF (the
id is a resource), but it's not obvious how this migght be expressed
in Atom syntax.


For a long time I wanted to put properties on the id when I felt they
were necessary properties of the thing. The problem as James Gosling
reminded me [2] is that defining essential properties of things can
be quite tricky. And I suppose that many a document that started about
one thing ended up being about something quite different.

So I would tend initially towards conservatism, and not put any property
on the id. One could of course invent/discover such a property  
say :idabout

that would have the following rule associated with it

{ ?id :idabout ?obj .
  ?entry :id ?id . } => { ?entry :about ?obj . }

So the relation exists. It is just that it is very powerful relation,  
with
a lot of consequences that the user may not fully appreciate.  
Furthermore
it is not possible to write this relation out in atom syntax ea

Re: Is Atom Broken?

[Henry Story]

Well it clearly should be able to be generated someplace other than  
the server.
That was one major point of having ids: to be able to allow entries  
to be moved
from one server to another whilst allowing them to keep the same id.  
In order
for that to work the server needs to accept the id given to it by the  
client.



Henry

On 1 Nov 2005, at 15:20, Joe Gregorio wrote:


On 10/31/05, Luke Arno <[EMAIL PROTECTED]> wrote:

That is a tall order and I think it requires some
discussion as to how. :-)

I would like to start with atom:id.

Should it be generated client side?

Re: FYI: hAtom

[Henry Story]

e 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

semantics

[Henry Story]

Hi,

the AtomOWL group has released what I believe is a very good candidate
for an official semantics for the atom syntax. We have striven to keep
as close as possible to the syntax without trying to impose an RDF
interpretation onto XML. To see what I mean it is best to look at an  
example.

Here is the second example of the syntax document in N3:

8<--
   @prefix :   <http://www.w3.org/2005/10/23/Atom#> .
   @prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
   @prefix iana:   <http://www.iana.org/assignments/relation/> .
   @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .


   <> rdfs:comment "The simplest transformation from the atom-syntax  
to atom-owl of the second, longer example in atom11."@en .


[ a :Feed, :Version;

:title [ :value "dive into mark";
 :type "text/plain" ];
:subtitle [ :value "A <em>lot</em> of effort went  
into making this effortless";

:type "text/html" ];
:updated "2005-07-31T12:29:29Z"^^xsd:dateTime;
:link  [ :href [ = <http://example.org/>;
 :representation [ :type "text/html";
   :lang "en" ]
   ];
 :rel iana:alternate
  ];
:link [ :href [ = <http://example.org/feed.atom>;
:representation [ :type "application/atom+xml" ]
  ];
:rel iana:self
  ];
:rights "Copyright (c) 2003, Mark Pilgrim";
:generator [ :uri <http://www.example.com/>;
 :version  "1.0";
 :name "Example Toolkit" ];

:entry [ a :Entry, :Version;
:title [ :string "Atom draft-07 snapshot";
 :type "text/plain" ];
:link  [ :href [ = <http://example.org/2005/04/02/atom>;
 :representation [ :type "text/html"]
   ];
 :rel iana:alternate
   ];
:link  [ :href [ = <http://example.org/audio/ 
ph34r_my_podcast.mp3>;

:representation [ :type "audio/mpeg";
  :length "1337"^^xsd:integer ]
   ];
 :rel iana:enclosure
   ];
:id ;
:updated "2005-07-31T12:29:29Z"^^xsd:dateTime;
:published "2003-12-13T08:29:29-04:00"^^xsd:dateTime;
:author [ a :Person;
  :name "Mark Pilgrim";
  :uri  <http://example.org/>;
  :email <mailto:[EMAIL PROTECTED]> ];
:contributor [ :name "Sam Ruby" ];
:contributor [ :name "Joe Gregorio" ];
:content [ :value "[Update: The Atom draft is finished.]";

   :type "text/html" ];
]
] .
8<--


For more information please look at the Ontology at:
http://bblfish.net/work/atom-owl/2005-10-23/

I would like to get this to be a basis for working towards an official
sanctioned ontology for Atom. Please help us move towards this goal
by joining us on the atom-owl mailing list

http://groups.google.com/group/atom-owl/


Henry Story

with help from Danny Ayers and Reto Bachmann-Gmür
and many others.
see http://blogs.sun.com/roller/page/bblfish/20051023

Re: icon and logo on entry

[Henry Story]

Oh I think I get it now. You want to specify the logo and icon of a  
resource

on the other side of a link.


So generalizing the suggestion:

   
   Atom-Powered Robots Run Amok
   
   
   http://example.org/2003/12/13/atom03";>
 http://example.org/2003/12/13/ 
atom03-large.jpeg"/>
 http://example.org/2003/12/13/ 
atom03-small.jpeg"/>

   
   urn:uuid:1225c695-cfb8-4ebb--80da344efa6a
   2003-12-13T18:30:02Z
   Some text.
   

Makes sense to me.


Henry
http://blogs.sun.com/roller/page/bblfish/

On 25 Oct 2005, at 22:23, Henry Story wrote:




On 25 Oct 2005, at 22:08, James M Snell wrote:




I've been wanting to do the same thing for link elements.



Nice :-)



Let's propose a single solution:


 {url}
 {url}
 
   {url}
   {url}
 




Is the above a single solution, or two solutions? I can't quite  
tell the

difference.

Would they (it?) be equivalent to the following:


   Atom-Powered Robots Run Amok
   
   
   http://example.org/2003/12/13/atom03"/>
   urn:uuid:1225c695-cfb8-4ebb--80da344efa6a
   2003-12-13T18:30:02Z
   Some text.
 

I would think the media type is very much optional here.



Both elements should follow the exact same rules as the existing  
atom:logo and atom:icon elements.




Do you mean rules, or do you mean semantics? (ie: we just copy and  
paste the text

from the atom syntax doc, replacing feed with entry)



Henry




- James

Henry Story wrote:





I'd like to propose an extension that would allow something very  
much  like
icon and logo to be added to an entry, the way it currently is   
allowed on a feed.
I have been publishing entries like this for over a year now [1],  
and  so has
James Gosling [2], and other users of BlogEd. It would be really  
nice  to keep

this semantic information in the feed somehow.

Perhaps something like:

http://www.w3.org/2005/Atom";>

 Example Feed
 http://example.org/"/>
 2003-12-13T18:30:02Z
 
   John Doe
 
 urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6
 ./Image1-large.jpeg
 ./Image1-small.jpeg
 
   Atom-Powered Robots Run Amok
   ./Image5-large.jpeg
   ./Image5-small.jpeg
   http://example.org/2003/12/13/atom03"/>
   urn:uuid:1225c695-cfb8-4ebb--80da344efa6a
   2003-12-13T18:30:02Z
   Some text.
 


Though from what I have said in other posts about relative uris in
extension elements I suppose it would be better to have a new  
link type.


Any ideas?

Henry

[1] http://bblfish.net/blog/
http://blogs.sun.com/roller/page/bblfish/
[2] http://blogs.sun.com/roller/page/jag/

Re: icon and logo on entry

[Henry Story]

On 25 Oct 2005, at 22:08, James M Snell wrote:



I've been wanting to do the same thing for link elements.


Nice :-)


Let's propose a single solution:


 {url}
 {url}
 
   {url}
   {url}
 



Is the above a single solution, or two solutions? I can't quite tell the
difference.

Would they (it?) be equivalent to the following:


   Atom-Powered Robots Run Amok
   
   
   http://example.org/2003/12/13/atom03"/>
   urn:uuid:1225c695-cfb8-4ebb--80da344efa6a
   2003-12-13T18:30:02Z
   Some text.
 

I would think the media type is very much optional here.


Both elements should follow the exact same rules as the existing  
atom:logo and atom:icon elements.


Do you mean rules, or do you mean semantics? (ie: we just copy and  
paste the text

from the atom syntax doc, replacing feed with entry)



Henry



- James

Henry Story wrote:




I'd like to propose an extension that would allow something very  
much  like
icon and logo to be added to an entry, the way it currently is   
allowed on a feed.
I have been publishing entries like this for over a year now [1],  
and  so has
James Gosling [2], and other users of BlogEd. It would be really  
nice  to keep

this semantic information in the feed somehow.

Perhaps something like:

http://www.w3.org/2005/Atom";>

 Example Feed
 http://example.org/"/>
 2003-12-13T18:30:02Z
 
   John Doe
 
 urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6
 ./Image1-large.jpeg
 ./Image1-small.jpeg
 
   Atom-Powered Robots Run Amok
   ./Image5-large.jpeg
   ./Image5-small.jpeg
   http://example.org/2003/12/13/atom03"/>
   urn:uuid:1225c695-cfb8-4ebb--80da344efa6a
   2003-12-13T18:30:02Z
   Some text.
 


Though from what I have said in other posts about relative uris in
extension elements I suppose it would be better to have a new link  
type.


Any ideas?

Henry

[1] http://bblfish.net/blog/
http://blogs.sun.com/roller/page/bblfish/
[2] http://blogs.sun.com/roller/page/jag/

icon and logo on entry

[Henry Story]

I'd like to propose an extension that would allow something very much  
like
icon and logo to be added to an entry, the way it currently is  
allowed on a feed.
I have been publishing entries like this for over a year now [1], and  
so has
James Gosling [2], and other users of BlogEd. It would be really nice  
to keep

this semantic information in the feed somehow.

Perhaps something like:

http://www.w3.org/2005/Atom";>

 Example Feed
 http://example.org/"/>
 2003-12-13T18:30:02Z
 
   John Doe
 
 urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6
 ./Image1-large.jpeg
 ./Image1-small.jpeg
 
   Atom-Powered Robots Run Amok
   ./Image5-large.jpeg
   ./Image5-small.jpeg
   http://example.org/2003/12/13/atom03"/>
   urn:uuid:1225c695-cfb8-4ebb--80da344efa6a
   2003-12-13T18:30:02Z
   Some text.
 


Though from what I have said in other posts about relative uris in
extension elements I suppose it would be better to have a new link type.

Any ideas?

Henry

[1] http://bblfish.net/blog/
http://blogs.sun.com/roller/page/bblfish/
[2] http://blogs.sun.com/roller/page/jag/

Re: Sponsored Links and other link extensions

[Henry Story]

On 24 Oct 2005, at 22:59, A. Pagaltzis wrote:



* Antone Roundy <[EMAIL PROTECTED]> [2005-10-24 22:35]:


Interesting. Filling an attribute with a list of URIs doesn't
really appeal to me though.


+100 (me and all my co-voting cats)


How about this:

http://example.com/
file.mp3" xml:id="x-file">
http://www2.example.com/file.mp3"; />
http://www3.example.com/file.mp3"; />




It’s a lot more verbose and you have to fiddle with nesting.

What do you get in return? “It looks more XMLish”?



yes!? We are using xml!





Sounds good, but you may have noticed above that I used a
prefix not specific to enclosures--there's no reason to tie
this all to one particular type of link (nor to make it look
as if it were tied to one specific link type). So the other
link might, for example, be:



I don’t know if striving for generality in this fashion without
a practical need is worthwhile. It smells of architecture
astronautics for a reason I can’t particularly pinpoint. So maybe
my instinct is wrong.



maybe :-)
A million cats can't be wrong.





Note that I changed "alternative-to" to "primary" just because
it's shorter and one word.



Works for me.

Regards,
--
Aristotle Pagaltzis // 

Re: New Link Relations -- Last Call

[Henry Story]

I agree "self" would do well. But it is true that it's current  
definition
is a little vague. I don't suppose one can refine it in a way  
consistent with its current definition?


In any case this all looks good to me. As soon as we agree on the  
names, I will
implement these links in BlogEd, so that the web server can keep a  
complete history of
published changes. What would I need to add to my feed to make it  
clear that I my

feed is incremental (I think that's what my feed would be)?

Henry

On 24 Oct 2005, at 10:37, Stefan Eissing wrote:

Am 23.10.2005 um 23:34 schrieb Mark Nottingham:


On 23/10/2005, at 1:04 PM, Peter Robinson wrote:



I prefer 'subscribe' because it better describes the meaning and
intention behind the link, but I can live with 'current' if that  
is the

consensus.



Well, Tim seemed to have a pretty strong -1 on 'subscribe',  
whereas you say you can live with 'current'. So, at this point it  
looks like 'current', unless other people come forward. I flirted  
with "recent" briefly; anybody strongly like that one?




Maybe it is clear to everyone but me...however i do not see the  
damage done by using rel="self" instead of inventing a new  
relation. Could someone bother to explain that?


I know the definition in the format spec says it points to an  
"equivalent resource", but it also says that "This is the preferred  
URI for retrieving Atom Feed Documents representing this Atom  
feed." I probably do miss something important here, but
a) "equivalent resource" says either nothing or lets you enter a  
mine field while roy t. machine guns you
b) "representing this Atom feed" requires some king of dualistic  
thinking: the whole Atom feed is composed of several Atom feed  
documents which are linked with "prev" and (maybe) "next"  
relations. "self" points to the URI for the overall feed and has  
the same value in all chained feed documents (or feed chunks as i  
would call them)


Can I convince anyone to enter the land where an Atom feed is  
composed of one or more Atom feed documents?


Cheers, Stefan

Re: New Link Relations -- Ready to go?

[Henry Story]

+1 to all too.

On Fri, 21 Oct 2005, Eric Scheid wrote:


Date: Fri, 21 Oct 2005 10:47:57 +1000
From: Eric Scheid <[EMAIL PROTECTED]>
To: Atom Syntax 
Subject: Re: New Link Relations -- Ready to go?


+1 to all

Re: Feed History -04

[Henry Story]

My laptop broke down so I am having touble following all of this thread, 
but I agree that next, prev, ...  should just suggest a linked list.

There should then be special links for hist-prev, hist-next, ... that
are in rdf terms sub-properties of prev, next, etc... On the atom-owl 
mailing list we are working on a very faithful onotology to the 
atom-syntax, that would allow this sub-property relation to be clearly 
stated. This keeps everything very nicely open, allowing many specialised

semantics of the next, prev, style to be created.

Henry

   On Mon, 17 Oct 2005, James M Snell wrote:


Date: Mon, 17 Oct 2005 12:31:38 -0700
From: James M Snell <[EMAIL PROTECTED]>
To: Robert Sayre <[EMAIL PROTECTED]>
Cc: Byrne Reese <[EMAIL PROTECTED]>,
Eric Scheid <[EMAIL PROTECTED]>,
Atom Syntax 
Subject: Re: Feed History -04


Robert Sayre wrote:


On 10/17/05, Byrne Reese <[EMAIL PROTECTED]> wrote:


"next" and "previous" are as James points out, orthogonal to ordering.
The debate as to whether the next set goes backwards or forwards in time
is not about the use of the terms "next" and "previous," it is about the
default sort order of a result set.



Fully agree. Let's use what MarkP wrote down over a year ago, and stop
debating the nature of adjacency and ordering as it relates time and
archives. Are there any technical problems with the elements in this
feed:

http://diveintomark.org/xml/2004/03/index.atom



;-) Woo hoo! Robert and I agree on something ;-)

Debating how the entries are organized is fruitless.  The Atom spec already 
states that the order of elements in the feed has no significance; trying to 
get an extension to retrofit order-significance into the feed is going to 
fail... just as I discovered with my Feed Index extension proposal.



* Next/Prev/Start/Subscribe defines a linked list of feed documents and/or 
entry documents and says absolutely nothing about the ordering of the 
entries.
* Next/Prev/Start/Subscribe should be defined in their own specification that 
is not bound to Feed History
* Feed History (if MarkN wishes it so) should normatively reference the 
Next/Prev/Start/Subscribe extension spec


I do believe that a "last" link relation would be helpful for completeness 
and I do believe the use cases are there (e.g. search results, etc) but I am 
ok with dropping that for now as it can easily be defined later once the use 
cases do become more prominent. 
Over the next week I'll see if I can draft up the spec.  I'll use what MarkP 
put together as the basis for what I write up and submit.


- James

Re: Feed History -04

[Henry Story]

I am ok with next, prev, ... but I suppose I do have a question
that is similar to Marks: how do I know in what order the results
are listed? Are they in historical order? Are these feeds grouping entries 
in alphabetical order, in inverse historical order? Perhaps in 
alphabetical order of author,...


Again next, prev, first, last deal very well with paging. how do we 
specify the order? Is this related to the query? Should there be a default order for

subscription feeds? Should the ordering information be specified in the
feed?

In rdf we could say things like

iana:historicalNext a owl:ObjectProperty;
rdfs:subPropertyOf iana:next;
rdfs:comment "a historically ordered next relation" .

and then use historicalNext for the particular historical ordering
that we need to archive our feeds. This would allow processors
who do not understand or care about the historical ordering to still
walk through the linked list of feeds.

Henry

Ps. writing from Italy 
http://dannyayers.com/archives/2005/10/15/welcome-to-the-atomowl/


On Sat, 15 Oct 2005, Mark Nottingham wrote:
OK, but that still leaves us with the question below -- who's doing the 
paging, and why is it useful to have multiple ways around the thing?



On 15/10/2005, at 7:25 PM, Eric Scheid wrote:



On 16/10/05 6:54 AM, "Mark Nottingham" <[EMAIL PROTECTED]> wrote:



Can you walk me through a use case where this would be desirable?
E.g. what would the subscription URI be, would any of the entries
be  updated, and how if so? In what scenario would having a closed
set  feed be useful?



An archive for a blog that is no longer being updated? An archive
of entries pertaining to an event with a fixed endpoint? A
discussion forum that has been closed.



How are implementations supposed to use this information? Stop
polling the feed? Consider its items immutable? I'm concerned if
something so innocent-looking as "last" has these sorts of implications.



perhaps a better example would then be a feed of search results, which at
any time of query is a finite and closed set, and also designed to be paged
through.

e.






--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

Re: Feed History -04

[Henry Story]

I am ok with next, prev, ... but I suppose I do have a question that is 
similar to Marks: how do I know in what order the results are listed? Are 
they in historical order? Are these feeds grouping entries in alphabetical 
order, in inverse historical order? Perhaps in alphabetical order of 
author,...


Again next, prev, first, last deal very well with paging. how do we 
specify the order? Is this related to the query? Should there be a default 
order for subscription feeds? Should the ordering information be specified 
in the feed?


In rdf we could say things like

iana:historicalNext a owl:ObjectProperty;
rdfs:subPropertyOf iana:next;
rdfs:comment "a historically ordered next relation" .

and then use historicalNext for the particular historical ordering that we 
need to archive our feeds. This would allow processors who do not 
understand or care about the historical ordering to still walk through the 
linked list of feeds.


Henry

Ps. writing from Italy 
http://dannyayers.com/archives/2005/10/15/welcome-to-the-atomowl/



On Sat, 15 Oct 2005, Mark Nottingham wrote:


Date: Sat, 15 Oct 2005 20:45:35 -0700
From: Mark Nottingham <[EMAIL PROTECTED]>
To: Eric Scheid <[EMAIL PROTECTED]>
Cc: Atom Syntax 
Subject: Re: Feed History -04


OK, but that still leaves us with the question below -- who's doing the 
paging, and why is it useful to have multiple ways around the thing?



On 15/10/2005, at 7:25 PM, Eric Scheid wrote:



On 16/10/05 6:54 AM, "Mark Nottingham" <[EMAIL PROTECTED]> wrote:



Can you walk me through a use case where this would be desirable?
E.g. what would the subscription URI be, would any of the entries
be  updated, and how if so? In what scenario would having a closed
set  feed be useful?



An archive for a blog that is no longer being updated? An archive
of entries pertaining to an event with a fixed endpoint? A
discussion forum that has been closed.



How are implementations supposed to use this information? Stop
polling the feed? Consider its items immutable? I'm concerned if
something so innocent-looking as "last" has these sorts of implications.



perhaps a better example would then be a feed of search results, which at
any time of query is a finite and closed set, and also designed to be paged
through.

e.






--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

Re: Feed History -04

[Henry Story]

This looks good.

Is the 'first' the feed document that changes, whereas 'next' and 'last' 
point to the archives? (in a feed history context?)


Henry

On Fri, 14 Oct 2005, James M Snell wrote:
The way I look at this is in terms of a single linked list of feeds.  The 
ordering of the entries within those feeds is irrelevant.  The individual 
linked feeds MAY be incremental (e.g. blog entries,etc) or may be complete 
(e.g. lists,etc).  Simply because a feeds are linked, no assumption should be 
made as to whether or not the entries in those feeds share any form of 
ordered relationship.




+1


 is the first feed in the linked list
 is the next feed in the linked list
 is the previous feed in the linked list
 is the last feed in the linked list.

Terms like "top", "bottom", "up", "down", etc are meaningless in this model 
as they imply an ordering of the contents.


For feed history, it would work something like:


...



...



...





...



...



...


- James

Mark Nottingham wrote:



At first I really liked this proposal, but I think that the kind of 
confusion you're concerned about is unavoidable; the terms you refer  to 
suffer "bottom-up" vs. "top-down."


I think that defining the terms well and in relation to the  subscription 
feed will help; after all, the terms don't surface in  UIs, so it should be 
transparent.



On 14/10/2005, at 10:37 AM, Antone Roundy wrote:

Which brings me back to "top", "bottom", "up" and "down".  In the 
OpenSearch case, it's clear which end the "top" results are going  to be 
found.  In the syndication feed case, the convention is to  put the most 
recent entries at the "top".  If you think of a feed  as a stack, new 
entries are stacked on "top".  The fact that these  terms are less generic 
and flexible than "previous" and "next" is  both an advantage and a 
disadvantage.  I think the question is  whether it's an advantage in a 
significant majority of cases or  not.  What orderings would those terms 
not work well for?




--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

 
BEAWorld 2005: coming to a city near you.  Everything you need for SOA and 
enterprise infrastructure success.



Register now at http://www.bea.com/4beaworld


London 11-12 Oct| Paris13-14 Oct| Prague18-19 Oct |Tokyo 25-26 Oct| Beijing 
7-8 Dec

Re: Feed History -04

[Henry Story]

It occurred to me that I should think a little more before speaking.

There seems to be a history of the atom spec here:

http://bitworking.org/projects/atom/

I could not find the prev link in any of the specs. So I guess I was  
mistaken.
But I also always thought of prev and next as being very good  
candidates for
the link element.  I never raised my voice against the move at the  
time because

I assumed most decisions on this list were good ones.

There is one reference to prev and next here:
http://www.intertwingly.net/wiki/pie/LinkTagMeaning


Henry

On 9 Oct 2005, at 10:47, Henry Story wrote:


I believe it was part of atom 0.3, and for some complex reason I never
bothered trying to understand someone decided it should be moved  
over to
the protocol side of things. Probably just because the debate was  
taking up

too much time...

So yes. 'prev' and 'next' have always been intended to be there in  
the link element...


Henry

On 9 Oct 2005, at 10:39, James Holderness wrote:



Following up on the idea of using atom:link instead of fh:prev, I  
recently came across an old article by Mark Pilgrim on XML.com  
(http://www.xml.com/pub/a/2004/06/16/dive.html) in which he  
discusses the atom:link element and the various rel attributes it  
supports. He specifically brings up the issue of feed history and  
using next and prev to link archives together.


It sounded to me as if he was talking about an existing feature in  
the spec - it wasn't like he was proposing it as a new idea. So  
was this something that used to be part of an old version of the  
spec that was later removed? Or was this an early proposal that  
was never accepted into the spec?


Also of interest: there's a link from that article to his archives  
on diveintomark.org which actually include next and prev links in  
the feed. I'm almost inclined to add support for that just so I  
can access those old posts. There used to be some excellent  
articles on his site.

Re: Feed History -04

[Henry Story]

I believe it was part of atom 0.3, and for some complex reason I never
bothered trying to understand someone decided it should be moved over to
the protocol side of things. Probably just because the debate was  
taking up

too much time...

So yes. 'prev' and 'next' have always been intended to be there in  
the link element...


Henry

On 9 Oct 2005, at 10:39, James Holderness wrote:


Following up on the idea of using atom:link instead of fh:prev, I  
recently came across an old article by Mark Pilgrim on XML.com  
(http://www.xml.com/pub/a/2004/06/16/dive.html) in which he  
discusses the atom:link element and the various rel attributes it  
supports. He specifically brings up the issue of feed history and  
using next and prev to link archives together.


It sounded to me as if he was talking about an existing feature in  
the spec - it wasn't like he was proposing it as a new idea. So was  
this something that used to be part of an old version of the spec  
that was later removed? Or was this an early proposal that was  
never accepted into the spec?


Also of interest: there's a link from that article to his archives  
on diveintomark.org which actually include next and prev links in  
the feed. I'm almost inclined to add support for that just so I can  
access those old posts. There used to be some excellent articles on  
his site.

Re: Entries in multiple language

[Henry Story]

On 28 Sep 2005, at 14:48, Reto Bachmann-Gmür wrote:


[snip lots of interesting stuff, to get to later]



Note that the first two entries share the same value of atom:updated,
this is a SHOULD-Level violation of section 4.1.1. I think the spec
should allow multiple entries with the same timestamp iff they  
differ by
language and/or content-type. In multilingual countries like  
Switzerland

it is required (as for laws) or at least a matter of political
correctness (as for press releases) for some publications to be
published at the same time in all language versions.


Why not publish content negotiated atom feeds, so that the French  
version

of the feed only contains french entries, the German version only German
entries, the Italian one only Italian ones, and the Romansh one only  
Romansh
entries? Then the user would subscribe to the feed serving the  
entries in

the language preferred by the author.

Of course since in Switzerland the German, French and Italian  
representations
of the feed have to appear simultaneously they will each contain  
entries with
identical ids and identical atom:updated time stamps. This would not  
contradict

the atom spec which mentions only that in a particular feed document two
entries with the same id should not have the same updated time stamp.  
It is
something on the other hand that an ontology of atom would have to be  
careful
about (or a database consuming atom feeds), as it would have to take  
into
account the possibility of multiple language versions of the same  
update of

an entry.


Henry Story




The following two entries are in a feed

http://www.w3.org/2005/Atom"; xml:lang="de">
Asylgesetzrevision - Aus humanitärer Sicht inakzeptabel! 


http://www.osar.ch/2005/09/27/pm_asylg-revision"/>
http://www.osar.ch/2005/09/27/pm_asylg-revision"/>
http://www.osar.ch/2005/09/27/pm_asylg-revision"/>
http://www.osar.ch/2005/09/27/pm_asylg-revision"/>
 href="http://www.osar.ch/ 
2005/09/27/050927_asylgnr_presserohstoff_"/>

http://www.osar.ch/2005/09/27/pm_asylg-revision
2005-09-27T11:00-01:00
2005-09-27T11:00-01:00

pro
http://osar.ch/aslum-rights
[EMAIL PROTECTED]

http://www.osar.ch/";>
http://www.w3.org/1999/xhtml";>
  Der Nationalrat hat heute praktisch allen  
Verschärfungsvorschlägen

des Ständerates zum Asylgesetz zugestimmt. Der verfassungswidrige
Nothilfestopp blieb chancenlos. Die SFH ist sehr enttäuscht über den
Ausgang der Beratung. Das neue Gesetz opfert den Schutz von Verfolgten
zugunsten von unverhältnismässiger Missbrauchsbekämpfung. Damit ist  
das

Referendum unausweichlich.




http://www.w3.org/2005/Atom"; xml:lang="fr">
http://www.example.com/"; version="1.0">
Example Toolkit

Revision de la loi sur l'asile - Inacceptable sur le plan
humain
http://www.osar.ch/2005/09/27/pm_asylg-revision"/>
http://www.osar.ch/2005/09/27/pm_asylg-revision"/>
http://www.osar.ch/2005/09/27/pm_asylg-revision"/>
http://www.osar.ch/2005/09/27/pm_asylg-revision"/>

 href="http://www.osar.ch/ 
2005/09/27/050927_asylgnr_presserohstoff_"/>

http://www.osar.ch/2005/09/27/pm_asylg-revision
2005-09-27T11:00-01:00
2005-09-27T11:00-01:00

pro
http://osar.ch/aslum-rights
[EMAIL PROTECTED]

http://www.osar.ch/";>
http://www.w3.org/1999/xhtml";>
  Le Conseil national a approuvé aujourd’hui pratiquement  
toutes les

aggravations proposées par le Conseil Fédéral dans le cadre de la
révision de la loi sur l’asile. L’exclusion de l’aide de première
nécessité, contraire à la Constitution, a été rejetée. L’OSAR se  
montre

profondément déçue par l’issue des débats. La nouvelle loi sacrifie la
protection des personnes persécutées sur l’autel d’un combat
disproportionné contre les abus. Le référendum apparaît dès lors
inévitable.




One hour later an important error in the french version gets fixed
(s/Conseil Fédéral/Conseil des Etats/)

http://www.w3.org/2005/Atom"; xml:lang="fr">
http://www.example.com/"; version="1.0">
Example Toolkit

Revision de la loi sur l'asile - Inacceptable sur le plan
humain
http://www.osar.ch/2005/09/27/pm_asylg-revision"/>
http://www.osar.ch/2005/09/27/pm_asylg-revision"/>
http://www.osar.ch/2005/09/27/pm_asylg-revision"/>
http://www.osar.ch/2005/09/27/pm_asylg-revision"/>

 href="http://www.osar.ch/ 
2005/09/27/050927_asylgnr_presserohstoff_"/>

http://www.osar.ch/2005/09/27/pm_asylg-revision
2005-09-27T12:00-01:00
2005-09-27T11:00-01:00

pro
http://osar.ch/aslum-rights
[

Re: ACE - Atom Common Extensions Namespace

[Henry Story]

I really like the ACE proposal, and I think the name is a good one  
too :-)


It can't harm to have this option on the table now. No one is forced  
to use it.

But I think it will have a few positive effects:

- proposals that use it will have a cool ace namespace name
- proposals that want to use the name will perhaps work a little  
harder to
  coordinate with other proposals on the table, which can't be a  
bad thing.
  Synergies between different proposals might be found thereby  
reducing the

  workload on implementors.
- The namespace will act like a stamp of approval. It will be an  
indication
  that there is some consensus behind the proposal, and that  
things will

  play nice together

This is not limiting anyone in any way. Proposals that want to use  
the dublin
core, foaf or other namespaces should have no trouble using them.  
Proposals
can also decide to use their own name space like the current feed  
history

namespace.

Henry Story

On 3 Oct 2005, at 07:15, Mark Nottingham wrote:


My .02, FWIW, and off the top of my head;

I think this is a well-intentioned effort, but at the wrong end of  
the process. The market (i.e., users and implementors) should have  
a go at sorting out at what's common/prevalent enough to merit this  
sort of thing; having a co-ordinated namespace will lead to the  
problem of what to lump into it, how to version individual  
extensions within it, etc.


And that is a problem that the end user won't to make himself all  
alone then.
Since every end user is bound to come up with his own idea of how to  
lump things together, thereby creation an explosion of private lumps,  
this should in the end

also reduce the workload on implementors.

In other words, some of the benefits of Namespaces in XML -- e.g.,  
loose coordination, well-insulated name spaces, ability to change  
namespace without changing local name to effect versioning -- will  
be lost, all for the sake of saving a few characters. Not worth it,  
IMO.


Nothing is lost. All those benefits remain, as I said above. The atom  
spec has
been designed to be open, the ace proposal will not and could not  
change that.



A much better thing would be to wait a year or two and see if  
there's a need for such a beast.


All these little proposals we have now indicates that we should work  
preventatively

and at least put the option on the table for proposers to consider.


And, the idea of an XML namespace backed by an IANA registry is a  
little bit twisted, considering the W3C and IETF's philosophies  
about these things ;)


Cheers,


On 01/10/2005, at 10:54 PM, James M Snell wrote:



As I've been going through the effort of defining a number of Atom  
extensions, I've consistently come back to the thought that it  
would be interesting to explore the creation of a "Common  
Extensions Namespace" under which multiple standardized extensions  
can be grouped.  I've written an initial draft of the concept but  
before I submit it as an Internet Draft, I'd like to get some  
feedback from the group.  Please review the attached and let me  
know what you think.


- James

Re: Feed History -04

[Henry Story]

I think this is good, but I would prefer the atom:link to be used  
instead of
the fh:prev structure, as that would better fit the atom way of doing  
things.
I also think it may be very helpful if we could agree on an extension  
name space
that all accepted extensions would use, in order to reduce name space  
clutter.


Henry


On 7 Sep 2005, at 01:18, Mark Nottingham wrote:


Feed History -04 is out, at:
  http://www.ietf.org/internet-drafts/draft-nottingham-atompub-feed- 
history-04.txt


Changes:
  - fh:stateful -> fh:incremental, with appropriate changes in text
  - more explicit cardinality information
  - implications of fh:prev being an Absolute URI spelled out
  - more explicit white space handling
  - Acknowledgements section

More information, including implementation details, at:
  http://www.mnot.net/blog/2005/09/05/feed_history

--
Mark Nottingham http://www.mnot.net/

Re: Unofficial last call on draft-snell-atompub-feed-expires-04.txt

[Henry Story]

Would it be possible to merge, or at least have the history extension  
[1] use the same
name space as your extension, so that the the history's incremental  
and archive tags
can have the same namespace, and the history fh:prev can be  
transformed to a link object, thereby:

- reducing the number of namespaces used by an atom feed
- allowing the  construct to be used by the feed  
history proposal

?

Henry Story


[1] http://www.ietf.org/internet-drafts/draft-nottingham-atompub-feed- 
history-04.txt

On 26 Sep 2005, at 17:32, James M Snell wrote:


Over the past couple of weeks I've been working on a number of  
proposed Atom extensions that I am moving forward with as standards- 
track RFC's through individual submission.


I believe that the Expiration extension -- http://www.ietf.org/ 
internet-drafts/draft-snell-atompub-feed-expires-04.txt -- is  
complete and ready for an unofficial last call.  Before I submit  
this to Scott Hollenbeck asking for it t become a standards-track  
RFC, I would like to invite the members of the WG to comment |  
praise | complain | improve | all-of-the-above.  In >= 2 weeks I'll  
make any appropriate changes and submit the draft to Scott.


Summary: introduces a mechanism for specifying a date-time or  
maximum age for the informational content of a feed or entry

Example:
  
...
2005-12-12T12:00:00Z

   ...
   2005-11-11T12:00:00Z
   2

  
  The metadata in the feed element expires at noon on Dec , 12 2005,
  The metadata in the entry element expires 2 miliseconds after  
noon on Nov, 11, 2005.


- James

Re: Structured Publishing -- Joe Reger shows the way...

[Henry Story]

Is  DOAP over Atom [1] an example of the type of solution you are  
suggesting James?
That looks good. But what if I want to annotate an entry with some  
RDF? In a recent
blog [2] I describe a cool bar in Zürich. I mention that I would also  
like to add
to my feed information pertaining to the description. So I would like  
for example to
say that my entry is about a particular bar, give the address of the  
bar, its geo location
perhaps, that it has free wifi, and that it is very friendly. This  
would allow search engines
to index much more structured information about the bar than they  
otherwise could. This would
allow Google Maps for example to give a location to my feedback on  
their maps. In the DOAP over
Atom type solution where the RDF is placed inside the content, there  
is then
no more space to put the entry content itself. So I can either put  
the text entry into the content

or the metadata. Where should the metadata go?

Henry Story

[1] http://www.codezoo.com/about/doap_over_atom.csp
[2] http://blogs.sun.com/roller/page/bblfish/20050910

On 10 Sep 2005, at 01:51, James M Snell wrote:

Bob Wyman wrote:


I’ve written a blog post pointing to a wonderful demo of tools for  
doing structured publishing in blogs that Joe Reger has put  
together. Given that Atom has built-in support for handling much  
more than just the text/HTML that RSS is limited to, I think this  
should be interesting to the Atom community.


http://bobwyman.pubsub.com/main/2005/09/joe_reger_shows.html

What can we do with Atom to make the vision of Structured/Semantic  
publishing more real?


bob wyman

There really isn't anything we HAVE to do with Atom to make it  
suitable for Structured publishing. The format's content model is  
already more than adequate for this kind of thing. For instance,  
Joe Reger's software could easily stuff the XML data instances that  
conform to a logs XML Schema into the atom:content element while  
including the text description of the log into the atom:summary.  
The only thing that really needs to happen here is for someone to  
begin writing the code that makes this happen.


- James

Re: "Top 10" and other lists should be entries, not feeds.

[Henry Story]

It's late here, but since I have been called...

Clearly the order of the entries could not be deduced from the tags  
themselves.

One would need to have an extra tag in there such as this  tag


   
  tag:first-in-list
  1
  The Graphes of Wrath
  1 July 2005
  ...
   
   ...

to specify the order of the entry. I think at the time I was talking  
in the context

of that being proposed.

Again it is late, but I think my idea of having a entry always stay  
at the same position
was that I was thinking that from one week to another one could just  
change the content

of the entry


   
  tag:first-in-list
  1
  Of Mice and Men
  8 July 2005
  ...
   


So that one could still think of a feed as a sequence of changes to  
resources. One
would then, I thought, not need to republish the whole list of  
entries, just
those that changed from week to week. As a result there was I  
thought, no need for

a  tag.

But the problem with that suggestion was that it could not cope well  
with mistaken
feed updates. So that if I mistakenly entered "Of Mice and Men" but I  
meant to
enter "The Restaurant at the End of the Universe" then adding the  
following entry



   
  tag:first-in-list
  1
  The Restaurant at the end of the Universe
  8 July 2005
  ...
   



would tend to indicate that the change was insignificant, whereas a  
change
of date would tend to indicate that the there was a new entry in  
first position.


Some proposed that one should distinguish therefore between the  
update time of the

entry and the update time of the object of the entry...

Henry


On 30 Aug 2005, at 23:35, Thomas Broyer wrote:

Bob Wyman wrote:



I’m sorry, but I can’t go on without complaining. Microsoft has  
proposed extensions which turn RSS V2.0 feeds into lists and we’ve  
got folk who are proposing much the same for Atom (i.e. stateful,  
incremental or partitioned feeds)… I think they are wrong. Feeds  
aren’t lists and Lists aren’t feeds. It seems to me that if you  
want a “Top 10” list, then you should simply create an entry that  
provides your Top 10. Then, insert that entry in your feed so that  
the rest of us can read it. If you update the list, then just  
replace the entry in your feed. If you create a new list (Top 34?)  
then insert that in the feed along with the “Top10” list.




Henry Story also proposed atom:id to be "order-related":
http://www.w3.org/2005/Atom";>
...

tag:first-in-list
Some entry
...


tag:second-in-list
Another entry
...



and a bit later:
http://www.w3.org/2005/Atom";>
...

tag:first-in-list
Another entry
...


tag:second-in-list
Yet another entry
...



Note how tag:first-in-list entry now represents "Another entry"  
while it were previously "Some entry", and tag:second-in-list now  
is "Yet another entry" while it were "Another entry".


--
Thomas Broyer

Re: "Top 10" and other lists should be entries, not feeds.

[Henry Story]

Mhh. Good point too.

For some reason though, this is starting to make me think that a feed  
is an entry again...


Henry

On 30 Aug 2005, at 13:23, Graham wrote:


How would this apply to the most problematic example of a list  
feed, the BBC news headline page:


http://newsrss.bbc.co.uk//rss/newsonline_uk_edition/front_page/rss.xml

Which has the top stories first (amongst other structure) and is a  
hell of a lot more usable in news readers that preserve order.


Graham

Re: "Top 10" and other lists should be entries, not feeds.

[Henry Story]

+1 I completely agree with Bob again.

Though my preference of course would be to put RDF in the content.
RDF has structures for ordered lists. It probably has vocabularies  
for songs.
It has vocabulary to specify the author of a work, etc... And with  
foaf you
could also specify which of the artists was your friend. In short you  
can

mix the different RDF vocabularies out there in well understood ways.

For those of you new to RDF but au fait with Java, I have just  
written up a blog

that should help explain exactly why RDF is so powerful:

http://blogs.sun.com/roller/page/bblfish? 
entry=java_annotations_the_semantic_web


In short: RDF can be mapped directly onto Java Beans. Just as Beans  
can be plugged
together, so RDF markup can be plugged together. Welcome to the world  
of OO xml.


Henry Story

On 30 Aug 2005, at 07:49, Bob Wyman wrote:
I’m sorry, but I can’t go on without complaining.  Microsoft has  
proposed extensions which turn RSS V2.0 feeds into lists and we’ve  
got folk who are proposing much the same for Atom (i.e. stateful,  
incremental or partitioned feeds)… I think they are wrong. Feeds  
aren’t lists and Lists aren’t feeds. It seems to me that if you  
want a “Top 10” list, then you should simply create an entry that  
provides your Top 10. Then, insert that entry in your feed so that  
the rest of us can read it. If you update the list, then just  
replace the entry in your feed. If you create a new list (Top 34?)  
then insert that in the feed along with the “Top10” list.


What is the problem? Why don’t folk see that lists are the stuff of  
entries – not feeds? Remember, “It’s about the entries, Stupid…”


I think the reason we’ve got this pull to turn feeds into Lists is  
simply because we don’t have a commonly accepted “list” schema. So,  
the idea is to repurpose what we’ve got. Folk are too scared or  
tired to try to get a new thing defined and through the process, so  
they figure that they will just overload the definition of  
something that already exists. I think that’s wrong. If we want  
“Lists” then we should define lists and not muck about with Atom.  
If everyone is too tired to do the job properly and define a real  
list as a well defined schema for something that can be the payload  
of a content element, then why not just use OPML as the list format?




What is a search engine or a matching engine supposed to return as  
a result if it find a match for a user query in an entry that comes  
from a list-feed? Should it return the entire feed or should it  
return just the entry/item that contained the stuff in the users’  
query? What should an aggregating intermediary like PubSub do when  
it finds a match in an element of a list-feed? Is there some way to  
return an entire feed without building a feed of feeds? Given that  
no existing aggregator supports feeds as entries, how can an  
intermediary aggregator/filter return something the client will  
understand?


You might say that the search/matching engine should only present  
the matching entry in its results. But, if you do that what happens  
is that you lose the important semantic data that comes from  
knowing the position the matched entry had in the original list- 
feed. There is no way to preserve that order-dependence information  
without private extensions at present.


I’m sorry but I simply can’t see that it makes sense to encourage  
folk to break important rules of Atom by redefining feeds to be  
lists. If we want “lists” we should define what they look like and  
put them in entries. Keep your hands off the feeds. Feeds aren’t  
lists – they are feeds.




bob wyman

Re: Don't Aggregrate Me

[Henry Story]

Yes, I see how one is meant to look at it. But I can imagine desktop  
aggregators
becoming more independent when searching for information... Perhaps  
at that point

they should start reading robots.txt...

Henry


On 25 Aug 2005, at 23:12, Walter Underwood wrote:


I would call desktop clients "clients" not "robots". The  
distinction is

how they add feeds to the polling list. Clients add them because of
human decisions. Robots discover them mechanically and add them.

So, clients should act like browsers, and ignore robots.txt.

Robots.txt is not very widely deployed (around 5% of sites), but it
does work OK for general web content.

wunder

--On August 25, 2005 10:25:08 PM +0200 Henry Story  
<[EMAIL PROTECTED]> wrote:





Mhh. I have not looked into this. But is not every desktop  
aggregator  a robot?


Henry

On 25 Aug 2005, at 22:18, James M Snell wrote:


At the very least, aggregators should respect robots.txt.  Doing so
would allow publishers to restrict who is allowed to pull their  
feed.


- James










--
Walter Underwood
Principal Software Architect, Verity

Re: Don't Aggregrate Me

[Henry Story]

Mhh. I have not looked into this. But is not every desktop aggregator  
a robot?


Henry

On 25 Aug 2005, at 22:18, James M Snell wrote:
At the very least, aggregators should respect robots.txt.  Doing so  
would allow publishers to restrict who is allowed to pull their feed.


- James

Re: Don't Aggregrate Me

[Henry Story]

On 25 Aug 2005, at 17:06, A. Pagaltzis wrote:


* Henry Story <[EMAIL PROTECTED]> [2005-08-25 16:55]:


Do we put base64 encoded stuff in html? No: that is why  there
are things like









!!! That really does exist?!
Yes:
http://www.ietf.org/rfc/rfc2397.txt

But apparently only for very short data fragments (a few k at most).  
And it does not give me anything

very intersting when I look at it in either Safari or Firefox.

Thanks for pointing this out. :-)


:-)

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

Re: Don't Aggregrate Me

[Henry Story]

On 25 Aug 2005, at 15:45, Joe Gregorio wrote:


On 8/25/05, James M Snell <[EMAIL PROTECTED]> wrote:



Up to this point, the vast majority of use cases for Atom feeds is  
the

traditional syndicated content case.  A bunch of content updates that
are designed to be distributed and aggregated within Feed readers or
online aggregators, etc.  But with Atom providing a much more  
flexible
content model that allows for data that may not be suitable for  
display
within a feed reader or online aggregator, I'm wondering what the  
best

way would be for a publisher to indicate that a feed should not be
aggregated?

For example, suppose I build an application that depends on an  
Atom feed
containing binary content (e.g. a software update feed).  I don't  
really

want aggregators pulling and indexing that feed and attempting to
display it within a traditional feed reader.  What can I do?



First, on this scenario, I would be inclined to make the firmware  
an enclosure

and not included base64.


+1 definitely.



But I still can see a scenario you might be serving up queries via
Atom and those
queries could be 'heavy'. There are, of course, several things you  
could do:


1. Cache the results.
2. Support ETags
3. Support ETags and 'fake' them so that they change only once a  
day, maybe

   once a week even.



I would put the following as the most obvious solution

0. have the content link to the file either by using enclosures or  
content by reference such as

   

There should be a golden rule: never place binary content in xml. It  
is ugly and completely
unnecessary. Do we put base64 encoded stuff in html? No: that is why  
there are things like



Henry

There are undoubtedly others, but the more important part is that  
your 'do not

aggregate' doesn't really solve the problem. I could, for example,
take one of your
heavy search feeds, convert it to HTML via XSLT and include that  
via iframe
in my home page. *That* traffic is going to be a lot worse than an  
aggregator

subscription and wouldn't fit the definition of 'aggregation'.

   -joe

--
Joe Gregoriohttp://bitworking.org

Re: Extensions at the feed level (Was: Re: geolocation in atom:author?)

[Henry Story]

On 22 Aug 2005, at 18:29, James M Snell wrote:


Bill de hÓra wrote:


As we have no processing model for this, my answer to Paul's  
question is
that feed level extensions do not inherit/cascade/scope over entry  
level
ones, irrespective of whether they're foreign or not, and that the  
best

way to think about atom:author is as a frozen accident.




+1



Ok, this is absolutely fine.  I'll go back through and update my  
various extension proposals to reflect this train of thought.

- James

Re: Feed History -03

[Henry Story]

On 17 Aug 2005, at 00:14, Mark Nottingham wrote:

On 16/08/2005, at 3:05 PM, Robert Sayre wrote:


I suggested writing the next tag like this:

http://purl.org/syndication/history/1.0/next"; href="./
archives/archive1.atom">



That's what I would do, too. Not my spec, though. Mainly so I could
put a title in that said "Entries from August" or whatever.


For that matter, if Henry's interpretation were correct, the  
element could be


  ./archives/archive1.atom

And Atom processors would magically know that XML Base applies to  
the URI therein. It's the magic that I object to; inferring the  
applicability of context based on the presence or absence of other  
markup isn't good practice, and will lead to practical problems.  
E.g., what if I want to have an optional attribute on an empty  
element? Is it "simple" or "complex"?


Yes. I agree the problem also exists for complex extensions. My  
question is the following:


How can a parser that parses atom and unknown extensions, know when  
to apply the xml base to

an extension element automatically?

Clearly if the extensions themselves were to use only xlink:link  
elements that would be easy.
(though atom itself does not give a good example by not following  
that principle). Is there
a place that parsers can get information where they can automatically  
tell that an attribute is a
xlink:link copycat? Or how do they tell that the content of an  
element is a URI? Can  DTDs or RelaxNG files help? If they could  
help, would they be retrievable mechanically by a processor of

xml to help it work out how to deal with relative references?

Anyway to summarise: if you don't want to use the atom:link element  
then perhaps it would
be best to use the xlink:link attributes. I have only read that spec  
quickly [1] but this would

mean that the following

  

would widely be understood to work with the xml:base.

Henry Story

[1] http://www.w3.org/TR/2001/REC-xlink-20010627/



This interpretation of extensions seems very fragile to me.

--
Mark Nottingham http://www.mnot.net/

Re: Feed History -03

[Henry Story]

On 16 Aug 2005, at 21:50, Robert Sayre wrote:

On 8/16/05, Henry Story <[EMAIL PROTECTED]> wrote:

On 16 Aug 2005, at 21:00, Mark Nottingham wrote:

I very much disagree; relative references should be allowable in
simple extensions, and in fact the rationale that Tim gives is the
reasoning I assumed regarding Atom extensions; if I had known that
the division between simple and complex extensions would be used to
justify a constraint on the use of context in simple extensions, I
would have objected to it.


The problem is that readers of your xml that wish to store your data
in some form other than xml (relational database, triple store,
object oriented database, prolog database,...), and that may
not at the time of consumption know about your extension will  save
the content in text, which is all the spec says they should do. Since
they don't at the time know the meaning of fh:prev and
in particular that it should contain a URI  they can't save the
absolute URI it represents.
All they will be able to save is relative uri which will be
meaningless if the context of the
original document is lost.


The app should store the relative URI, and it shouldn't lose the  
context.


relative URI? The application we are speaking about knows nothing of  
a relative
uri. All you have inside your Simple Extension Element is text! See  
the spec 6.4.1.


An application that does not know your extension cannot know that the  
text inside
your extension is to be interpreted as a relative uri. So what you  
are saying is
that any application that wants to process atom with extension  
elements has to keep
the full context of the document in which they found the extension  
element, even if
the document is a 100s of Megabytes long, and even if there is only  
one extension
element inside of it!  Or take the case of code that wants to place  
the feed inside
some other xml, which has a base element. What is it to do when it  
finds an extension

element it does not understand?




If you're using something like RDF to model feeds, you already have
a number of context-related issues to work through, this isn't an
extra burden.



The point of making extensions is that they should be interpretable
or at least in part useable
by parties that don't understand the extension.



It still is.


No they are not! See the 2 examples above.


This is a question of the Atom spec saying that the content of a
simple extension element is character data. Yet you are now wishing
to put in relative references that have complex semantics
not completely understandable without having the original context of
the document they appear in.


Lots of extensions will be like this. What's one itunes extenstion
without the others? :)


?


In summary, I agree with Mark.


You agree to accept the problems that go with his position, yes.
But why bother when there clearly is an easy solution to the problem  
that works with
the current atom format and which I outlined earlier, namely using  
the link element.

I suggested writing the next tag like this:

http://purl.org/syndication/history/1.0/next"; href="./ 
archives/archive1.atom">


This clearly allows relative uris (if I am not mistaken) without any  
of the problems
we have with the simple extension elements. And it seems to be  
exactly this type of

thing that the link element was designed to do.


Henry Story
http://blogs.sun.com/roller/page/bblfish/


Robert Sayre

Re: Feed History -03

[Henry Story]

On 16 Aug 2005, at 21:00, Mark Nottingham wrote:


I very much disagree; relative references should be allowable in  
simple extensions, and in fact the rationale that Tim gives is the  
reasoning I assumed regarding Atom extensions; if I had known that  
the division between simple and complex extensions would be used to  
justify a constraint on the use of context in simple extensions, I  
would have objected to it.


The problem is that readers of your xml that wish to store your data  
in some form other than xml (relational database, triple store,  
object oriented database, prolog database,...), and that may
not at the time of consumption know about your extension will  save  
the content in text, which is all the spec says they should do. Since  
they don't at the time know the meaning of fh:prev and
in particular that it should contain a URI  they can't save the  
absolute URI it represents.
All they will be able to save is relative uri which will be  
meaningless if the context of the

original document is lost.

If you're using something like RDF to model feeds, you already have  
a number of context-related issues to work through, this isn't an  
extra burden.


The point of making extensions is that they should be interpretable  
or at least in part useable
by parties that don't understand the extension. RDF has nothing to do  
with this. (Other than
it having some very solid theoretical backing and so being very  
helpful in thinking about these
issues, and also of it having solved quite a few years ago the  
problems that you are just discovering)



I should explicitly allow relative URIs in fh:prev, though.


-1

This is a question of the Atom spec saying that the content of a  
simple extension element is character data. Yet you are now wishing  
to put in relative references that have complex semantics
not completely understandable without having the original context of  
the document they appear in.
I know it may seem to the writer of an extension as if the meaning of  
his extension were clear
as day, but this will not be the case to all consumers of your  
extension, and even if your
extension becomes world famous, it certainly won't be true for all  
the other extensions that people will come up with. So I think we  
should be setting a good example in these first extensions we write.


Henry Story



Cheers,


On 16/08/2005, at 11:35 AM, Henry Story wrote:


I think that in section 5. you should specify that the URI  
reference MUST NOT be relative or
MUST BE absolute (if that is the proper W3C Architecture term). I  
agree with the point made by

David Powell in the thread entitled "More about extensions" [1].

Given that we have this problem I was wondering whether it would  
not be better
to use the link element as I think it permits relative references.  
Relative references
really are *extreemly useful*. I tried to work without them in my  
BlogEd editor
because the Sesame database folk mistakenly thought it was not  
part of RDF, and it caused
me no end of trouble: all those problems vanished as soon as they  
allowed relative references.


So if relative references are allowed in links perhaps the  
following would be better:


http://purl.org/syndication/history/1.0/next"; href="./ 
archives/archive1.atom">



Henry Story

[1] http://www.imc.org/atom-syntax/mail-archive/msg16643.html


On 15 Aug 2005, at 22:31, Mark Nottingham wrote:




Draft -03 of feed history is now available, at:
  http://www.ietf.org/internet-drafts/draft-nottingham-atompub- 
feed-history-03.txt


Significant changes in this revision include:
  - add fh:archive element, to indicate that an entry is an archive
  - allow subscription feed to omit fh:stateful if fh:prev is  
present
  - clarified that fh doesn't add ordering semantics, just allows  
you to reconstruct state

  - cleaned up text, fixed examples, general standards hygiene

There's going to be at least one more draft, as I neglected to  
acknowledge people who have made suggestions and otherwise helped  
so far. Sorry!


--
Mark Nottingham http://www.mnot.net/











--
Mark Nottingham http://www.mnot.net/

Re: Feed History -03

[Henry Story]

I think that in section 5. you should specify that the URI reference  
MUST NOT be relative or
MUST BE absolute (if that is the proper W3C Architecture term). I  
agree with the point made by

David Powell in the thread entitled "More about extensions" [1].

Given that we have this problem I was wondering whether it would not  
be better
to use the link element as I think it permits relative references.  
Relative references
really are *extreemly useful*. I tried to work without them in my  
BlogEd editor
because the Sesame database folk mistakenly thought it was not part  
of RDF, and it caused
me no end of trouble: all those problems vanished as soon as they  
allowed relative references.


So if relative references are allowed in links perhaps the following  
would be better:


http://purl.org/syndication/history/1.0/next"; href="./ 
archives/archive1.atom">



Henry Story

[1] http://www.imc.org/atom-syntax/mail-archive/msg16643.html


On 15 Aug 2005, at 22:31, Mark Nottingham wrote:


Draft -03 of feed history is now available, at:
  http://www.ietf.org/internet-drafts/draft-nottingham-atompub-feed- 
history-03.txt


Significant changes in this revision include:
  - add fh:archive element, to indicate that an entry is an archive
  - allow subscription feed to omit fh:stateful if fh:prev is present
  - clarified that fh doesn't add ordering semantics, just allows  
you to reconstruct state

  - cleaned up text, fixed examples, general standards hygiene

There's going to be at least one more draft, as I neglected to  
acknowledge people who have made suggestions and otherwise helped  
so far. Sorry!


--
Mark Nottingham http://www.mnot.net/

Re: Feed History -03

[Henry Story]

On 16 Aug 2005, at 02:19, Mark Nottingham wrote:

On 15/08/2005, at 5:09 PM, Robert Sayre wrote:


I'm interested in getting things working,
not playing the syndication format advocacy game.



Not sure how feed-history will work without a unique id.



? Sorry, you lost me there.


Yes. If you were to take a subscription feed "feed.atom" and map it  
to a graph

you might get something like this:

_feed
  |id--> 
  |---entry> _
  |  |id-> 
  |  |---title---> "first entry"
  |--fh:next---> <http://my.web/feed/history1.atom>


The graph of the history1.atom archive may be:

_feed2
  |id--> 
  |---entry> _
 |id-> 
 |---title---> "another entry"


The role of id is to help us merge the two graphs. IE the point of  
the history
tag is to help us think of the history.atom document as a  
continuation of
the same document, or rather that they are both descriptions of the  
feed with
id . Merging the above two as simple graphs at  
most gives

this


  |--1/id---> _feed
  |   |---entry> _
  |   |  |id-> 
  |   |  |---title---> "first entry"
  |   |--fh:next---> <http://my.web/feed/history1.atom>
  |--1/id--->_feed2
  |---entry> _
  |  |id-> 
  |  |---title---> "another entry"
  |--fh:next---> <http://my.web/feed/history1.atom>


But what we really want is something like this:


  |---entry> _
  |  |id-> 
  |  |---title---> "first entry"
  |---entry> _
 |id-> 
 |---title---> "another entry"


I think we require some form of inferencing beyond what is available  
in OWL
to achieve this result. This could probably be achieved through some  
simple

N3 rules.

Henry Story

Re: More about Extensions

[Henry Story]

Sorry to note the obvious, but does this not sound so much like a  
good reason we should
have engineered atom to *be* RDF? Is this not exactly one of the many  
problems that RDF

sets out to solve?

Henry Story

On 10 Aug 2005, at 02:34, Tim Bray wrote:


On Aug 9, 2005, at 5:11 PM, David Powell wrote:



No, we just need to warn publishers (and extension authors) that the
base URI of Simple Extension elements is not significant, and that
they must not expect it to be preserved.



Either the software understands the foreign markup, in which case  
it might recognize a relative URI, in which case it should apply  
the correct base URI, or it doesn't, in which case everything in  
the foreign markup is just a semantics-free string.


The problem could hypothetically arise when someone extracts  
properties from the foreign markup, stuffs them in a tuple store,  
and then when the software that knows what to do with comes along  
and retrieves it and recognizes the relative URI and can't do much  
because the base URI is lost.


So... IF you know how to handle some particular extension, AND IF  
you expect to handle it when the extension data has been ripped out  
of the feed and stored somewhere without any context, THEN you  
shouldn't use a relative reference.  Alternatively, IF you want to  
empower extensions to process they data they understand, AND IF you  
want to rip that data out of the feed and store it somewhere, THEN  
it would be smart to provide software an interface to retrieve  
context, such as feed-level metadata and the base URI.


Sounds like implementor's-guide material to me.

And, to whoever said relative references are "fragile": Wrong.   
When you have to move bales of web content around from one place to  
another, and just supposing hypothetically that you have internal  
links, relative references are robust, absolute URIs are fragile.  - 
Tim

Re: Expires extension draft (was Re: Feed History -02)

[Henry Story]

There is an interesting problem of how this interacts with the  
history tag.


If you set an a feed


  ...
  
  


then what are you setting it on? Well not the document, clearly, as  
you have
pointed out since HTTP headers deal with that. So it must be on the  
feed. And

of course a feed is identified by its id.

Now we have to make sure we avoid contradictions where different feed  
documents

describing the same feed state that the feed has different expiry dates.

Eg:

the main feed--

  August 25 2006
  tag:example.com,2000/feed1
  
  
  http://example.com/archive1

---

The above is a partial description of the feed tag:example.com,2000/ 
feed1

The history:previous link points to another document that gives
us more information about that feed.

---the archive feed

  August 15 2006
  tag:example.com,2000/feed1
  
  
  http://example.com/archive2

---

Now of course we have a feed id with two expiry dates. Which one is  
correct?

In graph terms we end up with something like this:

tag:example.com,2000
   |expires-->August 25 2006
   |expires-->August 15 2006
   |entry>...
   |entry>...
   |entry>...
   |entry>...

One has the feeling that the expires relation should be functional,  
ie have

only one value.

This makes me think again that for what I was looking for (that the  
document
in history:previous not change, so that one can work out when to stop  
fetching
documents) can in fact be entirely be taken care of by the http  
expiry dates and
cache control mechanism. Of course if this is so, I think it should  
be noted
clearly in the history spec. ((btw. Is it easy to set expiry dates  
for documents served

by apache?))


Henry Story


On 10 Aug 2005, at 04:46, James M Snell wrote:


This is fairly quick and off-the-cuff, but here's an initial draft  
to get the ball rolling..


 http://www.snellspace.com/public/draft-snell-atompub-feed-expires.txt

- James

Henry Story wrote:



To answer my own question

[[
Interesting... but why have a limit of one year? For archives, I   
would like a limit of

forever.
]]

 I found the following in the HTTP spec

[[
   To mark a response as "never expires," an origin server sends an
   Expires date approximately one year from the time the response is
   sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one
   year in the future.
]]

(though that still does not explain why.)

Now I am wondering if the http mechanism is perhaps all that is  
needed
for what I want with the unchanging archives. If it is then  
perhaps this
could be explained in the Feed History RFC. Or are there other   
reasons to

add and "expires" tag to the document itself?

Henry Story

On 9 Aug 2005, at 19:09, James M Snell wrote:







rules as atom:author elements.

Here it is: <http://www.intertwingly.net/wiki/pie/PaceCaching>




The expires and max-age elements look fine. I hesitate at  
bringing  in a caching discussion.  I'm much more comfortable  
leaving the  definition of caching rules to the protocol level  
(HTTP) rather  than the format extension level.  Namely, I don't  
want to have to  go into defining rules for how HTTP headers that  
affect caching  interact with the expires and max-age elements...  
IMHO, there is  simply no value in that.
The expires and max-age extension elements affect the feed /  
entry  on the application level not the document level.  HTTP  
caching  works on the document level.





Adding max-age also means defining IntegerConstruct and disallowing
white space around it. Formerly, it was OK as a text construct, but
the white space issues change that.





This is easy enough.



Also, we should decide whether cache information is part of the   
signature.

I can see arguments either way.





-1.  let's let caching be handled by the transport layer.

Re: Feed History -02

[Henry Story]

To answer my own question

[[
Interesting... but why have a limit of one year? For archives, I  
would like a limit of

forever.
]]

 I found the following in the HTTP spec

[[
   To mark a response as "never expires," an origin server sends an
   Expires date approximately one year from the time the response is
   sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one
   year in the future.
]]

(though that still does not explain why.)

Now I am wondering if the http mechanism is perhaps all that is needed
for what I want with the unchanging archives. If it is then perhaps this
could be explained in the Feed History RFC. Or are there other  
reasons to

add and "expires" tag to the document itself?

Henry Story

On 9 Aug 2005, at 19:09, James M Snell wrote:




rules as atom:author elements.

Here it is: <http://www.intertwingly.net/wiki/pie/PaceCaching>



The expires and max-age elements look fine. I hesitate at bringing  
in a caching discussion.  I'm much more comfortable leaving the  
definition of caching rules to the protocol level (HTTP) rather  
than the format extension level.  Namely, I don't want to have to  
go into defining rules for how HTTP headers that affect caching  
interact with the expires and max-age elements... IMHO, there is  
simply no value in that.
The expires and max-age extension elements affect the feed / entry  
on the application level not the document level.  HTTP caching  
works on the document level.




Adding max-age also means defining IntegerConstruct and disallowing
white space around it. Formerly, it was OK as a text construct, but
the white space issues change that.




This is easy enough.


Also, we should decide whether cache information is part of the  
signature.

I can see arguments either way.




-1.  let's let caching be handled by the transport layer.

Re: Feed History -02

[Henry Story]

On 9 Aug 2005, at 18:32, Walter Underwood wrote:
--On August 9, 2005 9:28:52 AM -0700 James M Snell  
<[EMAIL PROTECTED]> wrote:

I made some proposals for cache control info (expires and max-age).
That might work for this.


I missed these proposals.  I've been giving some thought to an  
 and  extension myself and was getting ready  
to write up a draft. Expires is a simple date construct specifying  
the exact moment (inclusive) that the entry/feed expires.  Max-age  
is a non negative integer specifying the number of miliseconds  
(inclusive) from the moment specified by atom:updated when then  
entry/feed expires.  The two cannot appear together within a  
single entry/feed and follows the same basic



rules as atom:author elements.

Here it is: 


Interesting... but why have a limit of one year? For archives, I  
would like a limit of

forever.

But otherwise I suppose this would do. Instead of putting the  
information in the
 link of the linking feed, you would put it in the archive  
feed. Which sounds
good. I suppose we end up with some duplication of information here  
with the http headers

again.


Adding max-age also means defining IntegerConstruct and disallowing
white space around it. Formerly, it was OK as a text construct, but
the white space issues change that.

Also, we should decide whether cache information is part of the  
signature.

I can see arguments either way.

wunder
--
Walter Underwood
Principal Architect, Verity

Re: Feed History -02

[Henry Story]

On 4 Aug 2005, at 06:27, Mark Nottingham wrote:
So, if I read you correctly, it sounds like you have a method  
whereby a 'top20' feed wouldn't need history:prev to give the kind  
of history that you're thinking of, right?


If that's the case, I'm tempted to just tweak the draft so that  
history:stateful is optional if history:prev is present. I was  
considering dropping stateful altogether, but I think something is  
necessary to explicitly say "don't try to keep a history of my  
feed." My latest use case for this is the RSS feed that Netflix  
provides to let you keep an eye on your queue (sort of like top20,  
but more specialised).


Sound good?


Sounds good to me.

But I would really like some way to specify that the next feed  
document is an archive (ie. won't change). This would make it easy  
for clients to know when to stop following the links, ie, when

they have cought up with the changes since they last looked at the feed.

Perhaps something like this:

http://liftoff.msfc.nasa.gov/2003/04/ 
feed.rss


Henry Story

Re: nested feeds (was: Feed History -02)

[Henry Story]

Sorry for taking so long to reply. I have been off on a 700km cycle trip
http://blogs.sun.com/roller/page/bblfish/20050807

I don't really want to spend to much time on the top-X discussion, as  
I am
a lot more interested in the feed history itself, but here are some  
thoughts

anyway...


On 29 Jul 2005, at 17:01, Eric Scheid wrote:

On 29/7/05 11:39 PM, "Henry Story" <[EMAIL PROTECTED]> wrote:
Below I think I have worked out how one can in fact have a top20   
feed, and I
show how this can be combined without trouble with the   


link...

On 29 Jul 2005, at 13:12, Eric Scheid wrote:

On 29/7/05 7:57 PM, "Henry Story" <[EMAIL PROTECTED]> wrote:

1- The top 20 list: here one wants to move to the previous top   
20  list and
think of them as one thing. The link to the next feed is not  
meant  to be
additive. Each feed is to be seen as a whole. I have a little   
trouble still

thinking of  these as feeds, but ...


What happens if the publisher realises they have a typo and need  
to  emit an
update to an entry? Would the set of 20 entries (with one entry   
updated) be

seen as a complete replacement set?

Well if it is a typo and this is considered to be an  
insignificant  change
then they can change the typo in the feed document and not need to  
change  any

updated time stamps.



Misspelling the name of the artist for the top 20 songs list is not
insignificant. Even worse fubars are possible too -- such as  
attributing the

wrong artist/author to the #1 song/book (and even worse: leaving off a
co-author).


Yes, I see this now. This is a problem for my suggestion. The  
atom:updated field
cannot be used to indicate the date at which an entry has a certain  
position in a
chart for the reason you mention. We could then no longer update that  
entry
for spelling mistakes or other more serious issues. One would have to  
add
a about date or something, and then the things gets a little more  
complicated

than I care to think about right now.

The way I see it, maybe a better way would be to have a sliding   
window feed
where each entry points to another Atom Feed Document with it's  
own  URI, and
it is that second Feed Document which contains the individual  
items  (the top

20 list).

This is certainly closer to my intuitions too.  A top 20 something  
is  *not* a
feed. Feed entries are not ordered, and are not meant to be  
thought of as a

closed collection. At least this is my initial intuition. BUT



Not all Atom Feed Documents are feeds, some are static collections of
entries. We keep tripping over this :-(

I can think of a solution like the following: Let us imagine a top  
20  feed
where the resources being described by the entries are the  
position in the

top list. So we have entries with ids such as

http://TopOfThePops.co.uk/top20/Number1
http://TopOfThePops.co.uk/top20/Number2
http://TopOfThePops.co.uk/top20/Number3 ...



will contain a new entry such as

  
   Top of the pops entry number 1
   http://TopOfThePops.co.uk/top20/Number1/"/>
   http://TopOfThePops.co.uk/top20/Number1
   2005-07-05T18:30:00Z
   Top of the pops winner for the week starting 5 July
2005
 



The problem here is that this doesn't describe the referent, it only
describes the reference. I want to see top 20 feeds where each  
entry links
to the referent in question. For example, the Amazon Top 10 Selling  
Books
feed would link to the book specific page at Amazon, not to some  
page saying

"the #3 selling book is at the other end of this link".


Oh, I don't really want to defend this position too much but there would
be a way around this criticism by simply having the link point to the  
album

like this:

  
   Top of the pops entry number 1
   http://www.amazon.fr/exec/obidos/ASIN/B4ULZV"/>
   http://TopOfThePops.co.uk/top20/Number1
   2005-07-05T18:30:00Z
   Top of the pops winner for the week starting 5 July
2005


So here the id would be the same for each position from week to week,  
but

the link it points to would change.

We would still need to solve the issue of the date at which it had that
position, though...

And so yes, a feed where the entry is a feed seems easier to work  
with in this case.

The feed would be something like this I suppose:


   top 20 French songs
   ...

   week of August 1 2005
   ...?...
   2005-08-01T18:30:00Z
   http://TopOfThePops.fr/top20/2005_08_01/";  
type="application/atom+xml">



   week of August 1 2005
   ...?...
   
   http://TopOfThePops.fr/top20/2005_08_01/";  
type="application/atom+xml">

   2005-08-02T18:30:00Z


   week of August 8 2005
   ...?...
   
   http://TopOfThePops.fr/top20/2005_08_08/";  
type="application/atom+xml">

   2005-08-08T18:30:00Z



But while you are at it then why not just create a special top-X  
ontology a

Re: Feed History -02

[Henry Story]

Below I think I have worked out how one can in fact have a top20  
feed, and
I show how this can be combined without trouble with the  


link...


On 29 Jul 2005, at 13:12, Eric Scheid wrote:


On 29/7/05 7:57 PM, "Henry Story" <[EMAIL PROTECTED]> wrote:


1- The top 20 list: here one wants to move to the previous top  20  
list and
think of them as one thing. The link to the next feed is not meant  
to be
additive. Each feed is to be seen as a whole. I have a little  
trouble still

thinking of  these as feeds, but ...



What happens if the publisher realises they have a typo and need to  
emit an
update to an entry? Would the set of 20 entries (with one entry  
updated) be

seen as a complete replacement set?


Well if it is a typo and this is considered to be an insignificant  
change then
they can change the typo in the feed document and not need to change  
any updated

time stamps.

The way I see it, maybe a better way would be to have a sliding  
window feed
where each entry points to another Atom Feed Document with it's own  
URI, and
it is that second Feed Document which contains the individual items  
(the top

20 list).


This is certainly closer to my intuitions too.  A top 20 something is  
*not* a feed.
Feed entries  are not ordered, and are not  meant to be thought of as  
a closed

collection. At least this is my initial intuition. BUT

I can think of a solution like the following: Let us imagine a top 20  
feed where
the resources being described by the entries are the position in the  
top list. So

we have entries with ids such as

http://TopOfThePops.co.uk/top20/Number1
http://TopOfThePops.co.uk/top20/Number2
http://TopOfThePops.co.uk/top20/Number3
...

Each of these resources describes the songs that is at a certain rank  
in the top of
the pops chart. Each week the song in that rank may change. When a  
change occurs in the

song at a certain rank the top 20 feed with id

http://TopOfThePops.co.uk/top20/Feed

will contain a new entry such as

   
Top of the pops entry number 1
http://TopOfThePops.co.uk/top20/Number1/"/>
http://TopOfThePops.co.uk/top20/Number1
2005-07-05T18:30:00Z
Top of the pops winner for the week starting 5 July  
2005

  

A client that would subscribe to such a feed would automatically get  
updates every
week for each of the top 20 resources. But the feed could be  
structured exactly like

I suggest in 2.

So for a top 2 feed (20 is a bit to long for me)


   My top 2 Software Books
   http://bblfish.net/blog/top2
   http://bblfish.net/blog/top2/ 
Archive-2005-07-18.atom

   ...
   
My Top 1 book
http://bblfish.net/blog/top2/Number1/"/>
http://bblfish.net/blog/top2/Number1
2005-07-25T18:30:00Z
My top 1 book is Service Oriented Computing by Wileysummary>

   
   
My Top 2 book
http://bblfish.net/blog/top2/Number2/"/>
http://bblfish.net/blog/top2/Number2
2005-07-25T18:30:00Z
My second top book is "xml in a Nutshell"
  


The above representation of the http://bblfish.net/blog/top2 feed  
points to the

archive feed http://bblfish.net/blog/top2/Archive-2005-07-18.atom


   My top 2 Software Books
   http://bblfish.net/blog/top2
   ...
   
My Top 1 book
http://bblfish.net/blog/top2/Number1/"/>
http://bblfish.net/blog/top2/Number1
2005-07-18T18:30:00Z
My top 1 book is Java 2D Graphics
   
   
My Top 2 book
http://bblfish.net/blog/top2/Number2/"/>
http://bblfish.net/blog/top2/Number2
2005-07-18T18:30:00Z
My second top book is "xml in a Nutshell"
  


 As you notice only the top1 has changed from the first week but not  
the
second, and yet in both feeds there is an entry for both. A non  
change can
sometimes be an important event. But this is really up to the feed  
creator
to choose how to present his feeds. He could easily have had only had  
the

entry for http://bblfish.net/blog/top2/Number1 in the first feed.

Looking at it this way, there really seems to be no incompatibility  
between
a top 20 feed and the  link. My talk about archives  
not

changing should be more precisely about archives not changing in any
significant way. And this advice could be moved to an implementors  
section

and be encoded in HTTP by simply giving archive pages an infinitely long
expiry date.

Someone could subscribe to that second feed and poll for updates,  
and all
they'll ever see are updates to the 20 items there, not the 20  
items from

the next week/whatever.

The idea of feeds linked to feeds has lots of utility -- feeds of  
comments

for one, and even a feed of feeds available on the site.


I completely agree. And remember for any two things there is at least  
one way they
are related. And there are many different ways feeds can be related  
to each other.
A feed may be an archival continuation of one - which is what the  

link in my opinion addresses, b

Re: Feed History -02

[Henry Story]

I get the feeling that we should perhaps first list the main types of  
history archives, and

then deal with each one separately. I can see 3:

1- The top 20 list: here one wants to move to the previous top  
20 list and think of them
   as one thing. The link to the next feed is not meant to be  
additive. Each feed is to
   be seen as a whole. I have a little trouble still thinking of  
these as feeds, but ...
2- The history of changes link: the idea here is that a feed is  
a list of state changes
  to web resources. The link to the history just increases the  
length of the feed by
  pointing to the next feed page. These two pages could have  
been merged to create one
  feed page with the same end result. By moving back through the  
feed history one gets
  to see the complete history of changes to the resources  
described by the feed.
3- A listing of the current states of the resources: here the  
end user is searching for
  all the blog entries as they currently are. No feed id is ever  
duplicated across the chain.


I think each of these has its uses.
 1. this use case is clear and well understood.
 2. is very useful for 'static' blog feeds written from a remote  
server, as once a feed has
been archived it no longer needs to be rewritten. It is also  
very useful in helping a
client synchronize with the changes to the feed. If a client is  
off line for a few months
or if there are a lot of changes in a feed then the client just  
needs to follow this type
of link to catch up with all the changes. If the entries are  
describing state changes to
resources such as stock market valuations, then this would allow  
one to get all the

valuations for a company going back in time.
 3. It is easier for this to be generated dynamically upon request.  
It is not really a history
of changes, but rather a list of resources. In a feed concerning  
a blog these two can of
course easily be confused as we think of blogs as being created  
sequentially. We then think
of the feed history as the history of the blog entry publication  
dates. If an old blog entry
gets changed then the page on which that blog entry originally  
appeared in the feed would
get changed just as the permalink to the blog post itself gets  
changed.
This type of list is of course not very useful in keeping  
someone updated as to the changes
in a feed, as the whole linked feeds would need to be stepped  
through to see if anything has

changed.
I think it is with this version that the proposals of having a  
separate document that points
to all the entries makes most sense. And this case also seems to  
be worked upon in the API

I think.

more below...

On 23 Jul 2005, at 18:14, Mark Nottingham wrote:



On 19/07/2005, at 2:04 AM, Henry Story wrote:


Clearly the archive feed will work best if archive documents, once  
completed (containing a
given number of entries) never change. Readers of the archive will  
have a simple way to know when
to stop reading: there should never be a need to re-read an  
archive page - they just never change.


The archive provides a history of the feed's evolution. Earlier  
changes to the resources
described by the feed will be found in older archive documents and  
newer changes in the later
ones. One should expect some entries to be referenced in multiple  
archive feed documents. These

will be entries that have been changed over time.

Archives *should not* change. I think any librarian will agree  
with that.




I very much agree that this is the ideal that should be striven for.

However, there are some practical problems with doing it in this  
proposal.


First of all, I'm very keen to make it possible to implement  
history with currently-deployed feed-generating software; e.g.,  
Moveable Type. MT isn't capable of generating a feed where changed  
entries are repeated at the top out of the box, AFAIK.


So is it that MT can only generate feed links such as describe in 3  
above?


Even if it (and other software) were, it would be very annoying to  
people whose feed software doesn't understand this extension; their  
"show me the latest entries in the blog" feed would become "show me  
the latest changed entries in the blog", and every time an entry  
was modified or spell-checked, it would show up at the top.


Well in many cases this is exactly what I want. If someone makes a  
big change to a resource that
was created one year ago (say your first blog post) then I think this  
is well worth knowing about.
Especially if I have written a comment about it. Of course if the  
change is not *significant* then
the change to the old feed archive would not be significant either.  
So perhaps I should have said

that archives should not change in any *significant* way.

So, it's a matter of enabling graceful deployment. Most of the  

spam on wiki

[Henry Story]

The following page has been badly spammed

http://www.intertwingly.net/wiki/pie/AtomOWL

and it looks like the fact that it was changed never appeared in the  
RSS feed.


Henry

images and logos

[Henry Story]

I have just published a feed for my blog at http://bblfish.net/blog/ 
blog.atom


I use logo and icon tags. Am I using it correctly?

I wanted to add logos and icons to each of the entries too, as each  
entry at
http://bblfish.net/blog/ has an associated image and logo. I guess I  
will
have to create my own extension element and won't be able to reuse  
the current

atom ones.

Is anyone else interested in this?

Henry

Re: Feed History -02

[Henry Story]

On 19 Jul 2005, at 01:52, A. Pagaltzis wrote:


* Mark Nottingham <[EMAIL PROTECTED]> [2005-07-18 23:30]:


This is one of the unanswered questions that I left out of
scope. The  consumer can examine the previous archive's URI and
decide as to  whether it's seen it or not before, and therefore
avoid fetching it  if it already has seen it. However, in this
approach, it won't see  changes that are made in the archive
(e.g., if a revision -- even a  spelling correction -- is made
to an old entry); to do that it either  has to walk back the
*entire* archive each time, or the feed has to  publish all
changes -- even to old entries -- at the head of the feed.



These are the kinds of things my “hub archive feed” situation was
supposed to address. Because the links are all in one place, the
consumer only has to suck down one document in order to be
informed of all archive feeds and being able to decide which ones
he wants to re-/get.


I wonder if what you are trying to describe here is not a different
concept altogether from an archive feed. I guess that both are  
completely

orthogonal concepts.

Feeds tend to specialize in a number of resources they track. What would
also be useful would be a document that  described the resources   
tracked by a
feed. This would be closer to a directory listing. It would help  
point to the

current state of the resources tracked by the feed.

So when one subscribed to a feed one could then quickly get a list of  
all
the resources that the feed had responsibility for. As this could be  
quite large
some form of navigation may be necessary. Perhaps this is the type of  
thing

that the protocol group is working on.

Henry Story



Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>