Re: sparql protocol simplex updated (protocolRootReferent issue)

Dan Connolly wrote:
> On Thu, 2004-12-09 at 14:56 +0000, Seaborne, Andy wrote:
> 
>>Kendall,
>>
>>Good to see a new draft.  Seems to me to be going in the right direction and 
>>could be published as a first WD as-is.
>>
>> Andy
>>
>>== Language specification
> 
> 
> This part of your message seems relevant to an existing issue
> http://www.w3.org/2001/sw/DataAccess/issues#protocolRootReferent

Yes - and it adds that multiple QLs may be available at a service point or 
"model point" (a model in a model-centric protocol).

Both ways work - Kendall is trying to be neutral.

I think that choosing one makes for clearer explanations - I think eventually we 
will have decide one way or the other as the details get sorted out.

> 
>>It would be good to be able to transport other query languages, existing and
>>to come.  The abstract syntax for RDFGraphQuery does not contain a specifier for
>>the query language;
> 
> 
> That's a good thing, per my experience.
> (as reported earlier in a DESCRIBE thread
> http://lists.w3.org/Archives/Public/public-rdf-dawg/2004OctDec/0346.html
> )
> 
> 
>> guess/parsing may be insufficient (some RDQL is legal SPARQL
>>but the effect of SELECT is different).
> 
> 
> Guessing isn't necessary, any more than an HTTP server needs to guess
> that the incoming syntax on port 80 is HTTP syntax. There's external
> metadata out there in the world that says that this endpoint speaks
> HTTP.

Kendall says the design is neutral to service-centric vs model-centric 
viewpoints, with multiple operations per service end point (SP) already.  You 
seem to be assuming a service centric, one QL per service access point model. 
Just different.

External metadata is insufficient in the case where a service point (or model 
point) offers multiple query languages.

I would be happy with the "one QL per SP" design but that was not the intent as 
I understood it.  As the service can also define the graph to by queried, makes 
for a short(ish) request "GET /qps?query=SELECT.."  Super.

I can also live with services (or models) that offer multiple query languages 
since the protocol doc says there are two already (SPARQL, getGraph).  Why these 
two when the protocol is general?  I'll let Kendall decide. (I think of getGraph 
as a QL because querying is just getting some information and getGraph does that.)

Example is Joseki metadata:

<http://server/bookLookupService>
     a   joseki:AttachedModel ;
     joseki:attachedModel        <file:Data/books.n3> ;
     joseki:hasQueryOperation    joseki:BindingRDQL ;
     joseki:hasQueryOperation    joseki:BindingSPARQL ;
     joseki:hasQueryOperation    joseki:BindingGET ;
     rdfs:comment "A collection of book details" ;
     .

which says it offers RDQL, SPARQL and plain GET.

As the doc tries not to force "one QL per SP", I suggested the least disruptive 
way around the issue.

As it stands, a service /qps can't offer two query languages if it can't tell 
which language the query is in.  The same string might lead to different results 
(matching subgraph vs result sets).

example: SELECT * WHERE (?x ?y ?z)

> 
>>I'd like to see a parameter in the abstract protocol with "lang=" in the HTTP
>>binding.  It becomes the only globally defined parameter and would free up all
>>other parameter names to be specific to the query language, not predefined by
>>this doc.  (I think there are slight differences in "graph=" between the SPARQL
>>query and the getGraph query.)
>>
>>With a lang= parameter, then the requests would look like [*] this:
>>
>>        GET /qps?lang=sparql&graph=...&query=...
>>
>>then the 3rd party form (ask a service for a named graph) of getGraph is:
>>
>>        GET /qps?lang=getGraph&graph=...
>>
>>while the 1st part version is still regular GET:
>>
>>        GET /3.rdf
>>
>>[*] except it should be a URI, not a short name.  But it won't fit them.
> 
> 
> [... other review sections elided...]
>

Received on Thursday, 9 December 2004 15:48:44 UTC