3 http://dret.net/lectures/publishing-spring08/ SIMS INFO 290-19 2008 S 2008-01-24 2008-05-08 Professor EW Erik Wilde dret@berkeley.edu Office +1-510-6432253 http://dret.net/netdret/ LG

Web-Based Publishing refers to making available any information that is made accessible through a Web-Based Service. Thus, Web-based publishing refers to any publishing process that is based on Web technologies, but not necessarily as a delivery technology. Web-based publishing can also use non-Web technologies as a delivery platform, for example the new proprietary Rich Internet Applications (RIA) platforms Adobe Integrated Runtime (AIR) or Microsoft Silverlight, or mobile platforms such as Android or OpenMoko. There are two main differences between information systems built around Web-based publishing, and other approaches. The first difference is that the standards used for communicating between the delivery platform and the back end are open and widely deployed technologies, which makes it easy to find and use tools, developers, and reusable components. The second difference is that because of the flexibility of the involved technologies, such a scenario is ideally suited to implement easily adaptable multi-channel publishing platforms, which can aggregate and publish information from and to a large variety of different information sources and consumers.

LEC Th 08:30:00 10:30:00 110 South Hall 2008-01-01 dret 2008-01-24 XML · Web Web-Based Publishing refers to making available any information that is made accessible through a Web-Based Service. Thus, Web-based publishing refers to any publishing process that is based on Web technologies, but not necessarily as a delivery technology. Web-based publishing can also use non-Web technologies as a delivery platform, for example the new proprietary Rich Internet Applications (RIA) platforms Adobe Integrated Runtime (AIR) or Microsoft Silverlight, or mobile platforms such as Android or OpenMoko. There are two main differences between information systems built around Web-based publishing, and other approaches. The first difference is that the standards used for communicating between the delivery platform and the back end are open and widely deployed technologies, which makes it easy to find and use tools, developers, and reusable components. The second difference is that because of the flexibility of the involved technologies, such a scenario is ideally suited to implement easily adaptable multi-channel publishing platforms, which can aggregate and publish information from and to a large variety of different information sources and consumers.

• Projects in the fields , , and
• Regular meeting time reserved for project work
• presentations about related work (research, projects, products)
• presentations about project plans and issues
• discussion of project plans and issues
• One fixed meeting slot per group per week
• discussion of project plans and issues
• assignment of presentations
• Overall workload should be 6-8h per week

• Final
• presentations which briefly present the project results
• reports which describe the project and its results in greater detail
• Grade is based on:
• 30% presentations during the semester
• 30% final project presentation & report
• 40% project results

• Place Markup Language (PlaceML) for describing locations
• places can be described geographically (coordinates)
• places can be described with metadata (descriptions)
• place descriptions can be structured
• What applications can use place descriptions, and how?
• creating, editing, managing, and sharing location information
• connecting location-enabled devices with location descriptions
• In many cases location information can be mashed up
• combined with other information such as map data from map services
• integrated into other environments (Facebook or OpenSocial)

• Data linking on the Web is rudimentary
• HTML has some primitive support in the document head
• microformats describe special-purpose links (e.g., to a license)
• The Semantic Web has stifled the development of the plain Web
• anything that can be done on the Web can be done on the Semantic Web
• adoption is still non-existent outside of closed communities
• Links are good, following links is good
• XLink is the Web's generalized linking language
• XLink is badly designed, underspecified, and unpopular
• a new link format must be accompanied by an access protocol

• Feeds are widely used to publish and reuse itemized information
• RSS and Atom provide formats for publishing feeds
• AtomPub is a format for providing write access to a feed
• Managing feeds currently is a manual process
• server configuration and not accessible through an API
• Feed descriptions are information items and can be put into a feed
• Feed Feeds is feed metadata managed using feeds
• Standardized formats support distribution and sharing of information
1. a feed feed server manages feed descriptions and supports AtomPub interactions
2. feed publishers can manage and publish their feed through a publisher interface
3. feed consumers can manage and share their feed subscriptions

• Applications should ship data, not code
• REST-based back-ends can support any kind of interface
• shipping code is very client-specific and should be avoided
• Applications should focus on the service perspective
• how to deliver a service that can be easily used by others
• how to describe the service's data model for potential users
• how to control access and authenticate service users
• If possible, other services should be integrated
• if you need authentication, why not use OpenID?
• if you need social networking, why not use OpenSocial?
• if you need location, why not use Fireeagle?

• Rich Internet Applications are based on the idea of a smarter client
• Ajax applications ship JavaScript code for modern browsers
• Flash applications ship ActionScript code for flash players
• ActiveX applications ship Windows components for IE
• RIAs should be built on top of a RESTful service
• standard services will provide XML-based interactions
• Ajax-specific services may provide JSON representations
• Service and RIA should be completely separated
• if required, the service can be provided as an API
• if required, alternative UIs (e.g., purely Web-based) can be implemented

