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
