Use Cases
The format should support today's weblog use cases at a minimum. Let's make sure this landscape is covered. See also EntryCatalog.
What are the different kinds of feeds that might exist (give existing examples if available)?
-
Weblogs
-
Single author
-
Multi-author weblogs
-
Photo blogs Picture Diary AlmostWordlessfotolog.net photoblogs.org More... (google search)
-
Mobile blogs Tokyo Tidbits
-
Audio blogs Harold Gilchrist Reverse Cowgirl More... (google search) Others... (google search)
-
Video blogs Devcon 2000 Multimedia Blogs audioviscereal.net
-
Combination photo/audio blogs ("snap and tell" - a photo supported by an audio description) Joi Ito's Moblog
-
Multimedia, interactive blogs LINKS PLEASE
-
Blogs in multimedia formats/combinations that don't yet exist?
-
Aggregated blogs (via ping or feed) Open Wiki - All The News Aggregation http://www.highcontext.com/kmpings/
-
Small news pointers (a link and brief description) fark Open Wiki - All The News Aggregation (these two look similar but differ in where the stories come from - one is user-submitted, the other is an aggregation of other feeds)
-
Event Watchers / System Generated Info
-
Wiki RecentChanges
-
CVS repository changelogs (e.g. cvs2rss)
-
Software Update notifications (e.g., Freshmeat, Source Forge, etc.)
-
Weather reports and Severe weather alerts openWeather
-
System event watchers (for that matter, event watchers in general)
-
MMORG (Massively Multiplayer Online Roleplaying Game) like Ultima Online/Everquest
-
Stock tickers
-
"Current" lists. (Lists of machines/networks and their status. Top Ten lists.)
-
Account statement (last few transactions on my bank account for example)
-
Corporate Info
-
Promotional Offers (see http://www.covacations.com/PromoRss/dealService.asmx/GetRss?)
-
Scheduling information for audio or video broadcasts (each item/entry is a different segment)
-
Corporate Communications (propaganda, white papers, job postings with appropriate metadata)
-
Transaction data from enterprise apps to feeds (see the ComponentBlog) and to enterprise apps from blog feeds (see AdaptiveBlogosphere for more).
-
Announcements
-
Political action alerts newsfeed
-
General Events (Conferences, Excibitions, Concerts, Gatherings, Parties)
-
Sporting events: box scores
-
Concerts, conferences or other types of event listings
-
Program listings (Radio / TV) See the ProgramlistingExampleFeed
-
Misc.
-
Review feeds
-
Threaded discussion (what about ThreadsML?) (comments for an individual log entry?)
-
Non-blog style content, e.g. a streamed novel
-
Aggregated content participating in a syndicate.
-
AAPP (Aggregate-Author-Process-(re)Publish
-
Pick and choose from the ICE use cases, a PDF linked from http://www.icestandard.org/servlet/RetrievePage?site=ice&page=specifications
-
Classified ad monitoring, real estate ad monitoring.
-
General database query results in response to a RESTful URI
-
BackUp. For every .html file on your blog, write a static .echo file. Portability guaranteed.
-
Graphical representation, e.g., IdeaGraph
Use Cases and Core
What use cases exercise the core of the ConceptualModel?
-
Single-author
-
usecase 1, describe here
-
usecase 2, describe here
-
etc..
-
Multi-author
-
Different formats
-
usecase 1, "actor wants to migrate to new blog tool" [We all know that making it easy for your users to leave is impossible to mandate, but it's in the interest of all weblog/newsfeed-related vendors to make importing a notEcho feed easy, ChristianCrumlish,RefactorAlwaysOk]
-
Varying entry ids and links
What use cases exercise the extensions?
-
Journalism-style feeds (heads, decks, etc)
-
Semantic Web Services - providing queryable data
Discussion
[ZhangYining RefactorOk] Not sure if relevant here, but one Use Case is posting/containing photos (or other forms of arts) in an Entry, a typical example might be a photojournalist who blogs a breaking news that has content and one or multiple illustrating photos. The question would be how to include non-text resources, jpg files in this case, in an Entry, should the weblogger upload jpg files to his home directory at her blog hosting server and reference them in content, or there is an extension mechanism to allow her to post them together with the Entry, or other methods? Whichever method is adopted, how should archiving and syndicating work for such blogs?
[ChrisWilper RefactorOk] No consensus yet on "weblogs only" vs. more innovative forms of syndication. IMO we need to decide which use cases it needs to support, and which might be supported later through extensions.
[DaveWarnock RefactorOk] I would like to be able to use it to provide feeds from VisibleResults our free fundraising software for charities. The uses would be a) end users getting news about fundraising projects (typical; RSS, no problem) b) managers tracking what is happening in the system (needs https and basic authentication, could be lot more than 15 items, might need a feed of feeds ie just a list of available feeds) c) trainers tracking what the people they are teaching are doing in the system (security) d) sysadmins checking logs/performance (security) e) public checking on changed to their own data (security).
I guess the key differences from standard blogging are security, much greater number of feeds, larger no of items in a feed, more rapid change of data into feed. But it would be good if there were also some support for a push model for the format, ie a desktop/server application that is fed each event as it happens rather than pulling at intervals.
[JoshJacobs RefactorOk] I'd like to see aggregators be able to 'spider' their way to a macro view of a topic, regardless of entry point. For example I go to a blog entry that references a post on another blog that is being responded to. The original post might in fact be a response to yet another post. Comments exist on multiple blogs, etc. From the point that I discovered the conversation I'd like to be able to tell my aggregator to pull together a more linear view of the conversation, and update it regardless of where new content comes from. This would essentially be a meta subscription, that I could archive for myself. I should have control over granularity (posts only, posts + comments, etc). The other benefit of this approach is that, as often happens, discussions may move between blogs over a period of time. I can respond with a comment to the latest post or comment without having to try to figure out where the current activity has shifted to.
Seperate thought, I think a lot of the discussion to far has been about what a post is, I hope the use case section will start to take on a lot more discussion about how users (as opposed to authors and tool vendors) want to interact with feeds. I'd love to see some of the aggregator vendors weigh in on cool feature ideas they've been unable to implement due to gaps in the available data sets. As Echo rolls out I'm of the belief that the ratio of pure readers, as opposed to authors/readers will be very high (think web browsers to HTML publishers), I think a lot more focus on how to take advantage of the dataverse to enable new user applications is really important. I guess in some ways I see the aggregators being far more important in this conversation than the blogging tools. This is entirely due to the fact that I don't blog, but I read extensively.
-
[AsbjornUlsberg, RefactorOk] This can be fairly easy to solve if we, as I've stated like 100 times now ;-), can nest <content> elements, and referr to external resources. If so, it's just to embed content into each other, and follow this path till it stops, or till you want it to stop.
-
[DavidNovalisTurner, RefactorOK] Along the same lines, there ought to be tools which choose the "best" items from one or more Echo feeds, and resyndicate them into a unified feed. Some concept of "origin" is needed for cases like this, so readers of the output feed can trace back to the original source. So, there's "repost of" and "responding to". RFC 2822 has similar concepts ("Resent-To" and "References"), so this isn't a new idea.
-
[AsbjornUlsberg, RefactorOk] Having a "parent" entry solves this one. I've provided two examples on how to do this in [CommentEntryExample]. Having more than one reference in each entry isn't necessary, as you would need to loop through the lot to get every entry's content, anyway. Hence, the "References"-header of e.g. NNTP isn't usable for us. But I agree with you. In those lines I would really like to be able to prioritize entries as well, maybe with a number from 1 to 6 where 1 is "breaking news" and 6 is "to whom it may concern" or something. This way we can easilly make prioritized, unified feeds, and in a better way organize our entries on front pages etc.
-
[DavidNovalisTurner, RefactorOK] It's often necessary to reference more than one post in a non-thread response context. For example, "Fred Bloggs claims that Echo is good, while Joan Webber disagrees. My feelings on this are mixed ..." Perhaps Joan isn't disagreeing with Fred specifically, but instead independently posting her own thoughts. So, there's no chain to follow. Of course, these sorts of references could simply be links in the content, but for fuller tool support, this sort of multiple reference would be helpful. Also, multiple reference in the NNTP style allows tools to work around broken links or deleted/altered posts by going further back in the chain. (I assume this is why NNTP does it).
-
[AsbjornUlsberg, RefactorOk] Multiple references can be made with an <annotate> element, as KellanElliottMcCrea describes in CommentEntryExample. I think the same solution for multiple comment references should be used for multiple views of an entry, as I explain in the Linkage thread.
[JoshJacobs RefactorOk] Does it make sense to have a separate discussion page for discussion of a subscription data structure? I can envision wanting to be able to leverage post data in defining my subscriptions. Simple use cases include providing credentials to retrieve personalized or secure feeds, if categories are supported I might want to filter categories at the subscription level, for multi-author blogs I might want to control which authors I see or exclude specific posters, etc.) I know that some of this can be done client side by the aggregator, but todays aggregators are using OPML as a subscription import/export format, and it seems appropriate to extend and preserve this capability. Not sure if this is out of scope for the project.
[DeaneBarker] I started a dicsussion (http://www.gadgetopia.com/archives/000699.html) about how you handle updates to entries (topics, posts, etc.). How do you get updates into an RSS feed? What is the "correct" practice for this? How do you aggregate many posts on the same topic to give a full view of THAT topic in a given blog? There are several comments n it at the above URL.
[AsbjornUlsberg, RefactorOk] One issue I would like to adress, but which I'm not sure is in the scope of Echo (at least not in v1.0), is that news broadcasters would like an easy interchange format that allows them to have control over copyrighted material. SOAP can of course be used, but RSS is already widely adopted, and it would therefore be easier for all news broadcasters to change to a similar, but new, RSS format, than to change to SOAP. Therefore we should look a bit into some handshake techniques, if it's not too difficult to solve. I know SOAP already has solutions for this, so we might just embed some of those into Echo.
I think it would be very useful to keep a subscription-list as a XML document on each site that offers some kind of feed, and then write a really simple interface (XML format + API) for how to get into such a subscription-list. When inside a list one can maybe classify what kind of information each subscriber should get, define different groups with different rights and such, but that's not important in the first place. As long as we define this subscription-mechanism, it should and can be easilly extended with a richer set of criterias and such afterwards.
-
[BrentRockwood, RefactorOk] I believe there has been discussion (at least among the REST folks) of letting the underlying protocol (ie. HTTP) handle the security.
[MaciejCeglowski] There's a small but significant group of bloggers who write posts in multiple languages Marysia Milonas, for example. Many readers in the States might want to filter her blog on English posts only - this is a use case that is not served by the format as I understand it right now.
-
[AsbjornUlsberg, RefactorOk] The xml:lang attribute serves that purpose. It's easy to filter on this attribute with selection languages like XPath.
[NickChalko RefactorOk] UseCaseNamingGuidelines. I recommend the pattern of "Name Use Case", all as one word of course.
[KenMacLeod, RefactorOk] I'm the one who put "LINKS PLEASE" on the use-case list. These types of sites appear to have or would have a VERY strong influence on the core conceptual model. These kinds of sites aren't in my blogroll, I don't know what sites to add. The examples we need are ones that exist today, so we can see how they work today, not proposals or ideas that we would need to invent solutions for.
-
[HaroldGilchrist, RefactorOk] Audio, video and photo blogs are not brand new blogging proposals or ideas. They are new weblog technologies (popular in last year) that in my opinion would probably benefit the greatest from ECHO standardized interoperability. They may not exist in your blogroll today in the same numbers as other type of mature weblog entries (so they won't be as easy to model as other mature feed entries) but these type of entries do exist today in weblogs html entries and will continue to grow. Again because these type of entries are new, the way they "work today" in feeds, APIs and interfaces is not standardized. ECHO needs to begin to address at some level, in the core, support for these existing weblog entries in feeds and in the APIs. For one, I already see the multiple content proposal as a feature that could be used by these type of entries.
[KenMacLeod, RefactorOk] I understand. But, please, at least more links. These are the sites we need to get in touch with to find out what their needs are. There's a huge question about whether Entry content needs a 'base64' binary encoding or content references. Some of us say, "well, of course we do, look at all those sites that could make use of it", and an honest reply would be "ok, cool, what sites?" The use-cases I didn't add "LINKS PLEASE" are simply the ones I think are well covered by current usage. It's the ones with "LINKS PLEASE" that are critical at the moment.
[HaroldGilchrist, RefactorOk] If your looking for an individual weblog that qualifies as an audioblog, my weblog "Audioblog/Mobileblogging News" at http://radio.weblogs.com/0100368/ does. I have been posting audio entries to my weblog for over a year (posted two audio entries this weekend). Hope that helps to explain my passion to have audioblogs, videoblogs, photoblogs and other multi-media files addressed at an open level playing field in syndication feed entries.
[AllenFirstenberg, RefactorOk] I just added the "current lists" item as an example of some resources that can use RSS now that wouldn't under the proposal to require a date stamp for every item. In these cases, each item would either have the same published date stamp, or would have date stamps that should not be used to indicate the ordering.
[BillSeitz] - while I think most blogging environments would make it easier to edit a BlogRoll, I think the bigger issue is how to identify them on front page [Containers] so that those links can be considered separately from the links in the list-of-latest-entries...
[AlexanderPayne + PhilLeif RefactorOk] Seconded: the syndication file/feed should include a reference to a BlogRoll (or another "related materials" list) owned by the blog's author. This would make finding blogrolls infinitely easier, and help to facilitate interconnection between blogs and their respective authors. In addition, this could provide a foundation for a reputation system.
Use Cases Tutorial