W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2009

RE: "suboptions" of Option 7

From: Eric Prud'hommeaux <eric@w3.org>
Date: Mon, 24 Aug 2009 08:10:46 -0400
To: "Seaborne, Andy" <andy.seaborne@hp.com>
Cc: Alexandre Passant <Alexandre.Passant@deri.org>, Gregory Williams <greg@evilfunhouse.com>, "public-rdf-dawg@w3.org Group" <public-rdf-dawg@w3.org>
Message-ID: <20090824121046.GC25777@w3.org>
* Seaborne, Andy <andy.seaborne@hp.com> [2009-08-21 14:52+0000]
> 
> 
> > -----Original Message-----
> > From: public-rdf-dawg-request@w3.org [mailto:public-rdf-dawg-
> > request@w3.org] On Behalf Of Alexandre Passant
> > Sent: 21 August 2009 12:12
> > To: Gregory Williams
> > Cc: public-rdf-dawg@w3.org Group
> > Subject: Re: "suboptions" of Option 7
> > 
> > HI,
> > 
> > On 19 Aug 2009, at 19:06, Gregory Williams wrote:
> > 
> > > On Aug 19, 2009, at 7:38 AM, Alexandre Passant wrote:
> > >
> > >> While I'm really willing to see RDFa annotated endpoints, I think
> > >> that 2 issues in that case would be:
> > >> - Some endpoints do not provide any forms for query input (unless
> > >> we want to say in the next spec that any endpoint must have a form
> > >> for query input - I'd favor that as well)
> > >
> > > I'm not sure having a service description in HTML and/or RDFa
> > > implies that the HTML *has* to have a query form.
> > 
> > I should have said - some endpoint do not provide any HTML page and
> > just raise an error if no query is sent.
> > That's something we have to consider regarding that proposal.
> > 
> > Alex.
> 
> This is the normal arrangement using Joseki.  /sparql is the query service endpoint, /sparql.html is the HTML form.
> 
> It's not necessary that it be that way but it maintains a practical separation of static content from the dynamic query processing.  The Joseki query processor is a servlet and dispatch is done by the web container (Jetty, Tomcat etc) and that's by the URL without the query string.  Having the static content managed by the web container normal static content handling, meaning the dynamic part (the query processor) does not have to do anything in particular is clearcut.

I'm trying to get my head around conneg proposal by examining an
interaction with a Joseki endpoint E (<http://example.org/sparql>).
While users go to E.html, queries would be E?query=blah and
service descriptions are about E.

SPARQL client C wants to see how much service E costs / CPUsecond.
C GETs E Accept: application/sparql-desc+xml  or  +ttl
I guess the response either includes
  E cost:pricePerCPUsecond "10000"^^cost:euros .
or
  E sd:url <http://example.org/details>
which then includes that assertion. What are the arguments for the
extra indirection?


> 	Andy
> 
> 
> > 
> > > It might be nice, but the spec might not have to force the query
> > > form on everybody (and in fact not doing so might help us re: abuse
> > > of conneg, allowing the people who are going to add a query form to
> > > be the ones who are abusing conneg, not the spec).
> > >
> > > .greg
> > >
> > 
> > --
> > Dr. Alexandre Passant
> > Digital Enterprise Research Institute
> > National University of Ireland, Galway
> > :me owl:sameAs <http://apassant.net/alex> .
> > 
> > 
> > 
> > 
> > 
> > 
> 

-- 
-eric

office: +1.617.258.5741 32-G528, MIT, Cambridge, MA 02144 USA
mobile: +1.617.599.3509

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.
Received on Monday, 24 August 2009 12:11:33 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:39 GMT