Question: Are recommendations available or in progress for a type of standardized API communication?

0 views
Skip to first unread message

Daniel Parker

unread,
May 5, 2008, 12:27:04 PM5/5/08
to DataPortability.Action.Technical
My question requires a brief explanation and then some background.

Explanation: Once a number of sites are loyally following all of the
DataPortability standards and recommendations (whichever parts are
relevant to each), the problem that arises is that even with the data
portable and the data in open formats (xml, json, etc), the next step
is still not standardized: the request "language." What I mean is that
different sites will implement their API differently -- use different
query-string key names and interpret their values differently. Yes,
simple type-formats exist, like the standard way to display datetime
in xml, but what I mean is the language for one site to, in a standard
way, know how to "get what I want" from the other site. None exist in
my knowledge.

Background: In the past there have been several formats introduced to
represent specific types of information. vCard, ical, and rss are
examples. vCard and ical formats are distinctly for representing
contact data and calendar data, respectively; and rss is distinctly
for representing time-based or timeline-based information. It is
understandable that we can't create a standard format for each type of
data that exists in the world, as we come up with new ones every day.
But imagine if a person could go to a site that doesn't do
calendaring, but it can integrate its operations with whatever online
calendaring application the user wants to, even if it was a calendar
app that released yesterday, because it follows standards
recommendations on how to communicate about its data. Anything that
works with data as objects can operate by the same language. What I
mean by language is _probably_ just query-string terminology.

I'm just wondering if there are any projects related to this thought,
or if there have been related discussions; or if this sparks any
interests. The key thought is that even after data is portable, it's
not truly portable until one site can make valuable use of data from
another site even without having seen the site before.
Reply all
Reply to author
Forward
0 new messages