Re: "Basic profile" terminology ?

hello andy.

On 2012-06-29 2:22 , "Andy Seaborne" <andy.seaborne@epimorphics.com> wrote:
>On 18/06/12 17:09, Erik.Wilde@emc.com wrote:
>>thanks for raising that issue, and you're right that this is an important
>> one. i am convinced (and you'll see https://gist.github.com/2927644
>> converging towards this point) that the most important question we will
>> have to answer is whether we're targeting our design at the data in a
>> back-end, or at a "service surface". i think we should aim for the
>>latter,
>> because that allows loose coupling. if we go that route, then /basic
>> profile/ would be more of a service layer, and not so much the data
>>layer
>> itself. but it still remains to be see where we're headed with this.
>dret - could you explain this some more?  I may understand you point, I
>may not ... I can't tell yet :-) The word "service" has been used for so
>long, in so many places. Loose coupling to me tends away from describing
>interaction models (maybe too much RPC background on my part from long
>ago!).

yes, "service" is a very very fuzzy word. in REST terms, the idea is to
exclusively focus on the service model (linked representations that drive
application state, by clients following links that have service-specific
semantics). very concretely: if you want to build a system for ordering
books, you just look at what needs to go in a book order, and then you
design a representation that allows you to transfer the state of an
"order" from a client to a server. if accepted, the client can also GET
pending orders, which hopefully look very similar to order submissions.
all of this should, as much as possible, reuse established standards (such
as the ability to GET a feed of orders instead of re-inventing that
concept just for orders), and should not be driven by the order service
implementation. one book order service may use SQL, another one XML, and
yet another one RDF, but the "service surface" should not reflect these
implementation differences to the outside.

>The gist seems to be talking about both describing the service and the
>actual interaction with the service.

yes, it is. in non-RDF scenarios, describing the service typically is done
in a media type with quite a bit of prose, mapping the prose (semantics)
to syntax.

>There is a continuum from a service model (maybe better said as ways to
>describe, store and publish service descriptions and their interactions)
>to "data publishing".  "Linked Data" emphasis the data publishing end of
>the continuum.

the way to describe, store and publish service descriptions on the web are
media types, generally speaking. these take humans to understand and
implement (@JeniT referred to the fact that clients need to specifically
implement support for these), and that's fine. but even when you look at
"data publishing", any loosely coupled scenarios must add a protective
service layer on top of it. it takes a lot (for most scenarios too much)
trust for you to just accept batch SQL statements for you which you will
insert in your database. you want some way of how peers can make sure that
expectations are being followed, and a model for how a service can guide
clients through a process of expecting data, accepting or rejecting it,
and maybe even transforming/filtering/cleansing it before it is actually
republished.

>The submission UCR (2.3) talks about the data in the applications -
>"people, projects, customer-reported problems and needs" - and
>interaction between tools.

concrete problem: if i am exposing a linked data service that accepts bug
reports, and that is a service that is open to the public, how do i
communicate and enforce the service-specific limitations of that service?
from the REST side, there has to be a "add-bug" link somewhere or maybe
just a "bug collection" that allows me to POST application/bug
representations. a service must be able to meaningfully pull these things
together: the semantics of "here is where you can file/get/close bugs",
and the state that needs to be transferred for these interactions.

>I do think that the most general service interaction description case is
>too ambitious for this WG in the time scale, if nothing else because of
>the lack of material to build on.  The list of WG deliverables covers
>the building blocks which I read as a step on the journey, not the
>journey itself.  Is that understanding correct?

we had quite a bit of scholastic discussions already. there are existing
standards (http://dret.typepad.com/dretblog/atom-landscape.html) that
cover a sizable number of topics listed in
http://www.w3.org/2012/ldp/charter#issues, and the interesting question is
whether the charter prohibits us from considering solutions that are not
based entirely on RDF, or not. mixing media types is business as usual in
REST, but it may not be what everybody prefers. my current understanding
is that you can interpret the charter both ways, and thus the question is
not one of interpretation, but for the working group to decide which way
it wants to go.

thanks and cheers,

dret.

Received on Friday, 29 June 2012 23:08:11 UTC