A Syndication Project
Example Use Cases
This URL: http://www.iangraham.org/projects/news/uses.html
Created: 18 September, 2000
Last Update: 22 September, 2000
Author(s): Ian Graham, Benet
Who are the people who would work with the syndicatated data, and how would
they work with it? These ideas are fleshed out in this document, which
summarizes the nature of the actors who would work with the syndicated
data, and the scenarios by which they would interact with this data. THis
helps us understand what a syndication system needs to be able to do -- and
which a syndication language must support.
Rough List of Actors, and their Roles
- writer -- a person (or software) that prepares write information to
be included as syndicated data in a syndication message. Writer must thus
include any data explicitly needed by the syndication format.
- aggregator -- a person or software system that may aggregate pieces
of data and make they available for syndication. This data might be pushed to
consumers (after assembly) on a subscription basis, might be pre-packaged for
subsequent downloading (by a consumer) or it maybe built on the fly subject to
a request by a consumer.
- consumer -- a person or software system that consumes information
provided by an aggregator, and uses that data in some way. Typical ways that a
consumer would obtain data include:
Note that a consumer can also be an aggregator. That
is, a consumer can access data from an aggragator, and then re-aggregate that
data and make it available to different consumers.
- by requesting a specific data (or set of items) item based on a single
identifier for that item (or set of items)
- by requesting a 'most recent' version of a specific data item (or set of
items) based a single identifier for that item (or set of items)
Examples of Types of Data Likely to be Syndicated
- Brief summaries of news articles, with references to 'source' news
site (as commonly done with RSS).
- Complete text of a news article. This data may be in various
different XML-related news formats, such as NITF, XMLNews, or in other non-XML
- Public Event listings. Essentially public calendaring information
to be shared amongst different public calendars.
- Site summary information. Metadata describing content of a site,
with referenes to the 'source' of the content. (as commonly done with RSS)
- Web site content pages. For possible replication of content between
- Binary data files (maybe Web site content).
Really Rough Use Cases
Level 0 Use Cases
By "Level 0" we mean that minimal set of use cases needed for syndication to
be possible. Our intention is to design a data model that satisfies Level 0
requirements, but leaves room for future extensions
- Writer authors data for syndication. Application must ask the
author for sufficient additional metadata so that the syndication messages can
be constructted successfully.
- Aggregator assembles data for syndication. Assembly tool must be
able to extract (or otherwise obtain) enought inforamtion about each piece of
data being assembled to construct a correct syndication message.
- Aggregator includes aggregated data from another aggregator in the
assembled data. The assembly tool must be able to encode this relationship, so
that the consumer will know where the different parts of the messages
originally come from.
- Aggregator drops expired data aggregated from elsewhere. The
assembly tool must know when such data has exipred, and should no longer be
- Consumer requests a specific data item. The consumer must have both
an appropriate unique identifier for the data item, plus some understanding of
how to obtain that data item.
- Consumer requests a most-recent version of a specific data item or
an entire aggregated message. The consumer must have an appropriate identifier
for the data item or the entire message, plus some understanding of how to
- Consumer checks to see when data should be updated. The consumer
must know if there is an expiry date (or update interval) for the data it has
- Consumer hides data during interval when aggregator says data should be
kept hidden . The consumer must know when each piece or aggregated data
should 'go public', and when it should be kept hidden.
- Consumer filters each piece of data based on rating scheme (PICS).
The consumer must know the rating scheme for the data blocks it has received.
- Consumer filters each piece of data based on human language . The
consumer must know the human-readable language for the data blocks it has
- Consumer filters each piece of data based on data type of the data
. The consumer must know the data type of the data blocks it has received.
- Consumer contacts aggregator with questions about the aggregation
process used to create the data source the consumer has received. Consumer
must have appropriate contact information for the aggregator
- Consumer contacts aggregator to request more complex services
(e.g., registers for automatic updating if a new version of an indicated
article is released; query the aggregator for a set of articles; etc.) The
consumer must know how to contact a software interface to the aggregator, and
must know how to find the API for that interface.
NOTE: The nature of
that interface and advanced services is outside the scope of a syndication
Level 1 Use Cases
These are 'likely' use cases but ones that are either not likely to be needed
first out, or whose implementaion is unclear, due to external constraints/
requirements. For example, authenticating a resource requires a working XML
digital signature technology, and this is only now being developed
- Consumer checks authenticity of aggregation messages. Consumer must
know location of signature authority it can check with, and must know how to
check the messages for authenticity.
- Consumer organizes/sorts data based on metadata. Consumer must
be able to retrieve appropriate metatdata relevant to each data item. Typical
metadata would be keyword lists, or category specifications