- From: Alberto Reggiori <alberto@asemantics.com>
- Date: Mon, 22 Mar 2004 15:46:43 +0100
- To: Patrick Stickler <patrick.stickler@nokia.com>
- Cc: "ext Seaborne, Andy" <andy.seaborne@hp.com>, RDF Data Access Working Group <public-rdf-dawg@w3.org>
On Mar 22, 2004, at 1:20 PM, Patrick Stickler wrote: > On Mar 22, 2004, at 14:02, ext Seaborne, Andy wrote: > >>> (a) expressing queries and query results in RDF >> >> +1 >> >> And I would add: >> >> () a standard means to make such a query (HTTP and/or SOAP) to a >> remote >> datasource on the web. >> >> Not all situations need this protocol part or access (for example, a >> local >> datasource may have other, more sophistaed means) but as a web >> recommendation, the DAWG should include the web access aspect to meet >> the >> charter. > > Agreed. +1 for me too and perhaps have the possibility to express more the one datasource in the same query from where to pull data/metadata - also leaving to the implementation the decision how to merge or smush those graphs. Even though I understand this might kick back in provenance in our requirements....but assuming we ignore that aspect for the moment, I find the need to select RDF from several different datasources as crucial requirement for a "web query language". > > I think the DAWG rec could (perhaps should) in fact be two distinct > documents, the first covering the expression of queries and query > results > in RDF (i.e. the vocabulary and semantics), and the second covering > protocol issues for clients submitting such queries to knowledge > stores. agree - some work about recording query-results has been already done in the past, and recently nicely summarized http://www.w3.org/2003/03/rdfqr-tests/summary.html which also provides a little bit of guidelines how to run simple interoperability tests between tools/implementations perhaps worth to add that page to the DAWG page for reference? > > We could even choose to have distinct "task forces" within the WG > focusing specifically on each. agree too - and I would expect that to happen at the first f2f meeting - or immediately after > >> >>> (b) a standard definition of a concise bounded description of a >>> resource >>> (c) a standardized means to request the concise bounded description >>> of a >>> specific resource >> >> The matter of "concise bounded description"s should be an orthogonal >> issue >> to the general form of query and of protocol. That is, it would be >> good if >> it did not need to be distinguished in the rec. I would rather agree with Andy here instead > I don't agree. > > Unless you are intending to restrict query responses solely to > bindings (which I think is both unnecessary and fails to meet > the needs of a very broad range of use cases that we've already > identified) you need to define what a "description" is. I do not think so - I rather would find such a requirement quite restrictive > I don't think it should be left up to each implementor to define > themselves what they will consider a description (such as is the > case with Joseki's 'fetch' operation) but that there should be > consistency across implementations insofar as the default, normal > behavior of DAWG conformant tools. Implementations may choose to > offer other flavors of descriptions, fine, but we really do need > to have a precise, standardized definition of a "concise bounded > resource description". even though that would be too much "application specific" - while we should try to be completely "opaque" on the "about" definition IMO cheers Alberto
Received on Monday, 22 March 2004 10:10:55 UTC