Re: decentralized use cases

hi erik,

When I described it as a "schema-less database" I wasn't imaging in it 
was a free-for-all.  There still needs to be validation on the way in 
and (data) security on the way out.

Posting a bug report may trigger the bug fixing process.  But there 
might also be a report generator that sees the same information and can 
describe the state of the software engineering process as "X red flags, 
Y fixes in the last 7 days" etc etc.  Two applications using the same 
data for different ends.  The advantage is that the bug fixing process 
does not need a reporting module, nor to know to send it on somewhere, 
as is required if a bug report is sent to the bug fixing process.  The 
reporting function can be added after the bug fixing process/app is 
deployed without disturbing the existing functionality.

The database is schema-less because any information can go in.  But that 
is not to say it is not validated - data still needs to be checked on 
the way in and access confirmed on the way out.  It's data security, not 
service security; WebID can part of the solution but the whole solution 
needs to consider who can see what.  This is hard; current 
infrastructure is oriented to service access control.

The schema-less-ness means whole new applications can be added without 
changing existing apps - you can add training courses and registration 
for them  without needing to change the bug fixing app or a reorg of the 
data.  It may also be "related but different" - adding requests for 
features or reports of deployments, that can link to bug reports.

This is especially easy in the LDP/submission because there is naming 
via containers to keep things apart but it can be done with single RDF 
database and rdf:type.

Re: REST

For me, REST is about a style of applications where everything is in the 
state exchanged including process flow.  There is no server-side state 
that can influence and operation; this gives scaling because any request 
can go to any server in a cluster.  It requires putting all the details 
state exchanged. This is the link following.  To take the ordering 
example, the response to the order placement contains a link to where 
the order status can be seen.

	Andy


On 12/07/12 09:33, Erik.Wilde@emc.com wrote:
> 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 Friday, 13 July 2012 10:01:49 UTC