Re: forms, direction, query, etc …

On 21 Nov 2012, at 02:24, Arnaud Le Hors <lehors@us.ibm.com> wrote:

> You guys should feel free to develop any proposals you'd like but, while I'm happy for the WG to weigh in on this in view of an actual proposal, I have to say that this seems quite far from what I think this WG is chartered to do. 
> 
> Putting aside the reliance on SPARQL for which several people have already raised concerns I don't think developing an elaborate query mechanism is on our plate, at least not in this version of the spec.

I think it is a bit early to exclude general groups of answers to solutions here. I am not defending SPARQL by
the way or any complex/elaborate query mechanism. 

In the thread on ISSUE-33 on pagination the mention of  SPARQL was there to help explain the relation between forms and queries using a well understood standard. The counter argument by Eric Wilde came
in three parts

 1- forms are not queries to the user 
 2- forms are templates
 3- semantics in forms is too complicated to implement
     a-  client side
     b-  server side

My answers were

 1. is simply wrong. It is quite obvious that forms are asking something of the user.
     That answering a question can have additional impact ( such as answer yes to the question: "do you want to buy this book") does not deny that it is not a question

 2. is true. Forms are templates but so are queries. 

 3. complexity is a relative thing
   a. the difficulty of implementing form understanding client side depends  on the complexity 
      of the query language - and that is as you point out not specified yet - it could be very simple.
   b. server side it is trivial, since the response to a form is no more complicated than
      current html form responses.

So now the complexity of a query mechanism is going to have to be judged in relation 
to how many solutions it solves that would otherwise have to be put in place in ad-hoc 
ways for the spec  to work. 

In my view you need a simple query mechanism ( I am not saying SPARQL ) for

  - patches ( how are you going to tell what to remove and what to replace it by )
  - querying server for simple patterns on large graphs -> efficiency
  - issues like pagination, and anything where HTML forms would be useful - no HTML forms
    no e-commerce
  
I think one can get a very simple query language to do that, that would certainly make the
whole of the spec a lot more simple and useful than any of the ad hoc solutions that will
need to be developed case by case for each of the different use cases.

> 
> Again, I don't mean to stop you. Please, feel free to make a proposal. I just want to share with you my concern that this may be out of scope so that if you see me pressing this point later on you aren't surprised. Consider that a fair warning. :-) 
> --
> Arnaud  Le Hors - Software Standards Architect - IBM Software Group
> 
> 
> Roger Menday <Roger.Menday@uk.fujitsu.com> wrote on 11/20/2012 02:04:26 AM:
> 
> > From: Roger Menday <Roger.Menday@uk.fujitsu.com> 
> > To: Olivier Berger <olivier.berger@it-sudparis.eu>, 
> > Cc: Linked Data Platform Working Group <public-ldp-wg@w3.org> 
> > Date: 11/20/2012 02:05 AM 
> > Subject: Re: forms, direction, query, etc … 
> > 
> > 
> > >> Henry opened up some discussion at the end of our phone 
> > conference today, regarding his proposal about forms and query. 
> > >> 
> > >> I've got to say that I thought Henry's proposal [1] was really
> > >> elegant.
> > > 
> > > +1
> > > 
> > >> I also think that it is a solution for a problem that is very 
> > relevant to LDP. 
> > >> 
> > >> If it has a flaw, it that a client needs to be SPARQL aware - 
> > which I don't think will help uptake. I made my proposal on this 
> > topic at [2]. I'll freely admit that it does not have the elegance 
> > of Henry's use of SPARQL to drive interaction from the client, but, 
> > what it does have is simplicity! It is sort of like "duck-typed 
> > creation" .... it doesn't offer anything elaborate (repeated, 
> > options, etc.) at the moment. 
> > >> 
> > > 
> > > Thanks for the reminder for this subthread which was raised initially in
> > > the discussion about Issue-33... but... what exactly is the point that
> > > Henry was after during today's meeting ?
> > > 
> > > I'm not sure it is strictly related to issue 33 but maybe more to other
> > > issues about discovery of the expected POST content, etc.
> > > 
> > > Would you mind clarifying, and maybe propose a particular open issue we
> > > should tackle during the next meeting where Henry's proposal would help
> > > (providing that we got rid of the "opening raised issues phase" before
> > > ;) ?
> > 
> > hi Olivier, 
> > 
> > I am happy to have a go and summarise the state of this topic. 
> > This could be a starting point for discussions at the next meeting. 
> > 
> > Roger
> > 

Social Web Architect
http://bblfish.net/