• Computer Science at Technical University of Berlin (TUB) (88-91)
• Ph.D. at ETH Zürich (92-97)
• Post-Doc at ICSI, Berkeley (97/98)
• book on Technical Foundations of the World Wide Web
• Various activities back in Switzerland (98-06)
• teaching at ETH Zürich and FHNW
• working as independent consultant (training, courses, consulting)
• research in various XML-related areas
• Visiting Assistant Professor at the School of Information (since fall 2006)
• Web and XML courses in fall 2007
• technical director of the Information and Service Design (ISD) program

• Course Web page: http://dret.net/lectures/publishing-spring08/
• Course mailing list: subscribe at majordomo@ischool.berkeley.edu
• no subject (leave blank)
• body of message: subscribe wbp
• Letter grade based on presentations and course project (results and presentation)

• Generated from XSLidy XML
• Designed for online presentation and use (lots of links!)
• for printing, use a (all slides), and then s (smaller font) a couple of times
• A good real-world example for Web-based publishing
• Slidy is useful, but there is no support for structures and hyperlinking
• XSLidy adds these features by adding an XSLT transformation
• XSLidy is useful, but there is no interface (XML editing only)

• My Online Glossary at http://dret.net/glossary/
• suggestions, updates, corrections are very welcome (really!)
• another exercise in how to use XML and XSLT for information management
• My bibliography at http://dret.net/biblio/
• suggestions, updates, corrections are very welcome (really!)
• produced by an XML-centric system for managing bibliography data
• The World Wide Web Consortium (W3C)
• headed by Tim-Berners Lee, inventor of the Web (with Robert Cailliau)
• The Internet Engineering Task Force (IETF)
• mainly Internet standards, but also responsible for URIs and HTTP

• Create a project description until next week
1. context, goals, and non-goals of the project
2. deliverables in one-month phases (i.e., 3 phases)
3. your project will be graded based on these goals!
• Next week we will discuss and assign projects
• If you don't have a project idea, just ask me …

2008-01-31 This week has a short introduction to Mantis, the issue tracking system that will be used for the course projects. Following this brief introduction, course projects will be discussed. The two projects are the Map Mapper project, which looks at ways to make map service URI interoperable across various services, and the Feed Feeds project, which is based on the idea of providing support for managing feed metadata. Both projects have back-end and front-end issues, and this course will mostly look at the front end issues.

• Often used as a bug tracking system for software development
• Issues are anything which needs resolution
• bugs in an existing implementation
• requests for a feature which should be added
• ideas for future features which should be captured
• Issue tracking is not chatting
• please do not have conversations using the system
• each issue and each note should have substance to it
• Try to resolve issues to the point where they can be closed

• Users get a login and have access to the application
• Each installation can have multiple projects
• users have access to the projects which are public or open to them
• Each project has a list of issues
• the category describes which part of a project an issue is for
• the severity describes how important the issue is
• the status tracks an issue through its lifecycle (until it is closed)
• Categories identify well-defined parts of a project
• issues entered for a category are assigned to a default user
• issue assignment can be changed manually at any time
• Adding notes to an issue can be done in two ways
• just adding a note without changing its status
• changing its status and then adding the note which describes the status change
• Issues can be monitored to get emails about activities

• Map URIs are specific to some map service
• they identify a location, but the location is hidden in the URI
• Location is becoming an important concept on the Web
• most services are silos for location information
• technically, this is caused by a lack of location support of the Web
• economically, this is caused by the services' interest to serve ads
• ideally, location on the Web should be identified by URI: geoloc:86.507942,28.031139
• Map Mapper allows users to switch between map services
• as a Greasemonkey script it can dynamically rewrite map URIs
• as a Firefox add-on it could add some configuration interface
• the add-on could also rewrite the URI of the current page (map switching)

• Implement the mapping as a JavaScript library
• should be relatively easy (regexes supported in JavaScript)
• currently, the processing model is only implicitly defined (but that will change)
• Use the JavaScript library in a Greasemonkey script
• easy testing of the library on the client side
• no UI but maybe configuration through customized code
• Use the JavaScript library in a Firefox add-on
• better integration into the browser
• UI for service preference or choice between one or all services
• mapping could also be applied to the address bar (map switching)
• Mapping table hardcoded into the script/library or loaded dynamically?

• Implement the mapping of URIs as a Web-based service
• Part of the Web-Based Services Course
• Greasemonkey and Add-On could also use such a service
• Server-side implementation has always the latest mapping table
• Mapped URIs could be collected
• statistics about map service usage
• statistics about map URI parameter usage (extract extra infos for statistics only?)

