- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Mon, 22 Mar 2004 14:20:25 +0200
- To: "ext Seaborne, Andy" <andy.seaborne@hp.com>
- Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
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. 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. We could even choose to have distinct "task forces" within the WG focusing specifically on each. > >> (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 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 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". Patrick > > Andy > > -------- Original Message -------- >> From: Patrick Stickler <mailto:patrick.stickler@nokia.com> >> Date: 22 March 2004 09:39 >> >> On Mar 19, 2004, at 17:16, ext Dan Connolly wrote: >>> My not-so-secret goal is Candidate Rec in six months. >> >> I'm very sympathetic to such a goal, though I hope that >> won't result in too rushed a rec which misses key issues. >> >>> To do >>> that, we need to stick to functionality that we've already coded. >>> Twice. i.e. one or more of us has done the prototype, thrown it away, >>> and built it for real. >>> >>> We have time to figure out what to do with the arbitrary >>> differences between the implementations we've got (i.e. one >>> implementation uses a comma where another used a period; one >>> supports integer add and one does float) >> >> I'm expecting that the DAWG rec solution will not employ built-in >> datatypes (even if it recommends support for XML Schema predefined >> datatypes) and will support RDF's datatype framework agnostic model. >> >> I.e., if I can't express datatype values as typed literals >> with arbitrary datatypes, then that is not acceptable. >> >> I hope that this is a widely shared position in the WG. >> >>> and >>> to spell-check our spec, set up a test harness, and that's >>> about it. >> >> >> I think that the WG actually has a bit more work to do than just >> repackage some existing legacy solutions as-is. >> >> Yes, most of the work has been done, and we should avoid venturing >> into any truly new areas, but I don't think we have absolutely >> all of the pieces in the form we need them in a single existing >> deployed solution to make the WG's activities primarily editorial. >> >> Three particular issues that I hope/expect the WG will explore, >> and ultimately incorporate into the final rec are >> >> (a) expressing queries and query results in RDF >> (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 >> >>> >>> Provenance doesn't look like a requirement to me. >> >>> Of course I think it's interesting and key to the future. >>> I spend a lot of time researching it and doing advanced >>> development with it. But it doesn't looke like part >>> of the so-called "minimum required to declare victory." >> >> I agree that provenance should be out of scope for this round. >> >> Cheers, >> >> Patrick > > -- Patrick Stickler Nokia, Finland patrick.stickler@nokia.com
Received on Monday, 22 March 2004 07:22:16 UTC