Re: New Link Relations -- Ready to go?
+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 atom-syntax@imc.org Subject: Re: New Link Relations -- Ready to go? +1 to all
Re: New Link Relations -- Ready to go?
Tim Bray wrote: On Oct 20, 2005, at 4:52 PM, Mark Nottingham wrote: - Attribute Value: subscribe I'm puzzled by this one. I thought that if you wanted to subscribe to a feed then, well, you would subscribe to a feed. I must have missed the discussion. Could someone provide a pointer to the archive? -Tim The idea being that if you were to come across an archived Atom document (however that might happen), the presence of this link would, (a) let you know that it was an archive document and thus shouldn't be subscribed to, and (b) provide you with a URL with which you could subscribe to the actual feed if you so chose. For reference, see here (end of the message): http://www.imc.org/atom-syntax/mail-archive/msg17202.html Also this thread (discusses the fh:archive element which served a similar purpose): http://www.imc.org/atom-syntax/mail-archive/msg16724.html Regards James
Re: New Link Relations -- Ready to go?
On Oct 21, 2005, at 7:38 AM, James Holderness wrote: The idea being that if you were to come across an archived Atom document (however that might happen), the presence of this link would, (a) let you know that it was an archive document and thus shouldn't be subscribed to, and (b) provide you with a URL with which you could subscribe to the actual feed if you so chose. Makes sense, but not self-evident. I would think that the usefulness of this thing would be improved by a few words of explanation for those who come upon it without knowing the history. -Tim
Re: New Link Relations -- Ready to go?
* Eric Scheid [EMAIL PROTECTED] [2005-10-21 17:05]: It was thought that the 'self' link in an archive would point to the archive document itself, which meant a different relationship was needed for the purpose of locating the URI which is the one that contains the most recent updates/entries. I admit I intentionally kept out of that discussion because I don’t have a lot of personal interest in the subject, and the thread has been so fast and furious I didn’t bother staying on top of it just because. But I’d like to offer some thoughts on this particular point; apologies in advance if these points have already been raised: First, rel=self is going to be implemented by most everything that groks Atom 1.0 in order to support one-click subscription, if applicable, right? Whereas this new relationship might not find such wide-spread support. Second, although less important – even applications which do support rel=subscribe will have to implement a fallback behaviour. Arguably, they already do in some fashion, because a feed may omit the rel=self link, so I don’t know if this is such a pressing issue. For these two (similar) reasons I think it might be wise to keep rel=self in the role that this new rel=subscribe thing is supposed to fulfill, and invent a new relationship that can point to the canonical location of the archive feed document. Third, and in some ways most importantly, I see overlap with Bob Wyman’s “preferred feed” agenda from way back when: http://www.imc.org/atom-syntax/mail-archive/msg15001.html Does anyone remember that? Maybe it would be wise to opt for something slightly more generic that can express semantics useful for feed scenarios other than archives? Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: New Link Relations -- Ready to go?
A. Pagaltzis wrote: * Eric Scheid [EMAIL PROTECTED] [2005-10-21 17:05]: It was thought that the 'self' link in an archive would point to the archive document itself, which meant a different relationship was needed for the purpose of locating the URI which is the one that contains the most recent updates/entries. I admit I intentionally kept out of that discussion because I don’t have a lot of personal interest in the subject, and the thread has been so fast and furious I didn’t bother staying on top of it just because. But I’d like to offer some thoughts on this particular point; apologies in advance if these points have already been raised: First, rel=self is going to be implemented by most everything that groks Atom 1.0 in order to support one-click subscription, if applicable, right? Whereas this new relationship might not find such wide-spread support. Most aggregators supporting self-based subscription are going to use it to allow the UA to subscribe to the *current* document. In other words, if the user is looking at an Archive feed, the self-subscription mechanism will lead the user to subscribe to the archive document. With subscribe, the UA is given a hint as to where the actual subscription document is located. Second, although less important – even applications which do support rel=subscribe will have to implement a fallback behaviour. Arguably, they already do in some fashion, because a feed may omit the rel=self link, so I don’t know if this is such a pressing issue. For these two (similar) reasons I think it might be wise to keep rel=self in the role that this new rel=subscribe thing is supposed to fulfill, and invent a new relationship that can point to the canonical location of the archive feed document. -1. self always points to *this* document and is only usable for subscribing to *this* document. You cannot use it to point to a separate document. - James
Re: New Link Relations -- Ready to go?
Thomas Broyer wrote: Mark Nottingham wrote: - Attribute Value: previous - Description: A URI that refers to the immediately preceding document in a series of documents. This definition doesn't prevent someone from using this link relation for linking within a series of documents representing, say a webring, where previous and next will be other sites' feeds. I really think we should make it clear that first/previous/next/last are meant for paging of a single feed only. I'll try to propose a replacement text. -1. I see no reason to limit this to paging of a single feed. - James
Re: New Link Relations -- Ready to go?
On 22/10/05 1:33 AM, A. Pagaltzis [EMAIL PROTECTED] wrote: First, rel=self is going to be implemented by most everything that groks Atom 1.0 in order to support one-click subscription, if applicable, right? Whereas this new relationship might not find such wide-spread support. I believe we're in a moment of grace right now and we could, with a bit of public advocacy, get 'subscribe' established and supported for one-click subscription. For these two (similar) reasons I think it might be wise to keep rel=self in the role that this new rel=subscribe thing is supposed to fulfill, and invent a new relationship that can point to the canonical location of the archive feed document. This occurred to me too, but I had my reservations about it. http://www.imc.org/atom-syntax/mail-archive/msg17284.html where I wrote: Fortunately, the link relation 'self' was defined in such a woolly way we could get away with re-purposing it. A few articles here or there, a bit of blog chatter, and the arrival of the fabled Developers Guide and we'd be set. I'd think this would be favourable to having to come up with a different pair of relations, like 'self' = what you subscribe to, may not look anything like the chunk in front of you 'this-chunk' = link to what you are looking at, not to be confused with 'self' e.
Re: draft-snell-atompub-feed-license-03.txt
All, Just wanted to clue y'all in on this conversation. The Atom extension drafts listed below entered an Unofficial last call state about three weeks ago. As of today I'm declaring these stable and will not be making any further changes on them unless a) significant bugs/problems are found or b) the Atom protocol works stretches out beyond the expiration date of the current drafts. Once the Atom protocol work is complete, I will submit these as standards track RFC's as per Scott's preference stated in the notes below. http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-license-03.txt http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-expires-05.txt (will publish soon on the IETF lists) http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-nofollow-03.txt (will publish soon on the IETF lists) Thanks to everyone who submitted feedback on these. - James -Original Message- From: James M Snell [mailto:[EMAIL PROTECTED] Sent: Friday, October 21, 2005 12:21 PM To: Scott Hollenbeck Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: draft-snell-atompub-feed-license-03.txt This is fine. There really is no risk on this particular extension with the protocol draft but your suggestion sounds like good general practice. For now I'll settle for informally declaring that the specs are stable and waiting for the primary work on the protocol to complete. Thanks! :-) Scott Hollenbeck wrote: Frankly I'd prefer to wait on documents like this until after atompub completes both the format and protocol documents. I realize that there isn't a normative dependency on the protocol document, but I'd really prefer to be sure that it stays that way. You can try to convince me that there's no risk if you wish. The normal process, though, is for you to try to convince an AD to shepherd your work. You can also send it directly to the RFC Editor if you wish, but they will then ask the IESG if there are any potential conflicts or overlaps with existing IETF work. In short, it'll take longer. The AD then reviews the document, we deal with the review, and a 4-week last call is requested. The doc goes through IESG evaluation after the last call, just like a working group document does. -Scott- -Original Message- From: James M Snell [mailto:[EMAIL PROTECTED] Sent: Friday, October 21, 2005 11:57 AM To: Hollenbeck, Scott Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: draft-snell-atompub-feed-license-03.txt Hello Scott, Over the past couple of months I have been developing a number of extensions to Atom. I believe that a couple of these are ready to move forward as standards-track RFC's as individual submissions. The first is draft-snell-atompub-feed-license-03.txt [1]. This spec defines a new license link relation than can be used to associate copyright licenses (e.g. creative commons) with Atom feeds and entries. Feedback on the spec has been received from members of the Atompub WG and from folks from Creative Commons and the larger XML developer community mostly through direct feedback to me. If everything looks acceptable to you, what is the next step on moving this forward as a standards track rfc? - James [EMAIL PROTECTED] [1] http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-l icense-03.txt
Unofficial Last Call - draft-snell-atompub-feed-index-03.txt
As of today I am issuing an unofficial last call on the Feed Rank extension http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-index-03.txt This extension introduces a numeric ranking mechanism for Atom entries that can be used to order entries according to relative significance. Please review the spec and provide comment back to the Atom syntax list. In two weeks I will review the feedback, make any appropriate changes, then work towards declaring the spec stable. Once the Atom Protocol work is complete, I will submit the stable version of the draft as a standards track RFC. Thanks! - James
Re: New Link Relations -- Ready to go?
James M Snell a écrit : Thomas Broyer wrote: Mark Nottingham wrote: - Attribute Value: previous - Description: A URI that refers to the immediately preceding document in a series of documents. This definition doesn't prevent someone from using this link relation for linking within a series of documents representing, say a webring, where previous and next will be other sites' feeds. I really think we should make it clear that first/previous/next/last are meant for paging of a single feed only. I'll try to propose a replacement text. -1. I see no reason to limit this to paging of a single feed. How would you use these link relations for feed state reconstruction (that is, automatic handling by the Atom processor, without user action –except probably the please reconstruct this feed's state action) if you can't know what's pointed at? How would you navigate through a paged search result (e.g. OpenSearch result feed) if previous/next might point at previous/next queries (e.g. history of what people searched for before you) or previous/next pages of the result feed? How would you disambiguate between two next link on pointing at the next chunk of a paged feed and the other pointing at the next archived feed? (e.g. August Top 100, page 2 and September Top 100) I thought we all agreed that we need a specific definition (related to paging) of these relations and were previously voting about how to call them (previous or prev-archive) -- Thomas Broyer
Re: New Link Relations -- Ready to go?
Thomas Broyer wrote: How would you use these link relations for feed state reconstruction (that is, automatic handling by the Atom processor, without user action –except probably the please reconstruct this feed's state action) if you can't know what's pointed at? How would you navigate through a paged search result (e.g. OpenSearch result feed) if previous/next might point at previous/next queries (e.g. history of what people searched for before you) or previous/next pages of the result feed? How would you disambiguate between two next link on pointing at the next chunk of a paged feed and the other pointing at the next archived feed? (e.g. August Top 100, page 2 and September Top 100) I thought we all agreed that we need a specific definition (related to paging) of these relations and were previously voting about how to call them (previous or prev-archive) I wouldn't disambiguate them as I don't believe it's necessary to. What's needed is a way of identifying the role|purpose|intent of a feed; not a way of disambiguating the links between them. An archive feed should be treated differently than a search feed which should be treated differently than a subscription feed. - James
Unofficial Last Call - draft-snell-atompub-feed-thread-04.txt
All, At some point over the next couple of days, a slightly modified version of the comments extension draft [1] will be published. The moment it publishes will kick off a two week Unofficial Last Call period for the spec. The spec has been stable of the past two months with no major issues raised. Please review the draft. After two weeks I will review any received feedback and, if appropriate, cut a new draft which will become the stable version. After the Atom Protocol work completes, I will submit the stable version of the draft as a standards track RFC. - James [1] draft-snell-atompub-feed-thread-03.txt (current version) [2] draft-snell-atompub-feed-thread-04.txt (new version waiting to publish... no significant changes)
Re: New Link Relations -- Ready to go?
James M Snell wrote : Thomas Broyer wrote: How would you use these link relations for feed state reconstruction (that is, automatic handling by the Atom processor, without user action –except probably the please reconstruct this feed's state action) if you can't know what's pointed at? How would you navigate through a paged search result (e.g. OpenSearch result feed) if previous/next might point at previous/next queries (e.g. history of what people searched for before you) or previous/next pages of the result feed? How would you disambiguate between two next link on pointing at the next chunk of a paged feed and the other pointing at the next archived feed? (e.g. August Top 100, page 2 and September Top 100) I thought we all agreed that we need a specific definition (related to paging) of these relations and were previously voting about how to call them (previous or prev-archive) I wouldn't disambiguate them as I don't believe it's necessary to. What's needed is a way of identifying the role|purpose|intent of a feed; not a way of disambiguating the links between them. An archive feed should be treated differently than a search feed which should be treated differently than a subscription feed. So you are OK with these feeds: GET /top50.atom HTTP/1.0 Host: music.example.net 200 OK Content-Type: application/atom+xml Content-Location: /top50/2005/w42/1.atom feed xmlns=http://www.w3.org/2005/Atom; titleWeek #42 Top 50/title subtitleTop 50 best selling singles/subtitle link rel=self href=http://music.example.net/top50/2005/w42/1.atom; / link rel=subscribe href=http://music.example.net/top50.atom; / link rel=previous title=Week #41 Top 50 href=http://music.example.net/top50/2005/w41/1.atom; / link rel=next title=Week #42 Top 50 (11th to 21st) href=http://music.example.net/top50/2005/w42/2.atom; / fh:incremental xmlns:fh=…false/fh:incremental … GET /top50/2005/w42/2.atom HTTP/1.0 Host: music.example.net 200 OK Content-Type: application/atom+xml feed xmlns=http://www.w3.org/2005/Atom; titleWeek #42 Top 50 (11th to 20st)/title subtitleTop 50 best selling singles/subtitle link rel=self href=http://music.example.net/top50/2005/w42/2.atom; / link rel=subscribe href=http://music.example.net/top50.atom; / link rel=previous title=Week #41 Top 50 href=http://music.example.net/top50/2005/w41/1.atom; / link rel=previous title=Week #42 Top 50 (1st to 10th) href=http://music.example.net/top50/2005/w42/1.atom; / link rel=next title=Week #42 Top 50 (21st to 31st) href=http://music.example.net/top50/2005/w42/3.atom; / fh:incremental xmlns:fh=…false/fh:incremental … GET /top50/2005/w41/1.atom HTTP/1.0 Host: music.example.net 200 OK Content-Type: application/atom+xml feed xmlns=http://www.w3.org/2005/Atom; titleWeek #41 Top 50/title subtitleTop 50 best selling singles/subtitle link rel=self href=http://music.example.net/top50/2005/w41/1.atom; / link rel=subscribe href=http://music.example.net/top50.atom; / link rel=previous title=Week #40 Top 50 href=http://music.example.net/top50/2005/w40/1.atom; / link rel=next title=Week #42 Top 50 href=http://music.example.net/top50/2005/w42/1.atom; / link rel=next title=Week #41 Top 50 (11th to 21st) href=http://music.example.net/top50/2005/w41/2.atom; / fh:incremental xmlns:fh=…false/fh:incremental … How do you expect a newsreader to *automatically* download this week's 50 entries without downloading last week's entries instead? (and show you links/buttons for you to ask download and display of previous/next week's Top 50) -- Thomas Broyer
Re: New Link Relations -- Ready to go?
Thomas Broyer wrote: James M Snell wrote : Thomas Broyer wrote: So you are OK with these feeds: Yes, they all look good to me. You didn't answer my last question: How do you expect a newsreader to *automatically* download this week's 50 entries without downloading last week's entries instead? (and show you links/buttons for you to ask download and display of previous/next week's Top 50) Ah, didn't see the last question ;-) My choice would be for it to not automatically download 'em. Just present the user with the available links and let 'em follow the ones they want. - James
Application for addition to Atom Registry of Link Relations
The following is an application for a link relation value, as specified in the Atom Syndication Format. https://datatracker.ietf.org/public/idindex.cgi?command=id_detailfilename=draft-ietf-atompub-format https://datatracker.ietf.org/public/idindex.cgi?command=id_detailfilename=draft-ietf-atompub-format Thank you - James Snell == Registry == http://www.iana.org/assignments/link-relations == Attribute Value == license == Description == http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-license-03.txt == Display Characteristics == http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-license-03.txt == Security Considerations == http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-license-03.txt
Sponsored Links and other link extensions
Ok, now that a number of the other extensions I've been working on are
moving along, it's time to turn my attention to a couple of other ideas
I've been stewing on. One of which is link[rel=sponsored] to indicate
sponsored links / advertisements within feeds.
link rel=sponsored
href=http://someone.is.paying.for.me.to.put.this.here; /
The reason for not using rel=related here is to provide consumers a
clear distinction between links that are truly related to the entry vs.
links included as advertisements.
A feed, entry or source may contain any number of rel=sponsored links.
Further, many links can be augmented with graphics and extended
descriptions, for this purpose, I am considering a couple of new
extension elements that would be children of atom:link
link rel=sponsored href=...
x:image type=.../x:image
x:documentation type=text|html|xhtmlSome basic documentation
about the link/x:documentation
/link
The x:image element would specify the URI of an image file (aspect ratio
of 2:1) associated with the link. The type attribute specifies the
media type of the image.
The x:documentation element is an Atom text construct similar to
atom:summary. I would have just reused atom:summary but given that the
core spec does not expressly allow for atom:summary within atom:link, I
felt doing so would be problematic. The purpose of x:documentation is
to allow an extended, human-readable description of the link to be provided.
In another direction, I've thinking about how to allow links to express
specific information about the resource being linked so that either a)
modifications of the resource can be detected or b) specific versions of
the resource can be referenced.
link rel=enclosure href=...
x:md5={hash}
x:etag={entity tag}
x:last-modified={http date} /
The values of each attribute corresponds to an equivalent HTTP header.
Lastly, a while back Eric Scheid and I discussed a bit about how
alternate locations for a link could be expressed (e.g. mirrors). He
was going to write up a draft, but I'm not sure about the status of that
effort. Here's what I'm thinking:
link rel=enclosure href... ...
x:alternate href=... title=... /
x:alternate href=... title=... /
/link
Each x:alternate identifies an alternative URL for the link resource.
The media type, length, hreflang, etc are all expected to be the same
for each alternate. The x:md5.x:etag, and x:last-modified attributes
from above could be used.
Thoughts? Gripes? Praise?
- James
Re: Application for addition to Atom Registry of Link Relations
Antone Roundy wrote: The following two bits seem incompatible with each other: o atom:entry, atom:feed and atom:source elements MUST NOT contain more than one 'license' link relation with the same combination of type and hreflang attribute values. Note the caveat, with the same combination of type and hreflang attribute values. The idea is to prevent a single license from being appearing more than once. Multiple license link relations MAY be used to indicate that the informational content has been published under multiple copright licenses. In such instances, each of the linked licenses is considered to be mutually exclusive of the others.
Profile links
Another subject that has come up in recent discussions is an extension that can be used to specify the purpose of a feed. For example, is the feed an archive, is it a podcast, is it used for discovering web services or publishing blog content, etc. The approach that I have in mind is to use link[rel=profile] where the href points to a profile document of some sort. For example, feed ... entry link rel=profile href=http://example.com/profiles/podcast; / link rel=profile href=http://example.com/profiles/weblog; / ... /entry /feed The profile documents could be anything really, but generally describe the kinds of metadata and content that the entry is expected to contain. For instance, the podcast profile could indicate that the entry should contain at least one link[rel=enclosure]. Any single entry may contain multiple profile links. It is up to the feed consumer to make sense of it all. If an entry specifies contradictory profiles, it's up to the consumer to sort it out. The profile documents should be dereferenceable. Thoughts? Gripes? Praise? - James
Re: What is this entry about?
James M Snell wrote: Ok, so thus far: we can indicate resources that are related to the given entry; we can indicate that an entry is a reply to another entry; we can specify categories to which the entry belongs; but there is currently no way of indicating the *subject* of the entry. The best options appear to be: a. Use dc:subject (appears to be a perfectly acceptable solution to me assuming that the subject indication is intended for human consumption entry dc:subjectThe Atom Specification/dc:subject /entry or... b. Use link[rel=subject] (which works if the subject is identified/described by a dereferenceable URI) entry link rel=subject href=http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-11.txt; / /entry I think either approach works. The dc:subject approach is ambiguous. The link approach requires invention. The link approach doesn't seem to be less ambiguous than dc:subject. For lessened ambiguity you might want to use published subject indicators a la topic maps. cheers Bill
Re: New Link Relations -- Ready to go?
James Holderness wrote: Thomas Broyer wrote: You didn't answer my last question: How do you expect a newsreader to *automatically* download this week's 50 entries without downloading last week's entries instead? (and show you links/buttons for you to ask download and display of previous/next week's Top 50) I see where you're coming from, but this kind of thing is already a problem without even taking links into consideration. For an aggregator to be able to do anything vaguely meaningful with a feed it has to be able to assume that the feed is incremental in nature. As I already explained, paging is orthogonal to the incremental nature of a feed. An incremental feed will be chunked as explained in Mark's current Feed History draft (just use an atom:[EMAIL PROTECTED]previous] instead of the fh:prev extension element) and a non-incremental feed as described in the OpenSearch result 1.1 draft. The difference is that an incremental feed is sorted by date so the older parts will become more or less stable over time; while a non-incremental feed is replaced as a whole each time it is updated, with no other relation to time. When the feed is updated an aggregator will by default assume that any new items can safely be added to the top of an inbox, any updates are updates to existing items, and any removed items have merely fallen off the bottom of the feed. However, as soon as we introduce the concept of non-incremental feeds, an aggregator that is not aware of the concept will fail to process such a feed in a meaningful way. We've created a situation where an aggregator has to be aware of the (still to be specified) fh:incremental extension, Microsoft's simple list extensions for RSS, and whatever future extensions may arise; basically the ability to see into the future. This problem merely repeats itself when it comes to processing archives. When we receive a next link, ideally we would like to assume it's a pointer to the next archive to be processed. For a regular incremental feed this isn't a problem. Even a search feed could be processed safely if ordered the right way. However, when it comes to non-incremental feeds we're screwed again. I agree that it sucks, but we're already stuck with that situation so I'm not sure that these links will make things any worse. What's the difference between a search feed and a non-incremental feed? Aren't search feeds one facet of non-incremental feeds? The difference between incremental and non-incremental feeds is that, when dealing with incremental feeds, paging can be seen as a link to archives, as the feed is tightly related to time. When dealing with non-incremental feed, the previous page is totally different than the previous archived snapshot. However, an incremental feed could take advantage of differentiating between paging and archive linking: if linking to archives uses an atom:[EMAIL PROTECTED]archives] (or call it history if you prefer) to point at an incremental feed where each entry describes an archived set of entries (see [1] for a more detailed example); such a feed has the advantage of paging that it allows direct access to a specific point of time inside the feed pages. Each archived set of entries could for example cover one or two week, so a user could navigate through the feed state or feed history not only by going from pages to pages but also by accessing archived chunks via an index or table of contents. -- Thomas Broyer
Re: New Link Relations -- Ready to go?
Thomas Broyer wrote: However, an incremental feed could take advantage of differentiating between paging and archive linking: if linking to archives uses an atom:[EMAIL PROTECTED]archives] (or call it history if you prefer) to point at an incremental feed where each entry describes an archived set of entries (see [1] for a more detailed example); such a feed has the advantage of paging that it allows direct access to a specific point of time inside the feed pages. Each archived set of entries could for example cover one or two week, so a user could navigate through the feed state or feed history not only by going from pages to pages but also by accessing archived chunks via an index or table of contents. Sorry, forgot the link: [1] http://www.imc.org/atom-syntax/mail-archive/msg17308.html -- Thomas Broyer
Re: What is this entry about?
Bill de hÓra wrote: The link approach doesn't seem to be less ambiguous than dc:subject. For lessened ambiguity you might want to use published subject indicators a la topic maps. It is less ambiguous in that a URI is less ambiguous that some arbitrary text string. Further, the link approach is perfectly compatible with the published subject indicators a la topic maps approach. - James
Re: What is this entry about?
James M Snell wrote: Bill de hÓra wrote: The link approach doesn't seem to be less ambiguous than dc:subject. For lessened ambiguity you might want to use published subject indicators a la topic maps. It is less ambiguous in that a URI is less ambiguous that some arbitrary text string. Further, the link approach is perfectly compatible with the published subject indicators a la topic maps approach. There's no requirement to use an arbitrary text string in dc:subject*. And even then, I have no idea how a URL (you did say these things had to be dereferenced) is less ambiguous than a string - they're equally arbitrary unless we're talking about their use in something like OWL. The link approach still doesn't seem to be less ambiguous than dc:subject, ie it does not seem to be a basis for choosing one over the other. cheers Bill * The dc:subject value is recommended to be taken from some controlled set. The @rel=subject idea doesn't say anything about the link being a PSI. The link approach is perfectly compatable then with PSIs insofar as you would have some other interpretation that lookups the URIs and sees if they're actually PSIs, or not.
Re: New Link Relations -- Ready to go?
That's what I was trying to do here: - Description: A URI that refers to a feed document containing a set of the most recent entries in the feed. This URI is intended to be subscribed to to keep abreast of recent changes in the feed. When different from the URI of the document where it occurs, it indicates that its value should be used for this purpose in place of the current document's URI. Any suggestions? On 21/10/2005, at 8:19 AM, Tim Bray wrote: On Oct 21, 2005, at 7:38 AM, James Holderness wrote: The idea being that if you were to come across an archived Atom document (however that might happen), the presence of this link would, (a) let you know that it was an archive document and thus shouldn't be subscribed to, and (b) provide you with a URL with which you could subscribe to the actual feed if you so chose. Makes sense, but not self-evident. I would think that the usefulness of this thing would be improved by a few words of explanation for those who come upon it without knowing the history. -Tim -- Mark Nottingham http://www.mnot.net/
Re: Profile links
James M Snell wrote:
Another subject that has come up in recent discussions is an extension
that can be used to specify the purpose of a feed. For example, is the
feed an archive, is it a podcast, is it used for discovering web
services or publishing blog content, etc.
The approach that I have in mind is to use link[rel=profile] where the
href points to a profile document of some sort.
For example,
feed
...
entry
link rel=profile href=http://example.com/profiles/podcast; /
link rel=profile href=http://example.com/profiles/weblog; /
...
/entry
/feed
The profile documents could be anything really, but generally describe
the kinds of metadata and content that the entry is expected to
contain. For instance, the podcast profile could indicate that the
entry should contain at least one link[rel=enclosure].
Any single entry may contain multiple profile links. It is up to the
feed consumer to make sense of it all. If an entry specifies
contradictory profiles, it's up to the consumer to sort it out.
The profile documents should be dereferenceable.
Thoughts? Gripes? Praise?
I think you're proposing to enable a kind of Atom microformat - if you
see profile ?x check for ?a ?b and ?c. Sorting it out on consumer
sounds flaky ('sounds', not 'is'), but this also might be very cool. I
wonder why you need a link to do this instead of foo:profile tag.
cheers
Bill
Re: Application for addition to Atom Registry of Link Relations
On 22/10/05 4:48 AM, James M Snell [EMAIL PROTECTED] wrote: Note the caveat, with the same combination of type and hreflang attribute values. The idea is to prevent a single license from being appearing more than once. Multiple license link relations MAY be used to indicate that the informational content has been published under multiple copright licenses. In such instances, each of the linked licenses is considered to be mutually exclusive of the others. but the second bit of text suggests that the following is allowable: link rel=license href=pay-me-for-commercial-use / link rel=license href=barter-for-commercial-use / link rel=license href=free-for-non-commercial-use / which is a situation which should be allowable (IMHO), and so the restriction should be removed: o atom:entry, atom:feed and atom:source elements MUST NOT contain more than one 'license' link relation with the same combination of type and hreflang attribute values. e.
Re: New Link Relations -- Ready to go?
On Oct 21, 2005, at 3:13 PM, Mark Nottingham wrote: - Description: A URI that refers to a feed document containing a set of the most recent entries in the feed. This URI is intended to be subscribed to to keep abreast of recent changes in the feed. When different from the URI of the document where it occurs, it indicates that its value should be used for this purpose in place of the current document's URI. Any suggestions? Yes. Acknowledge the specific case of an archival feed, an example is worth a thousand words. And discuss why this exist when Atom already has link rel=self, specifically designed to support auto-subscribe. -Tim
Re: Profile links
Bill de hÓra wrote:
I think you're proposing to enable a kind of Atom microformat - if you
see profile ?x check for ?a ?b and ?c. Sorting it out on consumer
sounds flaky ('sounds', not 'is'), but this also might be very cool. I
wonder why you need a link to do this instead of foo:profile tag.
Precisely. Yes, sorting everything out on the client does *sound*
flaky, but we're not introducing any new problem here. XHTML
microformats have the same problem.
Regarding the use of a link versus foo:profile, I really have no
preference one way or the other. The profile reference should be a
dereferencable link to a profile document that describes the profile
but, for the most part, clients will likely only rarely ever dereference
it (using the href more as an identifier). Strictly speaking,
dereferenceable profile links should probably use the atom:link element
but there is no hard requirement that says a profile element wouldn't
also work.
- James
Re: What is this entry about?
* James M Snell [EMAIL PROTECTED] [2005-10-21 21:25]: Ok, so thus far: we can indicate resources that are related to the given entry; we can indicate that an entry is a reply to another entry; we can specify categories to which the entry belongs; but there is currently no way of indicating the *subject* of the entry. The best options appear to be: a. Use dc:subject (appears to be a perfectly acceptable solution to me assuming that the subject indication is intended for human consumption or... b. Use link[rel=subject] (which works if the subject is identified/described by a dereferenceable URI) Err, are you forgetting atom:category? Doesn’t that satisfy all your wants *and* more? It has a URI, a term and a human-readable label. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: New Link Relations -- Ready to go?
So, an aggregator comes across a feed in the woods. It sees it has previous and maybe next link relations. The point that (I think) Thomas is making is that the people who leave that feed document in the woods had better be comfortable with the aggregator following the links and reconstructing the feed. After all, most of them already keep feed history without any hints about previous archives at all; if you give them a previous link, it'll be a red flag to a bull, no matter what my spec says. So, a feed that used next and previous to link to different weeks of the top 100 (for example) would get jumbled up pretty bad, and not display too well in aggregators. My thinking is that if we go down this road, one of two things will happen; a) Aggregators will start paying attention to special flags (like fh:incremental) that tell them the nature of the feed, and feeds will start using them real quick. b) Non-incremental uses of previous and next will die off, because people who use them for those purposes will see aggregators do strange things with their feeds. I think (b) is somewhat more likely. Either way, I'm OK, but I do note that (a) leads to two separate extensions being required in the feed, when the same purpose could be served by a more specialised link relation, and (b) will lead to other, more specialised link relations being created anyway. So I'm not sure why it's so important we have an effectively semantic- free previous and next, but if that's what happens, I'm reasonably confident my use case will still be met. So, Thomas -- are you still -1 on this? I don't see how we can come to consensus on a more specific set of relations, given the flood of +1s on the generic ones. On 21/10/2005, at 2:23 PM, Thomas Broyer wrote: James Holderness wrote: Thomas Broyer wrote: You didn't answer my last question: How do you expect a newsreader to *automatically* download this week's 50 entries without downloading last week's entries instead? (and show you links/buttons for you to ask download and display of previous/next week's Top 50) I see where you're coming from, but this kind of thing is already a problem without even taking links into consideration. For an aggregator to be able to do anything vaguely meaningful with a feed it has to be able to assume that the feed is incremental in nature. As I already explained, paging is orthogonal to the incremental nature of a feed. An incremental feed will be chunked as explained in Mark's current Feed History draft (just use an atom:link [EMAIL PROTECTED]previous] instead of the fh:prev extension element) and a non-incremental feed as described in the OpenSearch result 1.1 draft. The difference is that an incremental feed is sorted by date so the older parts will become more or less stable over time; while a non-incremental feed is replaced as a whole each time it is updated, with no other relation to time. When the feed is updated an aggregator will by default assume that any new items can safely be added to the top of an inbox, any updates are updates to existing items, and any removed items have merely fallen off the bottom of the feed. However, as soon as we introduce the concept of non-incremental feeds, an aggregator that is not aware of the concept will fail to process such a feed in a meaningful way. We've created a situation where an aggregator has to be aware of the (still to be specified) fh:incremental extension, Microsoft's simple list extensions for RSS, and whatever future extensions may arise; basically the ability to see into the future. This problem merely repeats itself when it comes to processing archives. When we receive a next link, ideally we would like to assume it's a pointer to the next archive to be processed. For a regular incremental feed this isn't a problem. Even a search feed could be processed safely if ordered the right way. However, when it comes to non-incremental feeds we're screwed again. I agree that it sucks, but we're already stuck with that situation so I'm not sure that these links will make things any worse. What's the difference between a search feed and a non-incremental feed? Aren't search feeds one facet of non-incremental feeds? The difference between incremental and non-incremental feeds is that, when dealing with incremental feeds, paging can be seen as a link to archives, as the feed is tightly related to time. When dealing with non-incremental feed, the previous page is totally different than the previous archived snapshot. However, an incremental feed could take advantage of differentiating between paging and archive linking: if linking to archives uses an atom:[EMAIL PROTECTED]archives] (or call it history if you prefer) to point at an incremental feed where each entry describes an archived set of entries (see [1] for a more detailed
Re: New Link Relations -- Ready to go?
How about: - Description: A URI that refers to a feed document containing a set of the most recent entries in the feed. This URI is intended to be subscribed to to keep abreast of recent changes in the feed; when different from the URI of the document where it occurs, it indicates that its value should be used for this purpose in place of the current document's URI. For example, an archived feed document might contain a subscribe relation that points to the subscription feed's location, so that clients subscribe to the appropriate link. Note that the self relation was designed for a similar purpose, but is not suitable for that use in other feeds, whereas this relation can be used in those situations. On 21/10/2005, at 4:16 PM, Tim Bray wrote: On Oct 21, 2005, at 3:13 PM, Mark Nottingham wrote: - Description: A URI that refers to a feed document containing a set of the most recent entries in the feed. This URI is intended to be subscribed to to keep abreast of recent changes in the feed. When different from the URI of the document where it occurs, it indicates that its value should be used for this purpose in place of the current document's URI. Any suggestions? Yes. Acknowledge the specific case of an archival feed, an example is worth a thousand words. And discuss why this exist when Atom already has link rel=self, specifically designed to support auto-subscribe. -Tim -- Mark Nottingham http://www.mnot.net/
Re: What is this entry about?
On Oct 21, 2005, at 5:47 PM, James M Snell wrote: Err, are you forgetting atom:category? Doesn’t that satisfy all your wants *and* more? It has a URI, a term and a human-readable label. Regards, I dunno, that's why I was asking ;-) atom:category works well for categorizing entries, but does it really tell us what the entry is about? For instance, suppose that I want to indicate that an entry is about http://www.ibm.com and file that in a category called technology? The categorization of the entry is different than the subject of the entry.. tho both are definitely related. Why don't we define link/@rel=about for pointing to a specific internet resource that an entry is about (a little more specific than the general case of rel=related). I know we discussed this before and in the chaos of trying to hammer the spec out, didn't do it, but I still think it's a good idea.
Re: New Link Relations -- Ready to go?
Thomas Broyer wrote: As I already explained, paging is orthogonal to the incremental nature of a feed. An incremental feed will be chunked as explained in Mark's current Feed History draft (just use an atom:[EMAIL PROTECTED]previous] instead of the fh:prev extension element) and a non-incremental feed as described in the OpenSearch result 1.1 draft. I beg to differ. I think the incremental state of a feed is very relevant to paging. If the aggregator does not know that a feed is non-incremental it will not be able to process the feed document in a meaningful manner. And when I say non-incremental I mean something like a Top 10 list where the entries in the feed document are a complete replacement for any entries that the aggregator may have previously received from that feed. What's the difference between a search feed and a non-incremental feed? Aren't search feeds one facet of non-incremental feeds? Not necessarily, no. A search feed could quite easily be implemented as an incremental feed. This is the most sensible approach since it would allow the feed to be viewed in all existing aggregators without requiring a special knowledge of non-incremental feeds. The initial feed document consists of all known results at the time the search is initiated. As new results are discovered over time, the feed can be updated by adding new entries to the top of the feed in much the same way that new entries would be added to the top of a blogging feed. In fact, if you do a search with something like feedster, this is exactly the sort of feed you will get back. Once you add paging support, the search results can be split over multiple pages in much the same way that an incremental feed splits its entries over multiple archives. As long as the search feed adds new entries to the top of the subscribed document and moves older results into archives as they fall out the bottom, it can be processed in exactly the same way as a regular incremental feed. However, an incremental feed could take advantage of differentiating between paging and archive linking: if linking to archives uses an atom:[EMAIL PROTECTED]archives] (or call it history if you prefer) to point at an incremental feed where each entry describes an archived set of entries (see [1] for a more detailed example); such a feed has the advantage of paging that it allows direct access to a specific point of time inside the feed pages. Each archived set of entries could for example cover one or two week, so a user could navigate through the feed state or feed history not only by going from pages to pages but also by accessing archived chunks via an index or table of contents. This is all very interesting, but not possible without more link extensions which don't exist yet. With what we have so far we can do incremental feed archives; we can do at least some form of searching; we can do non-incremental feeds (of the Top 10 variety) with history. I think that's a good start. Regards James
Re: New Link Relations -- Ready to go?
On Oct 21, 2005, at 7:19 PM, James Holderness wrote: What's the difference between a search feed and a non-incremental feed? Aren't search feeds one facet of non-incremental feeds? Not necessarily, no. A search feed could quite easily be implemented as an incremental feed. This is the most sensible approach since it would allow the feed to be viewed in all existing aggregators without requiring a special knowledge of non- incremental feeds. If your goal is to work as well as possible with today's client software, then bending your data to fit their model is the most sensible approach, but that's not always the goal. The initial feed document consists of all known results at the time the search is initiated. As new results are discovered over time, the feed can be updated by adding new entries to the top of the feed in much the same way that new entries would be added to the top of a blogging feed. In fact, if you do a search with something like feedster, this is exactly the sort of feed you will get back. If creation time is relevant to the data being searched, then this makes sense. But what if I want to subscribe to the top 10 Google results for some keywords I'm trying to optimize my site for (ignoring the fact that Google doesn't return search results in any feed format right now)? Or what about alternative sort orders which are available on sites like Feedster, Google News, etc.? (You can sort by relevance rather than date--the date still has some weight, but the results aren't strictly in date order). How about Amazon.com affiliates who want to use an RSS parser to display affiliates links to best sellers search results? There are a lot of search use cases that don't fit the incremental model. All that said, search results are often a bit different than top 10 lists and the like. With search results, you often don't want to view the contents of the feed in order all at once--the first time you do, but after that, you may just want to see new things as they make it up into the top positions. Today's clients can handle that just fine, unless you want to monitor more than just the first page of results.
Re: Profile links
I'm not sure if I've understood you correctly, but if this could be used as a hint to the aggregator on how best to process/display the feed then I think it's a great idea. For example, knowing that a feed was a collection of images (e.g. a Flickr feed) would enable the aggregator to automatically display the entries as an image thumbnail list. A feed of calendar events (using a microformat of some sort) could be automatically added to the user's calendar. I'm sure there are many other ways in which this could be useful. My only worry is that without some kind of profile registry it would be very difficult for an aggregator to do anything meaningful with the data. Where would you find a list of all existing profiles? If there are 10 different profiles that all suggest more or less the same thing which one(s) should an aggregator support? Perhaps we could start with a predefined set of well-known profiles? I really think this idea has great potential though. Regards James James M Snell wrote: Another subject that has come up in recent discussions is an extension that can be used to specify the purpose of a feed. For example, is the feed an archive, is it a podcast, is it used for discovering web services or publishing blog content, etc. The approach that I have in mind is to use link[rel=profile] where the href points to a profile document of some sort.
Re: Profile links
James Holderness wrote: I'm not sure if I've understood you correctly, but if this could be used as a hint to the aggregator on how best to process/display the feed then I think it's a great idea. Yes, that's exactly what it's for. For example, knowing that a feed was a collection of images (e.g. a Flickr feed) would enable the aggregator to automatically display the entries as an image thumbnail list. A feed of calendar events (using a microformat of some sort) could be automatically added to the user's calendar. I'm sure there are many other ways in which this could be useful. My only worry is that without some kind of profile registry it would be very difficult for an aggregator to do anything meaningful with the data. Where would you find a list of all existing profiles? If there are 10 different profiles that all suggest more or less the same thing which one(s) should an aggregator support? Perhaps we could start with a predefined set of well-known profiles? That's precisely why I want the profile references to be dereferenceable into some form of profile document that can describe the profile. I considered a registry of profiles but wasn't sure if that was a good idea or not. Still stewing on it. I definitely think the definition of profiles needs to be a community effort, much like the way that the microformats community is working collaboratively to define microformat profiles. - James
Re: Sponsored Links and other link extensions
James M Snell wrote: Ok, now that a number of the other extensions I've been working on are moving along, it's time to turn my attention to a couple of other ideas I've been stewing on. One of which is link[rel=sponsored] to indicate sponsored links / advertisements within feeds. Not sure about this. Why would an aggregator display such a link? At best you might get an option in the aggregator asking whether the user wanted to see sponsored links, but then you have to ask yourself how many users would enable such an option. As a content provider I would be inclined to just slap them at the bottom of the message somewhere with a little header saying sponsored links. Not pretty, but at least you can be sure the links will be seen. Lastly, a while back Eric Scheid and I discussed a bit about how alternate locations for a link could be expressed (e.g. mirrors). He was going to write up a draft, but I'm not sure about the status of that effort. Here's what I'm thinking: link rel=enclosure href... ... x:alternate href=... title=... / x:alternate href=... title=... / /link I like this a lot. You get fallback support when a link goes down as well as the ability to download from multiple sources simultaneously for extra speed. For this to work, though, it's vital that these resources are bit-for-bit identical. If not I think they MUST include an x:md5 attribute so an aggregator can tell which are safe to interleave. Regards James
Re: Sponsored Links and other link extensions
James Holderness wrote: James M Snell wrote: Ok, now that a number of the other extensions I've been working on are moving along, it's time to turn my attention to a couple of other ideas I've been stewing on. One of which is link[rel=sponsored] to indicate sponsored links / advertisements within feeds. Not sure about this. Why would an aggregator display such a link? At best you might get an option in the aggregator asking whether the user wanted to see sponsored links, but then you have to ask yourself how many users would enable such an option. As a content provider I would be inclined to just slap them at the bottom of the message somewhere with a little header saying sponsored links. Not pretty, but at least you can be sure the links will be seen. I know, this basically comes down to a trust issue... that is, do you trust that aggregators and users will respect 'em. I'm not convinced either, but I wanted to at least float the idea. Lastly, a while back Eric Scheid and I discussed a bit about how alternate locations for a link could be expressed (e.g. mirrors). He was going to write up a draft, but I'm not sure about the status of that effort. Here's what I'm thinking: link rel=enclosure href... ... x:alternate href=... title=... / x:alternate href=... title=... / /link I like this a lot. You get fallback support when a link goes down as well as the ability to download from multiple sources simultaneously for extra speed. For this to work, though, it's vital that these resources are bit-for-bit identical. If not I think they MUST include an x:md5 attribute so an aggregator can tell which are safe to interleave. Good points. - James