• Feed usage is already substantial and rising
• Feeds are information on demand
• Feed management on the publishing side is non-existent
• some platforms provide support, but there is no independent service
• Feed management on the consumer side happens in feed readers
• lock-in to feed reader and no sharing of feed data with others
• inability to easily switch between feed readers
• Feed Feeds are feeds containing feed metadata (i.e., meta-feeds)
• allows reuse of existing technologies and tools for handling feeds
• enables easy tracking of feed information by subscribing to a meta-feed
• publishing of feed information can be supported through AtomPub

• Feed publishers often have little support for managing feed information
• if they use a single platform, there may be some support for feed management
• in heterogeneous scenarios, managing feed information becomes very hard
• The Feed Feed Web Service provides feed metadata management
• the Web service can be accessed through its Atom/AtomPub interface
• an additional UI allows the manual management of feeds (categorization)
• additional features include generating views (directories) of feed feeds
• Feed publishers gain better control over their feeds
• better access for their customers to find certain feeds
• better understanding of the dependencies of feeds (aggregates/filters)

• Feed consumers use a feed reader for feed management
• feed readers are limited in capabilities and device support
• feed subscriptions should be managed in an open way
• Feed feeds for consumers should be like del.icio.us for feeds
• tagging of feeds and exploring the usage of feeds by others
• feed-specific features allow to link the feed URI with the resource URI
• tag-specific research can be applied to feed-specific tag spaces
• Information be publishers and consumers can be combined
• publishers get immediate feedback about tags, subscriptions, and collateral feeds
• consumers get information about the publishing context of the feed

• The first weeks should be mainly about thinking about design
• Thinking about implementation informs the design
• Use cases make design & implementation more realistic
• Discussions help when making design & implementation decisions

2008-02-28 Spec · Atom Landscape Atom is a read-only format for publishing entries and entry metadata in a feed. The Atom Publishing Protocol (AtomPub) is built on top of Atom for providing a protocol for submitting new entries to feeds. AtomPub introduces the concept of a collection, which is the set of entries which are managed through AtomPub and can be published as an Atom feed. AtomPub clients can add new entries to a collection using HTTP interactions, and AtomPub supports entries which are based on some XML format, as well as any other type of entry (such as images).

• Early Web content was static or updated very infrequently
• there was not yet the requirement to reuse content in different contexts
• Frequently updated Web content quickly became a very common scenario
• as commercial interests took over the Web, users should have a reason to re-visit a site
• presenting a steady stream of new content creates the image of a live Web site
• There are two major use cases where HTML is not sufficient
1. users want an efficient way to get the updated content from a site
2. sites want to aggregate updated content from other sites and re-publish it
• Syndication formats are designed to support these two use cases
• container formats for updated items
• a small amount of metadata about these items for automated processing

• LiveJournal (very simple text-based protocol)
• text-oriented protocol encoding the message in name/value-pairs
• very hard to adapt to any structure more complex than sets of flat values
• Blogger (now at Google after Google bought Pyra)
• no support for titles or any other sort of entry metadata
• protocol from the early days of blogging before tagging became popular
• MetaWeblog (an attempt to improve Blogger)
• extends Blogger using a very bad design (RSS XML as XML-RPC structure encoded as XML)
• Atom Publishing Protocol (AtomPub) is an attempt to provide a clean alternative
• use the same document structures for feeds and the protocol interacting with them
• use a REST approach to provide a simple and Web-compatible protocol
• add and for additional tasks

• Atom is a format for retrieving a set of entries as a feed document
• feeds often are time-based and are refreshed periodically or whenever needed
• feeds can use any other strategy for deciding what to publish
• Read-only access to feeds should be complemented by full access
• full access needs the CUD out of the CRUD set of operations
• many Web-centric technologies try to build on the Web's REST model of interaction
• AtomPub builds on Atom and adds a REST-based protocol on top of it
• POST for creating new entries (sending the request to the collection)
• PUT for updating existing entries (overwriting the existing entry)
• DELETE for deleting entries from a collection

• AtomPub's top-level concept is a workspace
• workspaces are used to group collections
• AtomPub makes no assumptions about how workspaces are managed
• AtomPub's core concept is the collection
• collections are used for managing and organizing resources
• Atom feed documents are representations of collections
• Members of a collection can be entry and media resources
• entry resources represent metadata+data and are represented as Atom entries
• media resources can have any media type and are the data described by entries
• a media link entry is a metadata entry associated with a media resource

POST /edit/ HTTP/1.1
Host: media.example.org
Content-Type: image/png
Slug: The Beach
Content-Length: nnn

...binary data...

HTTP/1.1 201 Created
Date: Fri, 7 Oct 2005 17:17:11 GMT
Content-Length: nnn
Content-Type: application/atom+xml;type=entry;charset="utf-8"
Location: http://example.org/media/edit/the_beach.atom

