decentralized use cases

hello.

i am wearing my "WG member hat" right now, not my "WG co-chair hat".

coming from the REST background, i am still struggling a bit to understand
an important aspect of building a platform, and so far my questions
regarding this have not created a lot of feedback. therefore i am still
curious and interested to get some answers or maybe just comments or
opinions. building a platform means it is something that others can build
on. REST has two central aspects how it makes sure that no bad things can
happen, and that things scale well:

- service interactions transfer state, not raw data. while state is of
course data, it is different, because in most scenarios it means the
transfer of intent, and not of raw facts. if i order something, i transfer
my order intent, and if that order is accepted by the service, it will be
transformed into whatever that service uses to internally represent a
factual order (and how that service does that is none of my business). the
service might give me access to my pending/completed orders, but again
that's state info, and better be cleaned of information about other
customers' orders, as well as internal info that i am not supposed to see
(such as an internal ratings how much a service values me as a customer).
so services decouple the service surface from the implementation
internals, and that's crucial in many scenarios. coupling between service
clients and providers happens on the service surface level, not at the
level of how a service manages data.

- state transfer is based on expectations about what is being transferred,
and often this means there are schemas and there is validation. schemas
are the first line of defense, they are a declarative way of formalizing
what a service expects to happen in the context of service interactions.
in many cases, schemas are half-formal and half-informal, and often they
also are contextual (a loose schema is accepted when i submit something, i
can expect a strict schema when i get a response because the service has
performed some cleanup). as a side-note, schematron has a nice way of
handling this through the notion of "phases", something that other schema
languages could learn from... without schemas, REST services become almost
impossible to define, because they are needed to encode the
"preconditions" and "postconditions" in all service interactions. if those
conditions aren't met, there are standardized ways (such as HTTP status
codes) to signal that disagreement happened on that interaction level.

these two mechanisms are the building blocks of REST in terms of isolating
a platform's surface from its internals, and from the feedback so far it
seems that the majority of the WG is in favor of going the route that andy
described so well as a "shared, schemaless database." what i am struggling
with is to reconcile the notion of that database approach, and a platform,
which for me is something that implicitly means decentralized settings and
trust relationships which do not necessarily imply complete and unlimited
access to a service's database. i'd really appreciate if somebody could
attempt to explain to me what i am missing. is it just that complete trust
is implicitly assumed and REST's protective measures are not needed?

the concrete reason i am asking is that we are very interested in using
linked data as a platform, but we also cannot go the route of a shared
database model. we must have control over what a linked data platform
exposes and what it does not expose, and we must have control over who can
add what and when to a linked data platform. these are the questions we
need to solve, and i am still trying to figure out how to best solve those
questions in the context of this WG.

thanks and cheers,

dret.

Received on Thursday, 12 July 2012 08:34:06 UTC