Re: "Basic profile" terminology ?

Hello dret,

<Erik.Wilde@emc.com> wrote on 06/29/2012 07:07:20 PM:

> From: <Erik.Wilde@emc.com>
> To: <andy.seaborne@epimorphics.com>, <public-ldp-wg@w3.org>, 
> Date: 06/29/2012 07:10 PM
> Subject: 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.
> 

In Linked Data terms, as defined by TBL [1], you don't have a "service" 
model or only human understandable media types...you have data, 
addressable and manipulated by some standards.  This enables a broad class 
of applications to operate on a data model, with meaning and 
relationships, that works for the web, scales to the web and works for the 
enterprise (within the firewall, outside or both).  HTTP + RDF + some 
rules can give you that and why the workshop attendees [2] wanted to 
address with this WG (me being one of them).  Sometimes it does take 
humans to understand the semantics of the ontologies used within the data 
models.

I believe you are talking at a level that is out of scope for this WG by 
talking at the "service" layer.  The example you reference seem to enable 
only a single pairing (or limited pairing) of client application to server 
applications for specific media type interaction.  What you are describing 
is not at all what was discussed at the workshop and why I'm participating 
in this WG for IBM.  Perhaps there is value in such an effort and perhaps 
worthy of its own workshop to gauge interest.

> >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.

The member submission highlights how to use existing standards to achieve 
a sizable number of topics listed in 
http://www.w3.org/2012/ldp/charter#issues.
I think it would be best to debate whether we need the term "RESTful" in 
our charter as it is now a days more of a buzz word and lacks any 
normative status at W3C.  This seems to be leading to some confusion but 
it is very clear to me that RDF is not up for debate based on its 
normative status and clear presence in the charter.

> 
> thanks and cheers,
> 
> dret.
> 

Apologies for delayed response.

[1] - http://www.w3.org/DesignIssues/LinkedData.html
[2] - http://www.w3.org/2011/09/LinkedData/Report

Thanks,
Steve Speicher | IBM Rational Software | (919) 254-0645

Received on Monday, 9 July 2012 12:25:13 UTC