<?xml version="1.0"?>
<entry xmlns="http://www.w3.org/2005/Atom">
  <title>The Beach</title>
  <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
  <updated>2005-10-07T17:17:08Z</updated>
  <author><name>Daffy</name></author>
  <content type="image/png" src="http://media.example.org/the_beach.png"/>
  <link rel="edit-media" href="http://media.example.org/edit/the_beach.png" />
  <link rel="edit" href="http://example.org/media/edit/the_beach.atom" />
</entry>

Resource	HTTP Method	Representation	Description
Introspection	GET	Atom Service Document	Enumerates a set of collections and lists their URIs and other information about the collections
Collection	GET	Atom Feed	A list of member of the collection (this may be a subset of all entries in the collection)
Collection	POST	Atom Entry	Create a new entry in the collection
Member	GET	Atom Entry	Get the Atom Entry
Member	PUT	Atom Entry	Update the Atom Entry
Member	DELETE	n/a	Delete the Atom Entry from the collection

Service Documents represent server-defined groups of Collections, and are used to initialize the process of creating and editing resources.

• The real top-level construct of AtomPub is the workspace
• collections on a server are organized into different workspaces
• workspaces have no AtomPub semantics and no operations can be performed on them
• Service documents list constraints on the members of collections
• accept specifies a comma-separated list of media ranges (with entry as special value)
• categories defines the list of categories that can be applied to members (can be fixed)
• AtomPub servers are likely to reject operations not satisfying these constraints
• AtomPub does not specify a way how to discover service documents

• Categories are important for creating and reading entries
• they may contain metadata using any classification scheme
• contain a list of allowed categories
• the categories may be embedded or they may be available elsewhere
• AtomPub defines a document format for standalone category documents
• a useful interface between AtomPub systems and other systems using classification schemes
• AtomPub makes no assumptions beyond categories as a controlled vocabulary
• applications may choose to use more elaborate models (taxonomies, thesauri, ontologies)
• managing and exposing this more complex structure is beyond the scope of AtomPub

• AtomPub is designed around Atom's very basic model of feeds and entries
• Atom is strict on extensibility and allows extensions of various kinds
• AtomPub supports Atom's extensibility and also allows extensions
• Atom's built-in bias also is part of AtomPub's bias
• time is the primary key for managing and accessing entries
• authentication and authorization are treated as orthogonal issues
• AtomPub can be extended by adding new modules
• AtomPub can be extended by adding features and repackaging it

• Collections often support more than the basic AtomPub features
• draft-snell-atompub-feature proposes a generic method for supporting feature discovery
• Collections may contain f:features elements for indicating supported features
• AtomPub servers can also publish separate feature documents
• these documents then can be referred to from multiple collections
• Features are not described, they are only identified
• features are identified by URI and feature descriptions simply list URIs
• URIs may or may not help in finding descriptions of features

• Atom and AtomPub have no explicit indication about removed entries
• if an entry is removed, it will not be part of the feed anymore
• draft-snell-atompub-tombstones proposes a mechanism for representing deleted entries
• Deleted entries appear as special entries in a feed
• at:deleted-entry elements represent deleted entries in a feed
• Feeds may contain links to feed that are used for managing deleted entries
• the trash relation allows a feed to link to a trash feed
• This proposal introduces well-defined ways for deleting and undeleting feed entries

• Google's GData provides access to many Google services
• based on AtomPub (and thus Atom) and allows AtomPub interactions with GData services
• extends AtomPub with features such as queries, batch operations, and authentication
• uses some of the OpenSearch fields for returning search results
• Google provides code for various programming languages
• mostly client libraries, available in Java, .NET, PHP, Python, Objective-C, and JavaScript
• GData's query format allows queries based on Atom's core metadata

http://www.example.com/feeds/jo/-/Fritz

http://www.example.com/feeds/jo/-/Fritz/Laurie

http://www.example.com/feeds/jo/-/Fritz%7CLaurie

http://www.example.com/feeds/jo/-/Fritz/-Laurie

• LocAtomPub extends Atom and AtomPub to become location-aware
• Locations can be lat/long geolocations or place names
• Atom needs to be extended to support location
• GeoRSS does something similar but is restricted to geolocation
• LocAtomPub allows locations to be physical or symbolic
• AtomPub needs to be extended to support location vocabularies
• uploading geolocation entries is a simple feature (optional or required)
• location vocabularies can be seen as equivalent to
• there has to be a well-defined format for defining location vocabularies
• AtomPub needs to be extended to support queries
• querying based on categories is supported by as well
• querying by location needs a more expressive query model

• AtomPub extends Atom with a protocol for posting entries
• AtomPub is limited in its capabilities
• supports Atom's very basic metadata vocabulary
• no well-defined support for collection hierarchies
• does not scale very well for posting large numbers of entries
• Extensibility can solve some of these limitations

2008-05-08 ...