Re: "Basic profile" terminology ?

hello andy.

On 2012-07-09 16:41 , "Andy Seaborne" <andy.seaborne@epimorphics.com>
wrote:
>Looking at the UCR example of application integration, I think I see a
>style that a bit like a shared, schemaless database than as a designed
>set of services.

that's what i see, too. i completely see the value of that, but it can
only work in settings where there is collaboration and coordination. in
open settings, you need a protective services layer on top of it, so that
you can manage what you allow into your shared, schemaless database
(prevent conflicts and DOS), and what you allow out of it (comply with
regulatory and legislative requirements for private/protected data).

>Applications put data in (publish); other applications retrieve the data
>- but the publishing application does not put data in the shared data
>repository for a purpose other than to publish it.  There is no design
>intent, let alone a contract between sender and receiver.  RDF is useful
>for this because it decouples the data layer from application data
>modelling by enabling the schemaless.

yes, i am still a believer that RDF as framework for large-scale and
flexible BI is the killer app for RDF:
http://dret.typepad.com/dretblog/2011/05/from-ai-to-bi.html

>The "RESTful interactions" and book order examples have a different
>character where the order is placed by POSTing with a media type for the
>expectations - there is a shared intent identified by the media type.
>There is a book ordering service, a book order is made by a certain
>action; the return body is presumably something to track the order with
>and the body has the links to follow.

yes, this is where media types designed for application domains come into
play: use cases and scenarios drive patterns of how business documents are
exchanged to allow the completion of a business goal. the data model of
these business models often is completely decoupled from what goes on in
the services internally. that's good because then you can order from a
book seller that uses RDF, from one that uses XML, and from one that uses
SQL; you don't need to know or worry.

it seems to me that i am in the minority with my interest in services, and
that's fine; the working group should do what the majority of members are
interested in doing, as long as the charter can be interpreted to cover
that. but if we do the "shared, schemaless database" approach you have
identified above, then we really should strike REST from our charter, just
to be clear about what we're doing and what we're not doing.

cheers,

dret.

Received on Monday, 9 July 2012 15:45:38 UTC