The project is to decisively shift power from the geeks and admins to the producers and consumers of media. In this its about good UI and simple empowering #KISS tools to move content by categorising it with a bootum up folksonermy. This simple approach is balanced by shared site level higher languages for the complex crew.
āThis is the Internetā
GET
PUT
POST
DELETE
āMERGEā
This Odata is the #4opens #OMN project.
People can get involved at a level they feel they can add to the project to reshape there world.
Consuming content
* simply on a portal/app (aggregation top site/app)
* on there own site as a sidebar or page.
* as a part of an admin team on a middle/bootem site
*
Producing content
* from a feed from there own site or #dotcons account
* writing linking articals as a part of a top/middle/bootm site
*
Aggravating content
* as a embed on there own site
* on a bootem/middle/top site
*
For the geeks the project is based on #4opens protocols
1) For bringing legacy content in ā RSS
2) For talking to the fedivers ā Activertypub
3) And for internal working – OData
Lets look at the last:
OData fundamentals (from https://blogs.sap.com/2018/08/20/monday-morning-thoughts-odata)
OData is a protocol and a set of formats. It is strongly resource oriented, as opposed to service oriented. There are a small fixed number of verbs (OData operations) and an infinite set of nouns (resources) upon which the verbs operate. These OData operations map quite cleanly onto the HTTP methods
OData operation |
HTTP method |
C ā Create |
POST |
R ā Read |
GET |
U ā Update |
PUT |
D ā Delete |
DELETE |
Q ā Query |
GET |
If something is important enough it should be addressable in that elements should have addresses, not hidden behind opaque web services endpoint. In the case of an HTTP protocol like OData, these addresses are URLs. And the shape of the data can be seen in the way those URL addresses are made up.
OData goes back further than you might think, its a grassroots project.
TThe protohistory of OData
ODataās origins go back to 1995, with the advent of the Meta Content Framework (MCF). This was a format that was created by Ramanthan V Guha while working in Appleās Advanced Technology Group, and its application was in providing structured metadata about websites and other web-based data, providing a machine-readable version of information that humans dealt with.
A few years later in 1999 Dan Libby worked with Guha at Netscape to produce the first version of a format that many of us still remember and perhaps a good portion of us still use, directly or indirectly ā RSS. This first version of RSS built on the ideas of MCF and was specifically designed to be able to describe websites and in particular weblog style content ā entries that were published over time, entries that had generally had a timestamp, a title, and some content. RSS was originally written to work with Netscapeās āMy Netscape Networkā ā to allow the combination of content from different sources (see Spec: RSS 0.9 (Netscape) for some background). RSS stood then for RDF Site Summary, as it used the Resource Description Framework (RDF) to provide the metadata language itself.
Atom. Like RSS, the key to Atom was the structure with which weblog content was described, and actually the structure was very close indeed to what RSS.
An Atom feed, just like an RSS feed, was made up of some header information describing the weblog in general, and then a series of items representing the weblog posts themselves:
header
Ā item
Ā item
Ā ...
A few years later, in 2005, the Atom format became an Internet Engineering Task Force (IETF) standard, specificallyĀ RFC 4287, and became known as the Atom Syndication Format:
āAtom is an XML-based document format that describes lists of related information known as āfeedsā. Feeds are composed of a number of items, known as āentriesā, each with an extensible set of attached metadata. For example, each entry has a title.ā
What was magic, though, was that in addition to this format, there was a fledgling protocol that was used to manipulate data described in this format. It was first created to enable remote authoring and maintenance of weblog posts ā back in the day some people liked to draft and publish posts in dedicated weblog clients, which then needed to interact with the server that stored and served the weblogs themselves. This protocol was the Atom Publishing Protocol, āAtomPubā or APP for short, and a couple of years later in 2007 this also became an IETF standard,Ā RFC 5023:
āThe Atom Publishing Protocol is an application-level protocol for publishing and editing Web Resources using HTTP [RFC2616] and XML 1.0 [REC-xml]. The protocol supports the creation of Web Resources and provides facilities for:
- Collections: Sets of Resources, which can be retrieved in whole or
in part.
- Services: Discovery and description of Collections.
- Editing: Creating, editing, and deleting Resources.ā
Is this starting to sound familiar – OData is exactly this ā sets of resources, service discovery, and manipulation of individual entries.
AtomPub and the Atom Syndication Format was adopted by Google in its Google Data (GData) APIs Protocol while this IETF formalisation was going on and the publish/subscribe protocol known as PubSubHubbub (now called WebSub) originally used Atom as a basis. And as we know, Microsoft embraced AtomPub in the year it became an IETF standard and OData was born.
Microsoft released the first three major versions of OData under the Open Specification Promise, and then OData was transferred to the guardianship of theĀ Organization for the Advancement of Structured Information Standards (OASIS) and the rest is history.
Something that humans could understand, as well as machines. The resource orientation approach has a combination of simplicity, power, utility and beauty that is reflected in (or by) the web as a whole. One could argue that the World Wide Web is the best example of a hugely distributed web service.
OData has constraints that make for consistent and predictable service designs ā if youāve seen one OData service youāve seen them all. And it passes the tyre-kicking test, in that the tyres are there for you to kick ā to explore an OData service using read and query operations all you need is your browser.
Have a quick look at an OData service. The Northwind service maintained by OASIS will do nicely. Have a look at the service documentĀ and, say, the Products collection.


Excerpts from the service document and from the Products collection
Notice how rich and present Atomās ancestry is in OData today. In the service document, entity sets are described as collections, and the Atom standard is referenced directly in the āatomā XML namespace prefix. In the Products entity set, notice that the root XML element is āfeedā, an Atom construct (we refer to weblog Atom and RSS āfeedsā) and the product entities are āentryā elements, also a direct Atom construct.
Todayās business API interoperability and open standards are built upon a long history of collaboration and invention.
Food for thought #OMN
Nourishment for action